We Keep Coding

does default interface violate the Interface Segregation Principle? [duplicate]

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.

Programming to interface [duplicate]

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.

What does composition do?

I have been learning java for the past two days and i have gotten confused with composition. what exactly is the point in composition and what does it do?Please leave some examples as well.

I think it is already answered in so many links. Refer these links.
Implementation difference between Aggregation and Composition in Java,
Favor composition over inheritance
https://softwareengineering.stackexchange.com/questions/176049/what-is-the-use-of-association-aggregation-and-composition-encapsulation-in-c
Also read this link
http://www.journaldev.com/1325/what-is-composition-in-java-java-composition-example
I put what Chandra posted. This might be what you are looking for
I think this is one of the most discussed point in Object Oriented design. As suggested in the article, composition is always preferred over inheritance. That doesn't mean that you should never use inheritance. You should where it makes more sense (which can debatable).
There are many advantages of using composition, couple of them are :
You will have full control of your implementations. i.e., you can expose only the methods you intend to expose.
any changes in the super class can be shielded by modifying only in your class. Any clients classes which uses your classes, need not make modifications.
Allows you to control when you want to load the super class (lazy loading)

Questions concerning an interface class

I know this is a question that has been asked a 100 times over but I would like to provide some of my own definitions to see if I understand an interface correctly.
Questions:
What is an interface?
An interface defines the structure for code design. An interface lays the foundation for your design and is made up of a collection of abstract methods and contains behaviors that a class must implement.
When to use an interface?
When similar methods of a design are to be reused across a project. This creates the structure of the behavior within a a project.
Why use an interface?
You use an interface in a project to create the foundation much like the construction of a new home. When a new home is built the frame is built, then the walls and doors and so on are added.
My above answers are what I describe as an interface and would like to know whether I am correct or not? If not, then please explain?
Thanks

You use an interface so that any class can make use of it as long as they implement it. That is why List is so cool and we use it in everyday programming.
Cows and Goats are both animals and they eat, walk, sleep, etc. You do not want to declare the same behaviors separately. If you now have a new animal, you will have to define the similar behaviors again. An interface forces you to implement the required behaviors.

I would argue that an interface is more like a an optional contract -- you specify the method names, parameters, and return type, and if a class chooses to implement the interface, it must then conform to the terms of that contract. It's more like an API spec than a design foundation, as interfaces are relatively flexible.
Note that this flexibility gives you considerable leeway in how you choose to use interfaces. As long as the implementing class provides the agreed-upon methods, the implementation is entirely up to you. There are interfaces (e.g. Serializable) that require no methods, and simply act as markers for the programmer's intent regarding a certain class.
Another use of interfaces is to mitigate the disadvantages of the fact that Java doesn't support multiple inheritance. Though each implementing class must contain the actual code, you might use an interface in an 'inheritance-like' way, to indicate that a certain set of classes derives behavior (in name, if not necessarily in implementation) from some common, more abstract pattern.
I would definitely suggest looking through the javadocs (perhaps the Collections framework) for more examples of interfaces. To continue with the contract analogy, the main use of interfaces is as a sort of API that specifies behavior you can count on, without having to know the implementation details.
The problem with the home analogy is that it's too restrictive-- interfaces don't restrict the design of a class as much as a foundation prescribes a certain structure for a building. Additionally, a building can only have one foundation, and in Java, there is no limit to the number of interfaces a class may implement.

Think of a TV remote analogy.
What
Its a standard way of using a Television(any television...flat screen, CRT, LED, LCD, Plasma etc).
So its basically an interface to a Television. Now, all TV remotes must have some basic common buttons (On, Off, Vol+, Vol-, Ch+, Ch-), these are the methods which should be present in the interface. Different brands implement these using different techs.
When
Now all Television brands want to share this standard way of controlling a Television (which is a big complicated machine).
Why
Think about it. It helps the consumer. As far as the consumer is concerned, he/she does not need to know how to manually operate the Television or from inside(you can do that from the circuit board!)

interfaces and their use [duplicate]

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.