Interfaces should be designed in their own right. ![]() ![]() These interface definitions are the core aspect of the OO design work. The concept of a Book and its properties/behaviors should be common across code that works with books. Note that this doesn't mean that you should have a separate interface for every parameter of every method. Worry about creating/conforming the implementation(s) that match that interface when it comes time to pass instances in or return instances of them. You will then have an interface which specifies the behaviors that it needs to support. Check that it did what you wanted and repeat this until you are done with the calling code. Your IDE will point this out and then offer to create the definition for you. As you do this, you will start calling methods that aren't defined. With any decent IDE, you can create an empty interface and then write the code that will interact with it. I argue that the best way to define interfaces is to create them in the code that will call them. (If that's not the case, then there's no reason to define it.) If you didn't have the interface, you would need to create and maintain duplicate versions of the same functionality for each type. There are then dependencies on that specification in the code. Instead, interfaces should be designed from the perspective of the client of that interface and classes should be written to align with those interfaces as needed.įor example, your Book interface is presumably used in the signature of some method or constructor either as a parameter or a return type. That is, they write a class or set of classes and then try to align interfaces to match the class definitions. This is a fundament mistake that I think a lot of OO developers make. It's thinking about them from the wrong direction. More importantly, in my opinion, is that such an approach completely misses the point of interfaces. This aligns to the first bullet and may be what the author was getting at. ![]() Having an interface which simply restates the interface of a single class is pointless. As someone once said, writing the same thing twice (or three times) doesn't make it correct. The first is that it means there are going to be many interfaces which have no reason to exist and simply create additional maintenance burden. Instead of trying to guess what the author might be getting at and whether that is right or wrong, I'll explain the interface anti-pattern that your question brings to mind: creating an interface for every class (or almost every class.) There are two main reasons that I think this is a bad practice. The third bullet kind of sounds good but doesn't really hold up under scrutiny. If you have two or more implementations of an interface, it's a hint that the interface exists for good reason. ![]() An interface doesn't need to match the signature of class (or vice-versa) but if it does, that isn't necessarily a problem.Īs I noted in the question comments, your example doesn't align with the second bullet: "There’s only one implementation of your interface". The first bullet "Your interface signature identical to your class" is a fairly weak argument. Without the full context of this article, it's impossible to say exactly what the point of it was but I think I can provide a useful answer to your question.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |