Does OCP and DIP (from SOLID) violate YAGNI?



  • I understand that YAGNI recommends that we not allocate abstraction without need. I mean, if we don't need polymorphism at this particular moment, we shouldn't be giving up abstraction because why then? However, both OCP and DIP call on us to provide abstraction here. OCP advises that if we need to change class behavior, we could do it without changing the type, simply releasing the abstraction into a type. DIP reports directly that the details should be subject to abstraction and not vice versa.

    The abstraction may also make it necessary to test users of the type. But in java, I understand there is no need.

    So, is there any need for abstraction immediately? Should OCP and DIP follow?



  • The different design principles aim at a certain design task, and in some cases they may contradict each other.

    It may be said that the different principles of " design " are different and the right vector should be found, the most useful in this particular case: SRP - speaks of the simple decision, OCP - the insulation of module components, DIP - the " correctness " of relations between classes, a LSP - the right polymorphysis.

    One principle may lead to a breach of another. For example, any inheritance possible as a violation SPRsince a whole group of classes is responsible for one responsibility now. Monitoring DIP and OCP may result in additional stitches, i.e. interfaces/base classes in the system, which, again, would lead to a breach SRP and/or ISP

    But this relationship between principles is not fixed. For a simple case, a hierarchy of the figure for drawing is a violation SRPbecause the " drawing " in the first iteration may consist of the conclusion of the text to the console and the disguise of the information in several classes will be excessive. But as the decision is complicated, the hierarchy of inheritance will be justified from the point of view SRPsince the complexity of displaying each individual figure will be so high that the concept of " responsiveness " is also changing. If, at the outset, " one responsibility " was the display of all figures, one responsibility responsibility would now be divided into many: " Circulation " , " square display " , etc.

    The principle YAGNI (You Aren’t Gonna Need It) is a more fundamental principle (the “principle of higher order” or “ Metprinciple”) that will help to understand when to follow principles/patterns/rules and when not.

    The YAGNI principle is based on several observations:

    1. The programmers, like the people in general, are poorly predicting the future.
    2. No flexible solution will be flexible enough.

    These observations result in the following conclusions: An attempt to create a flexible solution in the early stages of development is doomed to a redesigned solution♪ This is related to the fact that, at an early stage, it is not yet known what changes in the system will be needed, and it is simply not clear where to " catch up " for future changes.

    Since we do not know what flexibility is needed at an early stage, we will not be flexible where we need to: we will offer a replacement of the data access layer, but because of the " diving abstracts " , we will still have to make a decision on a certain database, or that flexibility will never be necessary. We will create a “Freimvork” password for the command line, which will be used in one annex, and the cost of attaching it to another annex will be so large that no one will.

    Good design is a simple solution when changing requirements leads to linear labour costs.

    The most notable way to achieve this is through evolutionary design: we start from breaking the system into major components, but we don't do too much. There's no need for basic classes if there's at least two or three heirs now. Even if such heirs " may come forward in the future " , the hierarchy of types is necessary when that very future comes.

    Principle YAGNI May be expressed as follows: Extra abstract extra abstraction (and any other complication) is justified only if the value of their future allocation is significantly higher than now.

    Investments in the sound library programming interface (API) will be justified, as the cost of changes is very high. The value of the interface/base class of the annex is almost identical today or in a year.

    The solution to the problem as it comes is possible to focus on the challenges of today and avoid work that may not be needed at all.

    P.S. Well, I don't think you have a very good understanding of the principles. OCP and DIPwhich are not entirely limited to the need for inheritance.

    Here are several articles on:

    • http://sergeyteplyakov.blogspot.com/2014/10/solid.html
    • http://sergeyteplyakov.blogspot.ca/2014/08/open-closed-principle.html
    • http://sergeyteplyakov.blogspot.ca/2014/09/the-dependency-inversion-principle.html
    • http://sergeyteplyakov.blogspot.ca/2013/04/blog-post.html

    And separately, in the article http://sergeyteplyakov.blogspot.ca/2014/10/about-design-principles.html I consider the same as in this response: that blindly following the principles will lead to a redundant and difficult decision.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2