对于包含以下对象的对象,是否有名称或特定规则...诸若此类。我正在使用一个复杂的系统,它通常有5-10层深的对象。我听到为什么这样做的一个原因是一次性将大量数据从服务器传递到客户端,有没有更好的方法来做到这一点?
编辑:它似乎是几个反模式的组合。域模型应该被清理掉,并且以下反模式是有问题的: Train Wreck Pattern和Everything but the kitchen-sink map
发布于 2012-11-05 16:55:47
这看起来像是一个坏了的域模型(不是反模式名称,BTW :)它源于这样一种错觉,即存在定义良好的域模型。在现实中,问题领域的一些方面可以被优雅地建模,但在更精细的细节级别上,存在异常时的异常和特殊情况下的特殊情况,每种情况都特定于单个服务方法,这会破坏这种优雅。
许多嵌套对象的出现通常是一个连续过程的结果,这个过程将域模型“磨细”到更细的粒度,希望每个实例变量都可以在不同的上下文中重用。有一个转折点,重用每个域属性的教条命令式就不再有意义了。
我走出这一困境的方法是不再试图创建一个放之四海而皆准的领域模型,而是使用专门为每个服务调用设计的对象。这些对象可能依赖于一些定义良好的域对象,但可以单独添加任何特定的信息,并且以不会干扰其他服务调用的方式添加。
发布于 2012-11-05 16:51:09
我不知道这种对象树的名称。但是一个众所周知的反模式是火车残骸模式,当代码使用过多的方法链接时就会发生这种情况。
objA.getChildB().getChildC().getChildD()....getChildZ().performSomeAction();这是一个很好的经验法则,将所有
.getChildC().getChildD()....getChildZ().performSomeAction();转换为一个方法
objA.getChildB()让我们将此方法称为performSomeActionDeepDownTheObjectTree()。
发布于 2012-11-05 16:53:32
这个术语是“面向对象的”,在这个术语中,您通过定义对象类将大型复杂问题分解为较小的问题,每个对象类都封装了问题的一小部分。对象交互的方式是通过消息传递,对象通过从它们所包含的对象开始查找要向其传递消息的其他对象。
问题越大、越复杂,将其分解成可管理的部分需要做的工作就越多,因此得到的对象层就越多。有时,小而简单的问题会被严重分解为大量对象,但这并不会使面向对象本身成为反模式。
主要问题很简单,数据对象通过嵌套以及包含不相关的数据变得太大。例如:你正在对鸟类进行排序,而不是一个简单的鸟类对象,你会收到一个对象鸟,包含羽毛,嘴,possibleParasites,空气,possibleHousesNestsCanBeIn和foodTypes,食物类型包含水果,昆虫,蠕虫,种子,种子包含橡树,榆树,刺,possibleAnimalsThatCanEatSeeds等--
Everything but the kitchen-sink map反模式可能是最合适的。
给出了一个具有许多复杂规则的复杂流程,所有东西(业务逻辑、相关和不相关的过程等)都被推入地图中。
解决此问题的最好方法是使用过滤操作,其中您指定了一个强类型接口,如interface BirdList extends Iterable<Bird> {},查询系统提供了该接口的一个实现,该实现仅有足够的数据来支持该接口。
您的应用程序接口可以提供许多不同的接口,如BirdList和BirdFeedingHabitMap、BirdNestingHabitMap等。客户端可以提供所需的接口列表,查询系统会分析这些接口,获取数据,并使用proxy classes组装一个以类型安全的方式公开查询结果的实现类。
https://stackoverflow.com/questions/13228617
复制相似问题