主页 / 问题 / 560468
Accepted
Мистер Фикс
Asked:2020-08-29 14:01:59 +0000 UTC2020-08-29 14:01:59 +0000 UTC

最低意识原则，什么时候可以违反？

  • 772

这是代码中此类组合的一个示例，据我所知，这违反了最少知识原则（请参阅 Demeter 法则）：

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()

但是，我注意到这种方法通常用于扩展类接口。

来自 Java 和 C# 的示例：

System.out.println()

来自 Django 的示例：

MyModel.objects.create()

所以我想知道什么时候以这种方式扩展一个类是正确的？

ооп

2 个回答

  1. 首先你需要弄清楚当一个物体把它的内部暴露在外面时，问题是什么，然后当这不是问题时就会清楚。

    封装和信息隐藏旨在简化开发。良好的设计可以让您一次专注于最少数量的概念，并在需求发生变化时将更改次数限制在最少数量的模块内。

    当一个对象将其内部暴露给外部时，这可能会导致更脆弱的解决方案。就其本质而言，类的公共接口应该更稳定，并且对客户隐藏实现细节。在这种情况下，可以在不破坏客户端的情况下更改实现。

    当实现细节以公共字段甚至属性的形式泄漏到公共接口中时，它会限制类作者更改的能力。视图代码A.B.C.D.E.Foo()的稳定性较低，因为对 5 个类中的一个进行更改很可能会破坏它。

    另一方面，并​​非每个公共财产都会透露实施细节。有时，这些属性是所解决问题的本质的一部分。例如，一个正方形有坐标和形式的反转：square.Position.X可能是合理的。

    有时，您出于其他原因不得不打破此规则，例如，在开发库时。

    任何复杂的系统都是有层次的，我们只需要将相关的概念进行分组即可。同样System.out来自 Java 世界的是一个类似的例子。我们希望将所有系统操作整合到某种外观之后，这将是一个方便的探索切入点。在这方面，我们不会转移out到另一个类，我们也绝对不会PrintStream从System.

    因此，作为结论：如果整体-部分关系是主题区域的一部分，则不违反得墨忒耳法则。在外观类的情况下并没有违反迪米特法则，其唯一任务是提供对某些对象的访问。

    但是，如果暴露的属性是将来可能会更改的实现细节，则违反了 Demeter 法则。

    • 8
  2. Best Answer

    根据常识和主题领域施加限制。

    我会写一个人。一个人，在大多数情况下，可以活动他的四肢，用他的脑袋思考，并做一些其他比较肤浅的动作。如果你正在编写一个游戏并且那里的人没有受到任何修改，那么他们应该具有与现实生活中相同的可用操作。 应该记住，对于蜂蜜。人为修改的设备或游戏 - 访问范围可以更广泛。

    一个简单的例子是человек.рука.двигать()。

    无论实现中发生什么，这样的代码都将保持有效并且不应该变成человек.ДвигатьРукой()or человек.Двигать(рука)。

    同时，人们不知道如何控制手中的特定肌肉，例如，这意味着对象必须隐藏在执行的内部。

    那些。рука.Двигать()但不是рука.мышцы[x].двинуть(y, z)。

    甚至更简单——当一个属性是强制的和不可变的，由主题区域证明——你可以引用它，否则它应该被主类隐藏。

    • 7

相关问题