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.
Related
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.
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.
This question already has answers here:
Scanning Java annotations at runtime
(13 answers)
Can you find all classes in a package using reflection?
(30 answers)
Closed 9 years ago.
I want to write a simple annotation like "#interface MyClassAnnotation" and "#interface MyMethodAnnotation" that targets Classes and Methods! but the main problem is that on main function i need to list all Class and Method instances on all JVM having that annotations! and I do not want to use any extra libraries, just pure built-in java functions.
Can anyone give me a good snippet for it?
You can determine whether your annotation is present on a particular class or method using the getAnnotation element, which is implemented by both Class and java.lang.reflect.Method.
The real question is, which classes and methods do you want to test this on? "All of them" is a bit hard to define. There doesn't seem to be a way to enumerate all of the classes that have been loaded by the JVM.
It's not feasible to go through all classes, you have to somehow narrow the scope. Either provide a configurable list of packages in which the classes with your particular annotation may be in or use the ServiceLoader concept in Java to declare the set of classes you need to find (this is useful if the code loading the service may be know about or link against all the implementations).
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.