Relations between classes

Question

I have four classes:

• Employee - contains only fields that hold informations about particular employee

• EmployeeGroup - contains only fields which describe type of jobs employee can do, each employee belongs to one of the EmployeeGroup classes.

• EmployeeDBase - contains methods for adding or getting employee and employeegroup from database.

• EmployeeForm - uses EmployeeDbase methods to get or add Employee or EmployeeGroup fields to database. It also has it's own methods for displaying informations in form.

I think relation between Employee and EmplyeeGroup is agregation and between EmplyeeForm and EmployeeDBase dependancy. Is there any othere relations Employee and EmployeeForm, Employee and EmplyeeDBase (because both are working with Employee objects).---

Answer 1

Your question sounds a bit... theoretical. Almost like homework.

For what it's worth, I think that you shouldn't confuse the Employee & EmployeeGroup classes - which are clearly representations of real-world entities, and EmployeeDBase and EmployeeForm which are software artefacts internal to your application.

Answer 2

Generally agree with @Benjol. There are two different kinds of relations here. Employee <-> EmployeeGroup is a "domain" relation, i.e. reflects rules and characteristics of the problem space. It's therefore most appropriate to model as a standard association - many:1 if an employee can be a member of one group only, many:many otherwise. To be honest, I wouldn't get hung up about aggregation. The cardinality is more important.

The other relations are architectural rather than domain-sourced. I would document that separately - preferably by reference to one or more architectural patterns. Take a look at Martin Fowler's catalogue for good examples.

Finally, two observations:

1. From your description it looks like the design has Employee & EmployeeGroup as simple value objects with all business logic in the EmployeeForm and EmployeeDBase. I'm generally suspicious of moving domain logic out of the domain classes. There are times when it's justifiable - usually for really simple/quick hack systems. Anything that has any significant domain logic - and/or is expected to have a non-trivial lifespan - is usually easier to maintain if the domain logic is better encapsulated with the domain classes instead of being bound up in ui or db layers. (see Eric Evans' "Domain Driven Design").
2. "EmployeeGroup" isn't the most informative name. From your description it would be better named "EmployeeRole" or something similar. Looks like that's defined in the book however, so not something you could change.