A lot depends on what the observable side effects of your methods are, and even how they are documented as working.
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. If your ebook object has valid behaviour for all of the methods included in your book objects, then LSP isn't violated. But it is also dependent on the detailed behaviour of your objects. LSP almost always causes serious problems when it is violated. The four principles above are useful design guidelines. I've skipped Liskov Substitution out of the list above, because I really think of it as a different category. We'd need to see a much larger description of how your system uses these objects to know whether DIP is satisfied or not. 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.ĭependency 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. 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. Interface Segregation again depends on what the clients of an object are, not what the object itself does.
#Single responsibility principle uml code#
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. 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.
But if both are consequences of the same specification (e.g. 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. 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. 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.
0 kommentar(er)
