【问题标题】:When are classes too similar什么时候类太相似
【发布时间】:2017-06-27 12:41:46
【问题描述】:

我想根据 POS 系统中的销售数据制作报告。

所以,我有一个 ReportGenerator 有一个 List <Ticket> Ticket 类表示收银机中的注册。这可以是 SalesTicket (DirectSalesTicket, InvoiceSalesTicket,...) 或 CashRegisterMovementTicket,用于登记在没有出售的情况下离开或进入收银机(例如,将钱存入银行)。

InvoiceSalesTicket 有一个 invoiceNumber,而 DirectSalesTicket 没有。所以我可以接受 2 个不同的课程。

对于CashRegisterMovementTicket,我可以创建 2 个类(CashInRegisterMovementTicketCashOutRegisterMovementTicket),它们是 CashRegisterMovementTicket(这是一个 Ticket)所固有的,代表添加到收银机的钱或被拿走的钱出登记册。 这将产生 3 个类,它们在内部并没有真正的不同。

当我想生成一份包含所有从收银机中取出的钱的报告时,我可以只使用 List <Ticket> 并只使用 CashOutRegisterMovementTicket 类型的钱。

另一个例子:

SalesTicket 拥有List <SalesLine>

一些报告基于具有礼券的SalesTicket 所以我有NormalSalesLineGiftCertificateSalesLine,它们都是SalesLine 固有的,但在内部它们是相同的。

感觉我有很多有时非常相似的课程。 我错过了什么?

【问题讨论】:

  • 如果你在它们之间复制测试,你会知道你的类的行为太相似了。

标签: oop design-patterns language-agnostic


【解决方案1】:

我认为您的方法很好,但是如果您只有一个带有 TransactionType 属性(发票、直接销售、现金等)的 SalesTicket,那么您可以在报告中使用该属性进行显示或过滤。

如果您有一些在各种 SalesTicket 类型中以不同方式实现的抽象方法(例如 CalculateTax()...),那么您就有充分的理由使用多种类型。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2010-10-03
    • 1970-01-01
    • 2021-06-24
    • 2010-12-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-17
    • 1970-01-01
    相关资源
    最近更新 更多