面向对象的对象交互风格编程

我注意到的一件事是,不熟悉OOP的人会被困在试图将物理世界映射到他们正在编写的代码中。你真的在乎约翰和贝蒂是人还是你真的想描绘一个银行帐户?我认为您在示例中选择的对象实际上使您更难找到问题的解决方案。

重要的是 1) 把如何转移资金的逻辑放在哪里。 2) 在哪里存储每个人有多少钱的数据。

您需要决定是否要在个人或银行客户(可能是个人、公司或其他人)的背景下讨论该问题。我猜你是在谈论一个客户,因为假设他是一个人,会有局限性和误导性。此外,银行是一个相当通用的术语,是一个有人在里面的大砖房,还是一个有几个不同页面的在线网站,做着不同的事情。 银行帐户对象可以有一个知道如何从一个帐户转移到另一个帐户的方法(可能是静态的,这取决于您决定如何存储数据以及您将要使用对象的目的)。如何转账的逻辑不属于贝蒂、约翰或银行,而是属于一个银行账户,如果涉及费用等,可以根据账户类型有特殊的逻辑。如果你把这个逻辑给银行,你最终会得到一个巨大的银行类,它有各种方法,从给客户增额到处理非常特定账户类型的资金。我的每种帐户类型都有不同的规则来处理转账。考虑一下您可能希望将转账或存款显示为待处理的时间。

如果你只是解决转移资金的问题,就不需要创建一堆对象。基于已知的需求和假定的未来需求,下面的内容将是一个不错的选择。 支票账户转账(约翰账户号、贝蒂账户号、金额)

我现在能问个问题吗?谁控制着钱?约翰决定交易金额,贝蒂,还是某个未指明的第三方?

我之所以问这个问题,是因为这里没有正确的或错误的答案,只是一个可能比其他人更灵活或更稳健的答案。如果这是现实生活中的情况,那么我会将交易建模为双方在交易开始前必须达成一致的东西,并且由花钱的人(John)发起交易。类似的回答 C类 还有“神秘人”

tx transaction_request = John.WantsToBuyFor(5);    //check if John can
if( Betty.AgreesWith( transaction_request ) )      //check if Betty wants
{
   transaction_request.FinalizeWith(Betty);        //Do it with Betty
}

以及 FinalizeWith 函数做数学运算

void FinalizeWith(Person party)
{
    requestor.cash -= amount;
    party.cash += amount;
{

当然,你可能想添加一些描述什么项目是约翰购买。

这个问题的答案是一个漫长而复杂的问题,你会从很多人那里得到零碎的答案。为什么只是零碎的?因为正确的答案几乎完全取决于系统的需求。

不过,有一个陷阱你必须确保你不会掉进 this one . 读一下你在这里得到的答案。你会得到很多好的建议。(最关注那些被投票支持的建议)一旦你读过并理解了这些建议, read Steve Yegge's rant (理解它!)也。从长远来看,这会让你头脑清醒。

我不赞成以上任何一项:)

约翰为什么付钱给贝蒂?这是一个重要的问题,因为它解释了入口点在哪里。假设约翰欠贝蒂钱,现在是发薪日。

public class John
{
    public void onPayday()
    {
        Betty.Receive(5.0f);
    }
}

当然,这是如果您想使用纯对象交互风格的方法。

不同的是,我们没有一个外部程序来协调约翰和贝蒂之间的互动。相反,我们让约翰对外部事件做出反应,并选择何时与贝蒂互动。这种风格也导致了对所需功能的非常简单的描述,例如“在发薪日,约翰应该付给贝蒂钱”

这是一个很好的例子,说明了控制反转意味着什么——对象之间是相互作用的,而不是被一些外部例程操纵。它也是一个告诉,不要问,因为对象是 告诉 彼此的事情(约翰被告知今天是发薪日,约翰告诉贝蒂接受5美元)。

这里有很多替代的解决方案。例如,

Betty.Receieves(John.Gives(5))

这假设Gives函数返回给定的数量。

tx = CashTransaction(John, Betty);
tx.Transfer(5);

这假设第一个prameter是付款人,第二个是收款人,然后您可以执行多个事务而不创建新对象。

事物可以用多种方式建模。你应该选择一个最接近你想要的模型。

纯OOP有一个特性可以帮助示例轻松通过雷达,但是 object-capability 模型使明确和集中。链接文档(“从对象到功能”(FOtC))详细讨论了该主题,但(简而言之)功能的要点是,对象影响其世界的能力仅限于其引用的对象。一开始,这似乎并不重要,但在保护访问和影响类的哪些方法在其他类的方法中可用时,这一点非常重要。

选项A)允许帐户John访问帐户Betty,而选项B)允许Betty访问帐户John;两者都不可取。有了选项C),账户访问由银行介导,因此只有银行才能窃取或伪造货币。选项D)与其他三个不同:其他选项显示正在发送的消息,而不是实现,而D)是一个方法实现,它不显示它处理什么消息,也不显示它处理什么类。D) 很容易实现前三个选项中的任何一个。

FOtC已经开始了一个解决方案,其中包括一些其他类:

• 封口机和开封机,
• 钱包,有点像账户,里面有钱,但不一定有主人。
• 薄荷糖,这是唯一能创造出正平衡钱包的东西

一个造币厂有一对封口机/开封机,每当造币厂制造一个钱包时,它就把它送给一个钱包。钱包监督平衡的变化;当减少一个平衡时,他们使用封口机,而开封机从一个钱包转移到另一个钱包。钱包可以产生空钱包。由于使用了封口机和开封机,钱包只能与同一造币厂生产的其他钱包一起使用。有人不能用自己的钱包来伪造货币;只有能接触到铸币厂的东西才能创造货币。通过限制造币厂的准入,可以防止造假。

任何有权使用钱包的人都可以通过生成一个空钱包并将钱从第一个钱包转移到其中来启动交易。然后,临时钱包可以发送给接收者,接收者可以将临时钱包中的钱转移到它拥有的其他钱包中。通过限制钱包的使用来防止盗窃。例如,银行代表客户在账户中持有钱包。由于银行只能使用客户账户的钱包和临时钱包,因此只有客户的银行才能从客户身上偷窃(尽管请注意,在银行账户之间的转账中,有两个客户可能受害,因此有两个潜在的窃贼)。

这个系统缺少一些重要的细节,例如货币当局(持有对一个或多个造币厂的引用)来创造货币。

总之,货币交易很难安全实现,因此可能不是学习OOP基础知识的最佳例子。

如果你真的想变糟,试试下面的

Person       Betty,John;
CashTransfer PocketMoney;
PocketMoney.from   = John;
PocketMoney.to     = Betty;
PocketMoney.amount = 20.00;
PocketMoney.transfer();

OOP的目的不是使代码更像书面语言,而是让对象具有不同的方法和参数,以使代码更具可读性。

所以从上面的代码,你可以看到约翰给贝蒂20美元的零花钱。代码是有意义的,允许更容易的代码可读性和可理解性。

我的投票:C。C做D做的事(例如不赔钱等)。

在这个小例子中,“银行”是一个完全有效的实体,它知道约翰和贝蒂有多少钱。约翰和贝蒂都不应该对银行撒谎。

不要害怕根据情况需要反转(或不反转)“OO”程序中的逻辑。

你应该根据你的领域建模。选项C看起来是最佳选择,因为它将事务逻辑分离到Bank\Service类中。

这是一个我作为一个新手经常与自己斗争的问题。我同意“C”似乎是最好的选择。在这种情况下,我认为最好使用“中性”实体,如“银行”。这实际上模拟了大多数重要的现实交易,因为大多数进口交易使用支票和/或信贷(中立的第三方)。

作为面向对象编程的新手,最后使用了一些面向对象编程,我认为应该是A和B。

我们关注的是人,由每个人来处理他的钱。我们不知道他是要用银行,还是直接从贝蒂那里拿现金。

您创建了一个Person类,并使用两个方法向该类添加方法:send和recieve。它还必须有一个名为balance的公共var来跟踪它们的余额。

创建两个人对象:贝蒂和约翰。使用相应的方法。像约翰一样。发送(贝蒂,5岁)。这将创造贝蒂和更新贝蒂的平衡以及。

如果他们想用银行怎么办?添加另一种方法,例如。。。转帐,转帐。

我就是这么想的。