OOP中的零行为对象-我的设计难题

#1 楼

您所描述的被称为贫血域模型。与许多OOP设计原则（如Demeter定律等）一样，仅为了满足规则而倒弯也不值得。

拥有价值袋是没有错的，只要它们不会使整个景观杂乱无章，并且不依赖其他对象来为自己做家务即可。

如果您有一个单独的类仅用于修改Card的属性，那肯定是代码的味道-如果可以合理地期望它自己照顾它们。

但是真正知道Card是哪个工作？

为什么要实施Player而不是Card.isVisibleTo(Player p)？或相反亦然？

是的，您可以尝试像这样做一样制定一些规则-例如Player.isVisibleTo(Card c)比Player（？）更高级别-但这并不是那么简单的猜测，我随着时间的流逝，它可能导致在Card和isVisibleTo类上都实现Card的糟糕的设计折衷方案，我认为这是不可行的。没有。为什么这样？因为我已经想象到Player返回与player1.isVisibleTo(card1)不同的值的可耻日子，所以我认为-这是主观的-设计上应该做到这一点。

纸牌和玩家的共同可见性最好由某些人来控制某种上下文对象-是card1.isVisibleTo(player1).，Viewport或Deal。

这不等于具有全局功能。毕竟，可能会有很多并发游戏。请注意，同一张卡可以同时在许多桌子上使用。我们应该为每个王牌成员创建许多Game实例吗？

我仍然可以在Card上实现isVisibleTo，但是将上下文对象传递给它，并使Card委托查询。编程接口以避免高耦合。

至于第二个示例-如果文档ID仅包含Card，为什么还要为其创建包装器类？

我想说的是，您需要的只是一个BigDecimal

顺便说一句，虽然Java不存在，但C＃中却有DocumentRepository.getDocument(BigDecimal documentID);。

请参阅


http://msdn.microsoft.com/en-us/library/ah19swz4.aspx
http://msdn.microsoft.com/en-us/ library / 0taef578.aspx

供参考。这是一种高度面向对象的语言，但没人能从中大做文章。

#2 楼

OOP背后的基本思想是数据和行为（基于数据）是不可分割的，并且它们与类对象的思想联系在一起。


犯了一个普遍的错误，即认为类是OOP中的基本概念。类只是实现封装的一种特别流行的方法。但是我们可以允许它滑动。


假设您有通用的纸牌游戏API。您有班级卡。现在，此类卡需要确定对玩家的可见性。


GOOD HEAVENS NO。当您在玩Bridge时，您是否该问七只心，何时该将假人的手从只为假人知道的秘密更改为所有人都知道？当然不是。



一种方法是在Card类上使用boolean isVisible（Player p）。
另一种方法是使用boolean isVisible（Card c） ）放在Player类上。


两人都很恐怖；不要做任何一个。玩家和纸牌都不负责实施Bridge的规则！


相反，我选择了第三个选项，其中有一个Viewport类，给定一个Player和一张牌列表，可以确定哪些牌可见。


我以前从未玩过带有“视口”的卡片，所以我不知道该类应该封装什么。我玩过带有几副纸牌，一些玩家，一张桌子和一副Hoyle的纸牌。


但是，这种方法抢夺了Card和Player类可能的成员函数。


好！


一旦完成了除卡片可见性之外的其他工作，您将剩下Card和Player类，这些类仅包含数据，因为所有功能都是在其他类中实现的，这些类大多是带有没有数据，只有方法，例如上面的视口。这显然与OOP的基本思想背道而驰。


没有; OOP的基本思想是对象封装了它们的关注点。在您的系统中，卡并不太在乎。也不是玩家。这是因为您正在准确地建模世界。在现实世界中，与游戏相关的纸牌属性极其简单。我们可以用从1到52的数字替换卡片上的图片，而无需很大程度地改变游戏的玩法。我们可以用标有北，南，东和西的人体模型代替这四个人，而无需大幅度改变游戏的玩法。玩家和纸牌是纸牌游戏中最简单的东西。规则是很复杂的，因此代表规则的类就是应该出现复杂性的地方。

现在，如果您的玩家之一是AI，则其内部状态可能会非常复杂。但是，人工智能无法确定它是否可以看到卡片。规则决定了这一点。

这就是我设计系统的方式。

首先，如果游戏中有多个卡组，则纸牌会非常复杂。您必须考虑以下问题：玩家可以区分相同等级的两张卡吗？如果第一个玩家玩了七个心中的一个，然后发生了一些事情，然后第二个玩家玩了七个心中的一个，那么三个玩家可以确定它是相同的七个心吗？请仔细考虑这一点。但是除了这种担心，卡片应该非常简单。它们只是数据。

接下来，玩家的本质是什么？玩家消耗一系列可见的动作并产生一个动作。

规则对象是协调所有这些的对象。规则产生一系列看得见的动作并通知玩家：


玩家一，十个心已被玩家三交给了。
玩家二，一张卡片已由第三名玩家移交给第一名玩家。

然后要求玩家采取行动。


第一，你想做什么？
玩家一说：高音fromp。
第一人，这是非法动作，因为高音的fromp产生了无法防御的诱惑。
第一人，你想做什么？
玩家一说：丢掉黑桃皇后。
玩家二，丢掉黑桃皇后。

以此类推。将您的机制与策略分开。游戏的策略应封装在策略对象中，而不是纸牌中。卡只是一种机制。

#3 楼

您认为数据和行为的耦合是OOP的中心思想是正确的，但是还有很多。例如，封装：OOP /模块化编程使我们能够将公共接口与实现细节分开。在OOP中，这意味着数据永远不应公开访问，而只能通过访问器使用。按照这个定义，没有任何方法的对象确实是没有用的。

除了访问器之外没有其他方法的类本质上是一个过于复杂的结构。但这还不错，因为OOP使您可以灵活地更改内部细节，而结构没有。例如，代替将值存储在成员字段中，可以每次重新计算它。或更改支持算法，并且必须跟踪其状态。

虽然OOP具有明显的优势（尤其是相对于普通过程编程而言），但为“纯” OOP。有些问题无法很好地映射到面向对象的方法，而其他范式则更容易解决。遇到此类问题时，请不要坚持使用劣等方法。


请考虑以面向对象的方式计算斐波那契数列。我想不出一个明智的方法。简单的结构化编程为该问题提供了最佳解决方案。

您的isVisible关系属于这两个类，或者都不属于这两个类，或者实际上属于上下文。无行为记录是功能或过程编程方法的典型代表，似乎最适合您的问题。

static boolean isVisible(Card c, Player p);

没问题，

Card没问题，没有超出rank和suit访问器的方法。

#4 楼

OOP背后的基本思想是数据和行为（基于数据）是不可分割的，并且它们与类对象的思想联系在一起。对象具有与之配合使用的数据和方法（以及其他数据）。显然，根据OOP的原理，只是数据（如C结构）的对象被视为反模式。 （...）这显然与OOP的基本思想背道而驰。


这是一个棘手的问题，因为它基于很多错误的前提：


OOP是唯一有效的编写方法的想法代码。
OOP是一个定义明确的概念。它变得如此流行，以至于很难找到两个人可以就OOP的内容达成共识。
OOP是关于绑定数据和行为的想法。
一切都是/应该是抽象的想法。

我不会多谈＃1-3，因为每个人都可以产生自己的答案，并且会引起很多基于观点的讨论。但是我发现“ OOP是关于耦合数据和行为”的想法特别麻烦。它不仅导致＃4，而且还导致一切都应该是方法的想法。

定义类型的操作与使用该类型的方式之间存在差异。能够检索i元素对于数组的概念至关重要，但是排序只是我可以选择处理的许多事情之一。排序不需要是“仅创建一个仅包含偶数元素的新数组”的方法。

OOP是关于使用对象的。对象只是实现抽象的一种方法。抽象是一种避免代码中不必要耦合的方法，而不是最终目的。如果您仅通过套房和等级的值来定义卡的概念，则可以将其实现为简单的元组或记录。没有任何其他代码部分可以依赖的非必需细节。有时您根本没有什么可隐藏的。

您不会将isVisible用作Card类型的方法，因为对于您的卡片概念来说，可见并不是必需的（除非您有非常特殊的卡片，它们可能会变成半透明或不透明...）。它应该是Player类型的方法吗？好吧，这可能也不是球员的素质。它应该是某些Viewport类型的一部分吗？再次取决于定义视口的方式以及检查卡可见性的概念对于定义视口是否必不可少。

isVisible很可能应该只是一个自由功能。

#5 楼

显然，根据OOP的原理，只是数据的对象（如C结构）被视为反模式。


不，它们不是。 Plain-Old-Data对象是一个完全有效的模式，我希望它们在任何处理数据的程序中都需要在程序的不同区域之间进行持久化或通信。

虽然您的数据层在从Player表中读取数据时可能会假装完整的Players类，但它可能只是一个通用的数据库，返回带有表中字段的POD，这它传递到您程序的另一个区域，该区域将播放器POD转换为具体的Player类。

使用数据对象（无论是键入还是未键入）在您的程序中可能没有意义，但这样做没有意义使它们成为反模式。如果它们有意义，请使用它们，否则请不要使用。

#6 楼

我个人认为域驱动设计有助于使这个问题更清晰。我问的问题是，我该如何向人类描述纸牌游戏？换句话说，我在建模什么？如果我要建模的东西确实包含“视口”一词和与其行为相匹配的概念，那么我将创建视口对象并使其在逻辑上应做的事情。

如果我不这样做的话我的游戏中没有视口的概念，我认为这是我所需要的，因为否则代码“感觉不对”。对于将其添加到我的域模型中，我三思而后行。

模型一词意味着您正在构建事物的表示形式。我警告不要放置一个代表抽象内容的类，而不是要代表的东西。

我将进行编辑以补充说，在代码的另一部分中可能需要视口的概念，如果您需要与显示器连接。但是用DDD术语来说，这将是基础架构方面的问题，并且将存在于域模型之外。

#7 楼

我通常不做自我宣传，但是事实是我在博客上写了很多有关OOP设计的文章。总结几页：您不应该从类开始设计。从接口或API以及形状代码开始，有更大的机会提供有意义的抽象，适合规格并避免使用不可重用的代码来膨胀具体的类。

这如何应用于Card-Player问题：创建一个如果将ViewPort和Card视为两个独立的库，则Player的抽象是有意义的（这意味着Player有时不带Card使用）。但是，我倾向于认为Player可以容纳Cards，并应该为它们提供Collection<Card> getVisibleCards ()访问器。就创建可理解的代码关系而言，这两种解决方案（ViewPort和mine）都比提供isVisible作为Card或Player的方法要好。

类外的解决方案要好得多， DocumentId。几乎没有动机使（基本上是整数）依赖于复杂的数据库库。

#8 楼

我不确定眼前的问题是否在正确的水平上得到了回答。我曾敦促论坛中的智者在这里积极思考问题的核心。

U Mad正在提出一种情况，他认为按照他对OOP的理解进行编程通常会导致问题。

我认为这个话题与是否要在Card vs Player中定义isVisible略有关系。这只是一个示例，尽管很幼稚。

尽管如此，我还是请有经验的人来看一下眼前的问题。我认为，U Mad提出了一个很好的问题。我知道您会将规则和有关的逻辑推到自己的对象上。但据我了解，问题是


是否可以使用简单的数据持有人构造（类/结构；我不在乎它们针对此问题建模）真的没有提供太多功能吗？
如果是，对它们进行建模的最佳或首选方法是什么？
如果没有，我们如何将这个数据计数器部件合并到更高的API类中（包括行为）？

我的观点：

我认为您是在问以下问题：在面向对象的编程中很难做到的粒度。以我的少量经验，我不会在模型中包括一个本身不包含任何行为的实体。如果必须的话，我可能已经使用了一种结构，该结构旨在保留这种抽象，而不像具有封装数据和行为的类的类。

#9 楼

OOP中常见的混乱根源在于以下事实：许多对象封装了状态的两个方面：它们所了解的事物以及有关它们的事物。关于对象状态的讨论经常忽略后一个方面，因为在对象引用混杂的框架中，没有通用的方法来确定任何有关其引用曾经暴露于外界的对象可能了解什么。

我建议使用CardEntity对象将卡的那些方面封装在单独的组件中可能会有所帮助。一个组成部分与卡上的标记有关（例如“钻石王”或“熔岩爆炸；玩家有AC-3闪避几率，否则会受到2D6伤害”）。一个可能与状态的独特方面有关，例如位置（例如，它在甲板上，在Joe的手中或在Larry面前的桌子上）。可能涉及三分之一的人可以看到它（也许没有人，也许一个玩家，或者也许很多玩家）。为了确保所有内容保持同步，可能不会将卡的位置封装为简单字段，而是将其封装为CardSpace对象；将卡移动到某个空间时，可以给它一个适当的CardSpace对象的引用；它将把自己从旧空间中移出并放到新空间中。）

分别封装“谁知道X”和“ X知道”应该有助于避免很多混乱。有时需要小心避免内存泄漏，尤其是在有许多关联的情况下（例如，如果新卡可以存在而旧卡消失了，则必须确保不要将应丢弃的卡永久地附着在任何长期存在的物体上） ），但是如果对对象的引用的存在将构成其状态的相关部分，则对象本身明确地封装此类信息是完全适当的（即使它将实际管理它的工作委派给其他某个类）。 />

#10 楼

但是，这种方法抢夺了Card和Player类可能的成员函数。


那不好/不明智的建议是什么？

要使用与您的卡示例类似的类比，请考虑一个Car，一个Driver，并且需要确定Driver是否可以驱动Car。

确定，所以您决定您不希望Car知道Driver是否具有正确的车钥匙，并且由于某些未知原因，您还决定不希望Driver知道Car类别（您并未充分充实此知识）以及您最初提出的问题）。因此，您有一个中间类，类似于Utils类，其中包含带有业务规则的方法，以便为上述问题返回boolean值。

我认为这很好。中级班级可能现在只需要检查车钥匙，但是可以重构以考虑驾驶员是否在酒精的影响下或者在反乌托邦的未来拥有有效的驾驶执照，以检查DNA生物特征。通过封装，将这三个类并存在一起确实没有什么大问题。