This question already has answers here:
Interface Segregation Principle and default methods in Java 8
(4 answers)
Closed 1 year ago.
in this question the author gives some reasons about why the default keyword is introduced into java language. One reason provided is to support the optional method.
However, taking ISP into consideration, no client should be forced to depend on methods it does not use.
(from wikipedia) In the field of software engineering, the interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.[1] ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.
From my point of view, we should be encouraged to split functions into small interfaces, without puting everything into single interface by the default trick.
Simple and short:
Yes, it conflicts with the ISP.
But there is no other choice if you want to introduce a method in hindsight, after already designing the original interface and having people implement it all over the world.
Related
This question already has an answer here:
Interfaces VS APIs VS Public classes
(1 answer)
Closed 2 years ago.
Big Packages Like twitter Provides Developers with APIs These APIs allow them to have limited access of the functions of their packages.
The implementation of functions we have access is hidden so is it safe to say APIs are just an example of Abstraction??
The "I" in API stands for "interface". An interface is something that you interact with by providing input and receiving output. Abstraction is an idea, just that, an idea without a specific implementation. Look at Java abstract methods and classes. They are "ideas", if we may say so, that each one of us can implement in a different manner. Having said that and looking again at the API, we API consumers, have no say on the implementation of the API functions. We feed it some input and get some output, or in other words, we interface with it.
Is this an example of abstraction? Not to me.
This question already has answers here:
What does it mean to "program to an interface"?
(33 answers)
Closed 5 years ago.
From my understanding, you program to an interface rather than a concrete class to restrict yourself from using methods that aren't part of the interface. This helps in the case you want to change the implementation of said interface later on. (Flexibility)
i.e.
List myList = new ArrayList(); // programming to the List interface
instead of
ArrayList myList = new ArrayList(); // this is bad
Is the reason you can't access methods in ArrayList such as trimToSize(), that aren't part of the List interface, simply because they're not defined in List? Is it similar to as if a class had a public global variable but no method to access it?
Also, if you do decide to change
List myList = new ArrayList();
//into
List myList = new LinkedList();
Would the only reason you would make such a change be for the performance (I see no other reason)? Since in both cases you'd only be able to access the List defined methods, excluding the concrete implementation's extra functionalities.
People use interface to hide details of details of implementation. For example, I want to write a function that returns size of a collection - it can be a list, an array, a map, anything at all, I don't care. I'll use a pseudo-code, it's not relevant to Java:
int length (Collection c) {
return c.size();
}
Otherwise, I have to implement 'map_length, list_length' and dozens of other methods. And this will blow up your code dramatically.
Another common example - data bases. There quite a lot of them with different API, request languages, performance, etc. I don't know ahead, which one prefer to use in your application. So you can create generic data base interface and use it as 'a placeholder' around your code. While you hide exact DBs behind an interface, you can switch between various DBs without any issues.
I would recommend you reading further on inheritance and patterns.
You are right in your explanations.
Programming with interfaces (i.e API) has several interests. Below are few of:
It clearer/simpler in term of contract: Somebody who uses your API will know which feature you exposed and so what he can use.
It does not help to expose everything just for the reason "in case of..." No, if you are designing a business, it is most of time for specific reasons / needs.
Even when you are building some technical layers, it is still better to expose only what you what to be used as a general purpose, especially when you can have different implementations of a contract (having only one implementation does not mean you don't need API interface by the way)
It is safer: You avoid complexity of usage, and so use scenario.
Better for maintenability: as you said you can change your implementation without impacting client that use your API (if it is correctly designed of course)
In term of project organization, it also enables you to split your project(s) into several module(s) and introduceS module responsabilities.
In term of application building / deployments, it also enables you to seperate components and then to change / rebuild / deploy only parts of your global application.
There are lot of Benefit when programming by API.
About List and different implementations, the reasons why some methods does not exists and the API can be:
Either people who did it did not think about possible future usage
Or, maybe the feature you ask for is too specific to be proposed as a general public method on this API
Or, maybe it is not (or should not be) the responsability of such a class to do your specific need
Or, maybe other utility classes on List already do what you need
Or any other good or bad reasons
I would say that it really depends on your situation, there is only one rule "Dependency Inversion", for example, if you are writing business code then the presentation layer should implement interfaces, but in the business layer you don't really need it unless there is a good reason.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In java, If we are using an enum and eventually we want to add/remove an attribute to/from that enum, hence its usages, we are violating open/closed principle in solid principles.
If so, what is the better usage of enums?
The answer is no as OCP doesn't apply (and cannot apply) to Enums. Enums should be complete (contain all possible values) and static (static = final, non-mutable). You can see them as a small, finite set of Value Objects.
If you want something that can be extended, you can always use a class or build your own "type-safe enumeration" that can be extended.
About the language. I choose to use the term apply rather than violate, as principles, as many good practices, have a context where it makes sense to apply them. A violation (for me) means that a situation calls to use a principle, but it's not used or it's not implemented properly. It doesn't apply means what it says on the tin, that the principle brings no use in the current context or that it cannot be applied, as otherwise would go against other principles which have stronger forces ... in the context :).
Edit
Another reason why I think Enums don't violate OCP (now I use the word violate :D), is because OCP doesn't mean that all of the classes and methods can be extended, but rather that a conscientious developer makes informed decisions about where to put those extension points. In the case of an Enum a developer understands that there's no need to extend the possible values and further that it would be damaging to add new values, as existing code wouldn't know what to do with the new value. So he/she decides to completely close the class and not provide extension points. The same applies to any other class that is final. A final class doesn't violate OCP, but rather (or ideally) a developer made a decision of not allowing to extend it.
This is similar to what I mentioned before, that Enums are like a small, finite set of Value Objects. VOs are immutable and closed, and as such they don't violate OCP.
And to add something more, I've seen some libraries not implementing OCP correctly (Tapestry 5) and making more than needed final, which made them a PITA to use. Or just not closing anything, which made some devs make mistakes because they didn't understand the finer details of the library, and messed up the invariants.
The answer is yes. All Java enums violate the Open/Closed Principle, because they cannot be extended without modification.
The "better usage of enums" in Java is to have them implement an interface, and have clients depend on that interface rather than the enum implementation, because the interface does not violate the Open/Closed Principle.
Don't jump to the conclusion that if enums violate the OCP, then we shouldn't be allowed to use them. I want to clarify this answer with a reminder that the OCP, by definition, applies only to client-facing code, i.e. code that is public/exposed. The OCP is not a restriction on implementation details.
A module is said to be closed if it is available for use by other modules... At the implementation level, closure for a module also implies that you may compile it, perhaps store it in a library, and make it available for others (its clients) to use.
--Bertrand Meyer, Object-Oriented Software Construction 2nd ed. page 57
So, utilizing enums as part of an application's internal API avoids the OCP altogether. It is only as part of the external API where enums should be abstracted through an interface.
Consider that since an enum is a concrete implementation, exposing it only though an interface serves as much to satisfy the Dependency Inversion Principle as it does the OCP. Even if you believe that directly exposing enums somehow sidesteps the OCP, it still creates a concrete dependency, which violates the DIP.
Also consider the comment from #MarkRotteveel, "Open/closed is a principle, not a dogma that needs to be followed at all times."
Open/Closed as well as all SOLID principles were designed to make easy refactor and understand the code. You should use it based on the context.
As long as Enum Types must be a a well-known set of values, you shouldn't write something like this:
enum Fruits {apple, pear, banana}
enum Food extends Fruits {chicken}
For three reasons:
1) Java doesn't allow it.
2) By no means a chicken is a Fruit
3) Fruit is no more a well-known and complete set of values
If you use Enum to define, for example, the planets of the Solar System and a new planet is discovered or an old one loses its status (or is destroyed by aliens) it's Ok to modify your class to adjust the new requirements.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Use of Java [Interfaces / Abstract classes]
What's the benefit of interfaces over normal Java classes. Someone explained to me that an interface is like a contract, but I just don't get it. Why not just stick with classes?
Interfaces are useful for a couple reasons:
1) A class can extend only one other class, but it can implement any number of interfaces. This allows a method of multiple-inheritance while limiting the difficulties caused by multiple-inheritance.
2) They allow you to hide your implementation when you provide an API to your code, thus allowing you the freedom to change your implementation details in any way you wish as long as you don't violate the previously-defined interface.
For very small projects, interfaces may not be useful. For any medium-sized or large project, interfaces definitely help define the boundaries between the components so that the individual components can be tested in isolation from each other. Appropriate use of interfaces can also help you avoid circular dependencies between your JAR files.
When you are coding against a concrete class, it is easy to make use of implementation details that may not remain in future versions of the class. When you code against an interface, you cannot do this.
Read What Is an Interface? from the Java tutorials, it's well explained.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java: “implements Runnable” vs. “extends Thread”
I have two classes called "Hierarchical" and "RS" which extends another class called "Encode". The first two classes also implements Runnable. Which interfaces should I implement, the EncodeInterface or the other two? I also have a number of business objects, do I have to implement an Interface for them as well? Business Object are in a seperate package. Thanks in advance
I am trying to develop using the facade pattern. That requires one to have at least three packages for each subsystem right, one for the business objects, one for logic and another for data access right?
I have two classes called "Hierarchical" and "RS" which extends another class called "Encode". The first two classes also implements Runnable. Which interfaces should I implement, the EncodeInterface or the other two? I also have a number of business objects, do I have to implement an Interface for them as well?
What interfaces you should define and implement depends on what you're trying to do, which isn't very clear from your question.
I am trying to develop using the
facade pattern. That requires one to
have at least three packages for each
subsystem right, one for the business
objects, one for logic and another for
data access right?
It sounds like you're jumping to the facade pattern without actually knowing that you need it.
The pattern does not dictate what packages or subsystems you have to have. It is a technique for dealing with a situation when you already have a complex system with multiple subsystems and you want to provide a simpler interface for the uses of the system.