发布于 2020-01-03 15:15:29
如果你的问题是
可从接口更新的实例变量。
是成为外在状态的候选人,而
类变量+不能从接口更新的实例变量
是否有可能成为飞重物体的固有状态,我想说的是,有时可能是这样,但不一定:
然而,这并不是一个很难的规则:您也可以有这样的要求:创建对所有客户端都有故意副作用的飞重是有意义的。例如,维基百科中的Python示例是关于不可改变的奶酪品牌,每个品牌都有固定的成本。但是,如果一个人得到一个要求改变所有品牌的成本之后,使飞行重量的物体变可能是一个可能的解决方案。
此外,别忘了飞行重量的概念是为了节省大量的内存空间。如果使内部状态共享无助于以相关的方式减少对象的数量,或者减少外部状态的组合,那么只查看实例变量的类型就没有帮助了。
另外,在尝试从其中提取一个轻量级之前,可能需要在内部对这个类进行重组,这使得只查看当前存在的实例变量或通过类接口查看它们的使用就没有意义了。
最后,让我说,当只给出类名Regular和方法名f、g和h时,这样的设计问题很少可以回答。我们需要有一些上下文,需要了解类的具体用例,然后就可以在语义的基础上决定要做什么。试图仅仅从句法的角度来处理这样的问题通常是行不通的。
发布于 2020-01-03 14:33:02
你的理解基本上是正确的。适当地使用proper模型的一个例子是Java的JTable和单元渲染器(示例)。我们的想法是有有限数量的细胞渲染器。表中的信息将传递给呈现器,以计算应该在那里执行的操作。
在本例中,所有外部状态都传递给回调方法:
Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int col) {
// .... Can set color based on row, whether the cell has focus, etc.
// .... all of that is extrinsic state
}在本例中,非常罕见的情况是,飞重具有内在状态。我认为用这种模式来理解是很重要的。然而,内在状态的例子可能包括:
它背后的整个概念是为了最小化飞行重量的实例,同时最大化它的可重用性。
在“四人帮”模式书中,他们的例子是一页上的象形文字。如果文档中的每个字符都有自己的字形对象,则呈现单个字符将是内存密集型的。在他们的例子中,他们以这样的方式分担责任:
在很多方面,这就是字体在屏幕上呈现的方式。字体定义了字符集中的每个字形,屏幕根据需要呈现这些字形。
https://softwareengineering.stackexchange.com/questions/403227
复制相似问题