Menu
I know and understand the value of interfaces in Java. You code to the interface, and then you can change your implementations without having to change any code using the interface. Often the term "contract" is used in connection with interfaces. The way I understand it is the interface defines the "contract" between the application and the implementation.
So, when I create an implementation, I have to fulfill the contract. My questions is, what exactly is in that contract that I have to fulfill?
Obviously, at a minimum you have to provide methods with the same signatures as the interface. The code won't compile otherwise. Is that all the "contract" entails? It seems like there should be more.
For example, I've read articles debating the value of testing to the interface vs. testing specific implementations, or doing both. I see great value in having tests for an interface so that you know what inputs have what expected outputs. It would seem to me that this would also be part of the interface "contract". Every implementation of the interface should produce the same outputs from the same inputs. Obviously there's no way to enforce this contract in the code, but it can be enforced through test cases. Am I wrong in my thinking here?
Finally, what about side effects that implementations have? Here, I'm mainly talking about any persistence that might happen as part of the implementation. Say I have an implementation that is saving some records to the DB while it preforms the operation. Would this somehow be part of the interface "contract"? If so, how could you enforce this contract? From the interface level, I have no idea what the implementation is actually doing. All I know is I give it inputs, and it gives me an output, which I can test. Is any persistence that happens also considered an "output"? If so, I just don't see how this can be tested and enforced. I'm a proponent of persistence ignorance, so I could know that something should be persisted, but I don't know how it is persisted. So, I just don't how to tell when something actually persisted. It may be simple if your interface has some simple CRUD operations, but I want to think about more complicated interfaces.
I hope my question makes sense and that someone can provide some good feedback. I want to discuss this generally, but I can provide a specific example if it's not clear what I'm talking about.
568
Interfaces form a contract between the class and the outside world, and this contract is enforced at build time by the compiler. If your class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile.
A contract describes the interaction between both sides, as a set of requirements that the consumer has from the provider. It's analogous to interfaces in OOP — The interface is the contract between the calling code (consumer) and the implementing class (provider).
- Interfaces function to break up the complex designs and clear the dependencies between objects. Disadvantages : - Java interfaces are slower and more limited than other ones. - Interface should be used multiple number of times else there is hardly any use of having them.
A Java interface is not intended to contain implementations of the methods, only the signature (name, parameters and exceptions) of the method.
I think "contract" and "Interface" have very less in common.
An interface is something like a door. A door may pass typical human, but not elephants, giraffes or car.
An contract is when you could assure that through the door only female, or male, or software developer will come.
So a contract defines BEHAVIOR while interface defines which information is passed
94
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
