So we should apply the interface segregation principle and split the ICashier interface into two smaller ones. These would essentially be dumb implementations that don't do anything, and these are not behaviors that a client class should expect or be able to ask a machine to do. You don't want to be forced to provide method implementations for the self-serve machine that don't fit the machine. But as you can see, this design is not ideal, because the self-serve machine should not need to clock in and out of work or take any breaks. So how does this work? The ICashier interface does work for the human cashier class because all its behaviors are captured by the interface. Instead, you should split large interfaces into smaller generalizations. This means that any classes that implement an interface should not have dummy implementations of any methods defined in the interface. The interface segregation principle states that a class should not be forced to depend on methods it does not use. So then are you forced to add these human behaviors into the interface? Or do you just accept that your system now has a low level dependency and will just do extra work when you need to make changes? Luckily, you can use the interface segregation principle to tackle this issue so that you won't run in to dependency issues or be forced to generalize everything into the interface. But if your client class calls the method directly upon a cashier, it will become dependent on that concrete class. A client class would not be able to use indirection to invoke these human behaviors, because they're not in the interface. Now, you can simply put these human behaviors into a concrete cashier class, but there's an issue with this design decision. While an automated self-serve machine can perform work indefinitely, a cashier needs to eat, go on breaks and leave at the end of their shift. They both scan items that a customer wants to purchase, accept some form of payment and dispense change when needed, but there are some behaviors that are not shared between the two of them. The purpose between the two can be generalized with an interface. They can approach a human cashier operating a till, or they can use the automated self-serve machines. In North American countries, there are two ways a customer can pay for their goods. Imagine creating a system that represents the checkout area at a grocery store. Can you think of any problems that this might cause? Consider this example. However, an issue can arise if an interface contains too much. Interfaces play an important role in object oriented programming, so much so that you should strive to program to interfaces instead of concrete classes. Design patterns do this so that client classes become less dependant on concrete classes, allowing for changes to be made more easily. These generalizations are presented as interfaces for client classes to use to indirectly invoke the behaviors of the concrete classes. Many design patterns that we've explored use generalization of concrete classes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |