Modelling patterns part 2

First issue here is about an actual pattern. It could be name as Reservation pattern. It deals with two event objects: reservation and participation. In many cases of participation to an event is quite simple a capacity reservation object with only one attribute -time.

In most cases my recommendation is to combine these two events. This means theoretically that we interpret that the participation event is created before it actually happens. This participation will now housing also the attributes of reservation. This is a very effective simplification with no drawbacks. This way we can save one class and three associations and that is a lot!

This solution can be applied to variety of participation events like participations to a flight, a concert, a play, a party and it can be extended to cover even a stay in a hotel.

There is also a other issue that want to take up with you. This is more of a fragment of almost every business domain model. I will call this “person- organisation” pattern. In my very first implemented domain model in Finnair 1994 I was so inexperienced and at the beginning of my OO learning curve that I created the following class model:

and it proved to be inadequate  as soon as the application was taken to production and almost first user came and asked how do I put Nokia here!

of course the far more correct model is the following:

Here a bit more elements than just the role organisation.