![]() The programmer first thinks it’s probably just OK to implement the IProduct interface again: ![]() The following two classes implement the interface:Īll is well so far, right? Now management comes along and says that they want to start selling T-Shirts with movie stars printed on them so the new product is more or less related to the main business. Here I take the interface approach but it’s perfectly reasonable to follow an approach based on an abstract base class instead, such as ProductBase. Open Visual Studio, create a new Console app and add the following interface: The domain expert correctly recognises that these are indeed related products that both can implement the IProduct interface. We’ll simulate a movie rental where movies can be rented in two formats: DVD and BluRay. Unnecessary dependencies in turn reduce the cohesion, flexibility and maintainability of your classes and increase the coupling between dependencies. This helps you create subclasses that only implement those interfaces that are meaningful to them.īig fat interfaces – and abstract base classes for that matter – therefore introduce unnecessary dependencies. Adhering to ISP will often result in small interfaces with only 1-3 methods that concentrate on some very specific tasks. Often such master interfaces are a result of a growing domain where more and more properties and behaviour are assigned to the domain objects without giving much thought to the true hierarchy between classes. However, there are more subtle differences between two ‘almost related’ objects than between a Person and a Triangle as we’ll see in the demo. The above example is probably too extreme, nobody would do anything like that in real code I hope. Then they will see exceptions thrown or inexplicable 0’s returned where the method does not apply. Also, if you loop through an enumeration of IMasterInterface objects then the caller expects to be able to simply call the CalculateArea() on every object in the list adhering to the LSP principle of the previous post. …where the true implementations will probably throw a NotImplementedException or will have an empty body or return some default value such as 0 at best. …then the client may as well make the following method calls: These look perfectly reasonable, right? However, if the interface they implement looks like this…: All implementing classes will of course need to implement all methods in the interface where the unnecessary ones may only have a throw new NotImplementedException as their method body. The opposite is that an interface grows to allow for more functionality where there’s a chance that some methods in the interface are not related, e.g. If you have no direct access to that interface then all you can do is to implement the relevant bits and ignore the methods that are not relevant for your class. Imagine that your class needs some functionality from an interface but not all. ISP is about breaking down big fat master-interfaces to more specialised and cohesive ones that group related functionality. The Interface Segregation Principle (ISP) states that clients should not be forced to depend on interfaces they do not use.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |