Advantages of Domain object representing only elements of one type over being able to represent several different types of elements

Question

hi

1) As far as I’m aware, each domain object instance ( at BLL layer ) should completely represent an element of the domain ( an employee, book, car etc ).

So what is an advantage of having two types of domain objects, say one type representing a particular forum and other type representing a thread(s) in that forum, over having a single domain object type representing both a forum and thread(s) inside this forum?

Another example: what’s an advantage of having two types of domain objects, one representing an instance of a car, and other representing an instance of a bus, instead of having a single type of a domain object representing both a car and a bus?

2) Should domain object instance always represent an individual item of certain type, or can they also represent a group of items of same type? For example, is there a situation where a single object instance should represent a group of employees and not just a single employee?

thanx

Answer 1

To answer (1): This is a judgement call you must constantly make. Ask, are the two types of things more alike than they are different? Sometimes it could go either way, and two good programmers might decide differently. Keep inheritance in mind, which is how you can have the best of both worlds: common functionality organized centrally with all the individualism you need. This is central to oop/d.

(You might even eventually split domain item representation among multiple objects, driven by the single responsibility principal, but I wouldn't worry about that at first. One class for one domain item is a great place to start and is very straightforward.)

To answer 2: Yes, you often have domain objects represent groups of items, as well as individual items. Quite often you will have both a car object as well as a cars object, which is called a collection object.

Answer 2

A good reason two use multiple domain objects, is to better handle code like this:

if (o.VehicleType == VechileType.Car)
    DoSomthing();
else if (o.VehicleType == VechileType.Bus)
    DoSomethingElse();

These conditional statements have a way of duplicating themselves around the system and each time they can be subtly different. Using different types to represent car/bus gives all that logic a better place to go. If you don't see logic like that, then chances are you don't need to bother with the complexity of multiple types.

This article has some good examples of the replace conditional with polymorphism refactoring.