Oop 国家与行为

有时对象由纯数据组成。此类对象具有字段、访问器，实际上没有其他方法

有时对象由纯行为组成。它们具有表示其状态的其他对象，或者数据作为方法参数传递。这些对象通常表示算法或某种策略

你喜欢什么样的状态/行为比率？
什么更易于维护？
什么更容易出错？

我喜欢对象（按优先级顺序）：

有关于如何使用它们的详细说明，这样您就不会达到无效状态。

• 调用方法时，如果异常状态不正确，则引发异常
• 在调用一个方法之前，有一些方法允许您断言它们处于正确的状态

当这些措施到位时，事情就更难搞砸了

---

没有行为的对象也可以是哈希表，没有状态的对象也可以是函数的集合。

我喜欢做一个或另一个的对象——要么表示有行为的对象（理想情况下，只显示void方法），要么表示纯状态（理想情况下，它是不可变的，除了维护其状态和可能的验证之外，没有代码）

第一类对象相互传递另一类对象。这与Actor模型非常接近，这样做可以解决很多问题。（如果在Java/C#中这样做，可以将接口作为“值”传递给第一类对象。）

---

我发现它是中间的物体（既是状态的，也是行为的）你会遇到问题……行为对象中的某些状态是可以的，只要它的主要目的不是被查询。

如果你设计的对象都是行为而不是状态，或者都是状态而不是行为，我认为在你的设计中有缺陷。在r中遇到这些类型的对象确实不常见如果这些不是你描述的辅助对象，而是真实世界对象的表示，那么我认为某个地方出了问题

我没有任何关于状态/行为的固定比率。我认为每个对象都有自己的形状，这在不同的对象之间可能会有很大的差异。但我认为随着时间的推移，如果你对对象进行大量研究，动词往往会比名词/形容词更多，也就是说，行为将主导状态

---

这就是我在我的程序中观察到的。

行为应该作为一个单独的类来实现只有当它是泛型的并且可以应用于不同类的对象时才是如此。如果是这样的话，你就不能选择“比率”——它仅仅取决于特定系统中泛型策略的数量

---

否则，就会出现过早泛化的情况，甚至更糟糕的是，毫无根据地违反OO原则。是的，它很容易出错。

如果对象的实现方式使其永远不会进入不一致的状态，即使出现异常，那就更好了。您所说的对于命令式OO来说是正确的。命令式OO是金标准。这并不是说它必须在任何地方使用，而是说所有东西都必须与它进行比较。如果你偏离了OO，你应该知道你这样做的目的是什么。分离状态和行为没有固有的、绝对的价值，应该应用于有利的特定情况，而不是试图满足某些指标。我认为abo当你有一个困难的功能块时，不要把它分成一个单独的协作对象，它们中的一些主要是状态，而另一些主要是行为。实际的分离取决于你所拥有的具体情况。非常非泛型。我不认为这个场景需要将行为和状态分离。复杂对象也可以分解为多个同时具有这两个属性的良好OO对象。我认为这是从错误的角度解决问题。在良好的OO中，您不需要构建对象来实现功能-您需要设计连接的objec系统在某种意义上，我同意这种分离在其他情况下可以作为副产品或折衷品发生。但这仍然是需要避免的。状态和行为的分离也可以用来实现关注点的分离。这与OOP有何矛盾？“我不明白这个场景如何需要行为和状态的分离。”当然它并不总是需要，但很容易想象它需要什么。这就是为什么我给出了这个例子。