层次结构和设计模式问题

Question

我正在为系统建模文档类。文档可以是以下两种类型之一：输入或输出。

如果类型为in，则文档有发件人。发件人可以是以下两种类型之一：个人或公司。

如果类型是out，则文档有接收者。接收者可以是以下三种类型之一：个人、公司、部门。

我不确定使用具有枚举的属性来表示文档类型是否更好，或者使用具有文档基类和每种文档类型的两个类的层次结构是否更好。

对于发送者和接收者，我不确定层次结构是否是一个好的选择，因为这三种类型没有任何共同点（个人、公司、部门）以及如何避免无效的发送者。

如果您能给我一些关于如何建模文档类的建议，或者如果 你可以告诉我一些我应该使用的设计模式。

提前致谢。

---

in 和 out 之间只有一些区别，除了发送者和接收者之外，其他字段相同。此外，行为是相同的，但有一些变化。

发送者和接收者没有任何行为，他们唯一要做的就是包含正确的对象，例如发送者可以包含个人或公司，但不能包含部门，因为部门不是有效的发送者。此外，如果发件人包含个人，则它不能包含公司，因为只接受一个发件人。

主要问题是当我收到文档并且必须读取该数据时如何读取发送者或接收者。例如，如果我必须读取发件人并且我使用发件人类型的枚举，则我必须执行这样的代码 if sender==person 读取 person 并将其分配给其他人，其他人读取公司并将其分配给公司。如果我使用继承，我如何避免使用强制转换，或者如何知道发送者是没有那么多代码或强制转换的个人或公司。再次感谢。

Answer 1

如果您使用的语言允许对象实现接口，那么这将是处理复杂类型关系的好方法。

ISender 可以由个人和公司实施。 IReceiver 可以由个人、公司和部门来实现。

这样，即使这三种类型没有任何共同点，文档也可以保存对接收者的引用。

对于这两种类型的文档，这在很大程度上取决于它们之间共享多少功能。如果没有，那么建立关系根本没有意义。如果它们共享很多功能，那么可能值得包含一个抽象基类来实现它。如果它们完全（或几乎）相同，那么带有输入/输出标志的单个类可能是一个好主意。

Answer 2

就我个人而言，我并不认为将文档类建模为层次结构有什么特别的优势，因为输入和输出文档之间的差异非常小。
特别是考虑到如果

如果文档中的类型有发件人。

即使它是隐式的，它也有一个接收者（你）。我们的文档也是如此。
因此，据我从您提供的信息中得知，我会使用枚举来区分文档（输入和输出）和类型（个人、公司、部门）。

尽可能遵循接吻原则。

无论如何，您还必须考虑要对文档执行的操作类型以及必须存储的附加数据。
如果您发现输入和输出文档在您的应用程序不断增长时可能会增加它们的差异，那么引入层次结构可能是一个好主意。
（即使在这种情况下，我也会将类型分开，使用一些类似枚举的结构来存储它们）

编辑：

关于您的评论：也许有。我不知道你打算使用哪种语言。但是，例如，对于 Java，每个实体（个人、公司……）都可以是一个实现
接口（例如接口调用实体）。然后使用泛型，您可以实例化您的类，强制泛型类型成为接口实体的实现。
像这样的东西：

public interface Entity{...}
public class Document<T implements Entity>{}

Answer 3

基本上可以归结为这一点。如果有 if 语句

if(document.IsIncoming()){
  do something
}elseif (document.SentToDepartment()) {
  do something else
}

在多个地方重复，那么最好使用某种多态解决方案（想想抽象类或接口）。发送者和接收者类型也是如此。

但是，您不需要在顶部进行子类化。您可以通过多态性将不同行为附加到单个文档类。假设传入和传出文档的打印行为不同。然后创建 IPrinter 接口并在两个类中实现它，如下所示。

public class Document
{
  DocumentType type;
  IPrinter printer;
}
interface IPrinter{
  print();
}

class IncomingPrinter :IPrinter{}

class OutgoingPrinter :IPrinter{}

每当决定要传入文档时（可能是在创建文档时），您都可以分配 IncomingPrinter。如果有多种类型的行为需要像这样分配，通常会使用工厂模式。通过这种方式，您可以将 if(doc.IsIncoming()) 语句本地化到一处。不在代码中的不同位置重复决策的好处有很多。

Answer 4

我在这里非常反对等级制度。发送者和接收者显然是具有某些行为并携带某些数据的概念。我将专注于这些职责并创建实体发送者和接收者。稍后，如果需要，可以创建这些的子类，例如 CompanySender。如果您的整个系统与发送者和接收者无关（我认为不是），那么基本上不要用发送者逻辑污染公司实体。

Answer 5

对于输入与输出文档的建模，最佳设计取决于您通常处理文档的方式。

如果您通常在编译时知道文档是否是输入/输出类型，并且除了发送者与接收者之外，还有很多共享属性和行为，那么层次结构会很好（因为您有接受 InDocument 或 InDocument 的方法）或 OutDocument 可能会在编译时解析，甚至运行时解析，具体取决于您的语言）。

另一方面，如果您的文档全部混合在一起并且您主要在运行时处理它们，那么另一个解决方案（我将很快介绍）可能会更干净。我怀疑对于发送者和接收者类型来说，这几乎肯定是正确的，这几乎肯定不保证层次结构（尽管，根据您的语言，您可能需要使用接口标记以便模拟我即将介绍的功能解决方案）。在这些情况下你想要的是一种“带有数据的枚举”。在像 F# 这样的对象函数语言中，您可以结合记录类型和判别式联合来对此进行良好的建模：

type PersonInfo = {Name:string ; Age:int}

type CompanyInfo = {Name:string ; Location:string} 

type sender =
    | Person of PersonInfo
    | Company of CompanyInfo

type DepartmentInfo = {Name:string ; Floor: int}

type receiver =
    | Person of PersonInfo
    | Company of CompanyInfo
    | Department of DepartmentInfo

type documentType =
    | In of sender
    | Out of receiver

type Document = {Type:documentType ; Title:string ; Body:string ; Date:DateTime } with 
    //example of how to process a Document using pattern matching
    override this.ToString() =
        match this.Type with
        | In(s) -> 
            match s with
            | sender.Person(info) -> sprintf "In / Person, extra info: Name = %s ; Age= %i" info.Name info.Age
            | sender.Company(_) -> "In / Company"
        | Out(r) ->
            match r with
            | receiver.Person(_) -> "In / Person"
            | receiver.Company(_) -> "In / Company"
            | receiver.Department(_) -> "In / Department"


//create a list of In and Out documents all mixed up
let documents = 
   [{Type = In(sender.Person({Name="John"; Age=3})); Title="My In Doc"; Body="Hello World"; Date=DateTime.Now}
    {Type = Out(receiver.Department({Name="John"; Floor=20})); Title="My Out Doc"; Body="Testing"; Date=DateTime.MinValue}]

//partition documents into a list of In and Out Types

let inDocuments, outDocuments = 
    documents |> List.partition (function | {Type=In(_)} -> true | {Type=Out(_)} -> false)