Hierarchy and design patterns question

Question

I'm modeling a document class for a system. The document can be one of two types: in or out.

If the type is in, the document has a sender. The sender can be one of two types: person or company.

If the type is out, the document has a receiver. The receiver can be one of three types: person, company, department.

I'm not sure if it would be better to use a property with an enumeration for the type of document or to use hierarchy with a document base class and two classes for each type of document.

For the sender and receiver I'm not sure if hierarchy would be a good option because the three types don't have anything in common (person, company, department) and how to avoid an invalid sender.

It would be good if you can give me some advice about how to model the document class or if you can tell me about some design patterns that I should use.

Thanks in advance.

---

There are only a few differences between in and out, the same fields with the exception of sender and receiver. Also, the behavior is the same with a little changes.

There are no behavior for sender and receiver, the only they have to do is contain the correct object, for example sender can contain a person or a company but no a department because departments are not valid senders. Also, if sender contains a person, it can't contain a company because only one sender is accepted.

The main problem is how to read the sender o receiver when I get the document and I have to read that data. For example, if I have to read the sender and I use a enumeration with the kind of sender I have to do code like this if sender==person read person and assign it to a person else read a company and assign to a company. If I use inheritance how I avoid to use cast or how I know if the sender is a person or company without so much code or cast. Thanks again.

Answer 1

If you are using a language that allows objects to implement interfaces, then that would be a good way to deal with the complex type relationships.

ISender could be implemented by Person and Company. IReceiver could be implemented by Person, Company, and Department.

This way the documents could hold a reference to a receiver, even though the three types don't have anything in common.

For the two types of documents, it depends a lot on how much functionality will be shared between them. If it is none, then there is no point in having a relationship at all. If they share a lot of functionality, then it may be worthwhile to include an abstract base class to implement it. If they are completely (or almost) the same, then a single class with an in/out flag might be a good idea.

Answer 2

Personally I don't see particularly advantages in modelling as a hierarchy the document class, because the are very little differences between in and out documents. Especially considering that if

If the type is in the document has a sender.

Even if it is implicitly it has also a receiver ( you). And the same is for out document. So, as far as I can know from the information you gave, I'd use enum for distinguish both Document(in and out) and types (person, company, department).

Try to follow kiss principle whenever possible.

Anyway you have also to take in considerations the type of operations you are going to do with the documents and the what additional data the have to store. If you see that in and out documents could increase their differences while your application will grow, so introduce a hierarchy may be a good idea. (Even in this case I will keep types separated, using some enum like structure to store them)

EDIT:

Regarding your comment: maybe there are. I don't know which language are you planning to use. But, for example, with Java every entity (person, company..) could be a class implementing an interface (for example an interface call Entity). Then using generics you can instantiate your class forcing the generic type to be an implementation of interface entity. Something like:

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