Mfcttrf

I have been trying to learn Object Oriented Design, but I find it very difficult to decide where to put behavior that deals with more than one type of object.

For example, I am building a REST API, it has User and Event entities.

Users can register for events.

Where to put registerUserForEvent(String userid, String eventid) and getRegisteredEventsForUser(String userid)?

registerUserForEvent():

If I put it in User class, it will have to know about how to check an event with given String eventId exists in the DB.
Vice versa if I put it in Event class.

getRegisteredEventsForUser():
This one is even harder, as this requires a JOIN in SQL (or an aggregate pipeline in MongoDB), which will need to know the internals of both User and Event classes. This leads to breaking encapsulation right?

So, what is the best way to model this in OO?

Very often, when you have a behavior where you cannot decide which of two objects should have it, that is because either

• the two objects should actually be one object or


• there is a third object missing.

A great example is the classic "Bank account" that is so often used as an introduction to OO. In the typical example, balance is data and deposit is an operation. This leads to all sorts of problems, but the one we are focusing on here is: where do you put the transfer method? If a transfers money to b, should it be a.transfer(b, amount) or b.transfer(a, amount)? Why would a even know about b? Why would b even know about a? Why would either of the two even know how to transfer money?

However, that is actually not how banking works in real-life and is also not how banking systems are typically designed.

In the real-world, deposit is actually data (it is a transaction slip) and balance is an operation (summing up all transaction slips for one account). This is the way banking was done for hundreds of years, and it is actually also how banking systems are written.

This has some advantages for concurrency (now, both Accounts and TransactionSlips are immutable, and balance is a pure function). But, it also solves our conundrum above: neither a nor b know how to transfer money, the bank knows that. transfer is now actually new TransactionSlip(a, b, amount).

Back to your specific example: it looks like what you are missing is at least one object, possibly even two:

• 
  Registration: Encapsulates the fact of a user being registered for an event


• 
  Registry: contains all Registrations