When should you encourage code duplication?
Another story from class, today I was reviewing some of the student's code, and we run into this one:
The student is one of the keenest persons I have ever seen on removing code duplication (painful experience, I understand). But in this case, I had stopped and started using clipboard inheritence to duplicate the code. No, I have no gone insane.
The issue is in this case, removing code duplication has cause a violation of the Single Responsibility Principal. That is a bad idea. These two views had distinct responsabilities, they just happened to have identical implementations at the moment.
That doesn't means that you are free to duplicate code in the name of SRP, in this case, I would usually have something like this:
Where the implementation would live, and it would be forwarded from the views implementations.
In this case, it wasn't necessary, because shortly thereafter, I had to modify the IReturnBookView significantly :-)
Comments
Can't remember where I first heard the term, but this sounds like a touch of "coincidental duplication".
Is it IReturnBookView or IRetrunBookView?
Change "responsability" to "responsibility".
Duplication can be coincidental but usually not. When I spot it I strain my brain to return a semantically satifying name without the "And." Usually it works, but sometimes I just split it up...and then I take an asprin. :)
Foobar, thanks, fixed.
If you really wanted to eliminate duplication, you could create an IBookView with the two properties and then inherit the other interfaces from that.
The question is:
Is IReturnBookView and ICheckOutBookView ARE A IBookView - well, they are both a view on a book, but I don't think that I can say that they satisfy the basic condition for inheritnece.
Comment preview