1

I just read about all the 5 principles S,O,L,I,D and I like test it in little example if I understand them correct.

Which SOLID principles are hurt by this class diagram?

enter image description here

I think what is broken is Liskov Substitution Principle because if we take upper class Book and replace it with its lower class E-book then application we have here will stop working because there is no way / function to access each other class, both classes here just have their own functions and that's it. For the same reason the principle Dependency Inversion Principle should be hurt by this class diagram as well because there is no object of interface to communicate with the given classes here.

I think the other principles are not hurt.

  • 5
    It does violate the LSP, but you're wrong about why. It inherits all of its parent's methods, you don't write them out again in UML. – jonrsharpe Nov 17 '18 at 21:11
  • 1
    If the ebooks method was renamed "ship" and moved to Book.. – user949300 Nov 17 '18 at 21:21
  • 3
    Yes, the idea of "stock" makes no sense for an ebook. – jonrsharpe Nov 17 '18 at 21:41
  • 1
    @jonrsharpe If I think about your first comment, I believe that the Single Responsibility Principle is hurt as well because the class E-book can send mail as its function but can also do replenish stocks as it's inherited to the class Book. So we have a class (E-book) that does not only have one responsibility (it has 2) which clearly hurts this principle? – tenepolis Nov 17 '18 at 21:49
  • 1
    SOLID principles more about implementation then design. You will know is Liskov Substitution Principle violated only when you see implementation of overridden methods. Single Responsibility Principle is about that class should have only one reason to change. So if you want change how emails sends then you will change EBook class, if you want to change how replenish stocks is done, you will change Book class, so for me both classes have single responsibility. – Fabio Nov 17 '18 at 22:53
7

The only principle which is not respected here is the Interface Segregation Principle: E-book inherits stock and replenishStock() which are absolutely useless for an electronic book.

If you want to have a proper segregation of interfaces, you'd need something like the following, where Book describes a content, and PaperBook and e-Book correspond to sellable items with the generic content:

enter image description here

In your diagram, there is nothing wrong with the Liskov Substitution principle, since an e-Book is a specialisation of a Book, and therefore has the full interface of Book (it's implicit). Of course, stock and replenishStock() don't make a lot of sense, but nothing tells us that the contract is not respected (e.g. the replenishStock could very well set the stock to an arbitrary high value and meet all the preconditions, postconditions and invariants).

Dependency inversion is not relevant here.

  • 1
    the replenishStock could very well set the stock to an arbitrary high value That would (at best) still create a dud function with no meaning. While it does avoid exceptions and keeps the system working, that doesn't mean it's a good implementation. For example, consider that whatever arbitrarily high value you pick, your ebook may be listed as unavailable if it sells really well. I'm aware you can set it to an int value much higher than your servers could ever reasonably distribute copies of the ebook but it's the principle of the thing. It's still still violating LSP in spirit. – Flater Nov 19 '18 at 7:25
2

Most of the "principles" in SOLID (which are more like guidelines in most cases) are very context dependent, and we can't really see whether they are violated by the system you describe because we don't have much context.

For example:

  • We can't tell whether you have violated the single responsibility principle, because determining what is and is not a responsibility of a piece of code requires understanding how that code is specified, and how that specification is likely to change in future. If handling stock levels can change independently of how individual stock items are described, then grouping these together in the same module could well be a violation of SRP. But if both are consequences of the same specification (e.g. because you have a single supplier and the description is in the same format the supplier provides, so any change to one is likely to also involve a change of the other) then SRP is not violated here.

  • The validity of the Open/Closed Principle depends heavily on what the clients of a piece of code are, and whether they are considered part of the same module (and therefore likely to evolve together, be tested together, and so on) or different ones (at which point the stability that OCP provides can become very important), so without knowing how your book objects are actually used we can't tell whether this is violated.

  • Interface Segregation again depends on what the clients of an object are, not what the object itself does. While Christophe's answer identifies a likely violation of this, it is only actually a violation if there are separate modules in your system that would use the separated interfaces he proposes. If there is only a single module that accesses books or ebooks, and it always uses all of the facilities you describe, then there is no violation.

  • Dependency inversion requires detailed objects to depend on abstractions rather than the other way around, but all of the objects you describe have a similar level of abstraction. We'd need to see a much larger description of how your system uses these objects to know whether DIP is satisfied or not.

I've skipped Liskov Substitution out of the list above, because I really think of it as a different category. The four principles above are useful design guidelines. LSP almost always causes serious problems when it is violated. It is a much less subjective rule. But it is also dependent on the detailed behaviour of your objects. If your ebook object has valid behaviour for all of the methods included in your book objects, then LSP isn't violated. But if a client of book objects could fail due to ebook objects handling stock in an incompatible way (for example), then LSP is violated. A lot depends on what the observable side effects of your methods are, and even how they are documented as working.

Of all of them, I think LSP is the most likely to be violated in the system you describe, because I can't see a reasonable way an ebook could implement the replenishStocks() method that couldn't cause some client that isn't written with ebooks in mind to fail. And as Christophe points out, ISP is probably violated too. The others, we really don't have enough information to know.

As an aside, the SOLID principles don't contain any guidelines that are intended to promote code simplicity. For real world applications, they should always be used alongside such guidelines (and with an understanding that in many cases they will conflict with them, and that it's up to you as a system designer to work out which should take priority). Kent Beck's rules for simple design are a good starting point.

  • It is a much less subjective rule. I think this hugely depends on where you draw the line on LSP. I've seen people argue that as long as it doesn't throw an exception or otherwise break the runtime, it doesn't violate LSP, but I find that a much too strict reading of LSP. For example, implementing a method that returns void and then doesn't do anything (because the derived class has no use for the method) still means that your derived class is providing a meaningless method, which violates the spirit of LSP - but this is more subjective - or contextual - than you are suggesting. – Flater Nov 19 '18 at 7:31
  • @Flater I don't say that the original solution is a recommendnd solution, I just say that the LSP would not be broken, exactly for the reason you mention: the e-book would behave exactly as the physical books, requiring replenishment and stock management (even though it makes no sense). SO whatever the spirit, none of the 4 LSP constituents would be violated. But it's not the right approach. So please consider the proper ISP solution instead that will lead to a better design and resolve the solution as well technically as in the spirit. – Christophe Nov 19 '18 at 7:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.