Which SOLID principles are broken by this class diagram?

Question

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?

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.

Answer 1

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:

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.

Answer 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.