The principle of minimum awareness when you can break it?



  • This is the example of a combination in the code I understand violates the principle of minimum awareness (Principle of Least Knowledge) https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%94%D0%B5%D0%BC%D0%B5%D1%82%D1%80%D1%8B 😞

    class A:
    
    def method1(self):
        pass
    
    def method2(self):
        pass
    
    def method3(self):
        pass
    

    class B:

    def __init__(self):
        self.a = A
    
    def method1(self):
        pass
    

    b = B()
    b.a.method1()

    However, I noticed that this approach is often used to expand the class interface.

    Example from Java and C#:

    System.out.println()

    Example from Jango:

    MyModel.objects.create()

    That's interesting knowing when expanding the class is how you feel right?



  • To begin with, we need to figure out what the problem is when one object displays its internalities outside, and then becomes clear when it is not a problem.

    Incorporation and concealment are aimed at facilitating development. http://sergeyteplyakov.blogspot.com/2013/01/blog-post_29.html It is possible to focus on a minimum number of concepts at one point in time and limits the number of changes to the minimum number of modules in case of changes in requirements.

    When the object displays its internalities outside, it can lead to a more delicate solution. In its nature, the open class interface should be more stable and the details of implementation hidden from its clients. In this case, implementation may be replaced without disrupting the work of clients.

    When the open interface examines the details of implementation, in the form of open fields or even properties, this limits the ability of the author of the class to change. Type code A.B.C.D.E.Foo() has low stability, as changes in one of the five classes are likely to break it.

    On the other hand, not any openness reveals the details of implementation. Sometimes such properties are part of the very essence of the problem. For example, the square has the coordinates and treatment of the species: square.Position.X It could be justified.

    Sometimes, this rule has to be violated for another reason, for example in the development of libraries.

    Any complex system is hierarchical and we simply need to group the associated concepts. Same. System.out Java is such an example. We want to merge all the system operations behind some facade that will be a convenient entry point for the study. In this regard, we are not going to move out In another class, and we certainly don't duplicate surgery. PrintStream in class System

    So, as a conclusion: The Demetres law is not violated if the whole-part ratio is part of the subject area. The Demetres Act is not violated in the case of facade classes whose whose sole purpose is to provide access to certain objects.

    But the Demetres Act is violated if the properties displayed are the details of implementation that may change in the future.




Suggested Topics

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