In my example, I’m “observing” the Company objects and reacting. That is valid in certain scenarios.
No, I don’t think so.
Where in my example is Company coupled to Employee?
Message excluded from import.
how?
Message excluded from import.
Message excluded from import.
Message excluded from import.
that’s telling Company to let me know when it’s going to be destroyed. It’s the observer pattern. Company knows someone needs to be told about it… but it doesn’t know nor needs to know who or for what.
Anything in code that deletes a company will also, synchronously, delete all employees
exactly. And I don’t think that’s a problem. I think the boundary exists.
Message excluded from import.
If different teams are responsible for companies and employees packs, they can continue working independently.
the team responsible for companies doesn’t need to warn the other team if they change their interface… unless Company stops supporting before_destroy hooks, of course. But that’s public API.
I completely understand how this can still feel “dirty” in some way… but I think it’s “clean enough” for most situations.
Message excluded from import.
I think the main benefit is it avoids the has_many and the main benefit of that is it avoids the temptation of traversing the object graph “in the wrong direction”. But yeah, it leads to N+1’s unless you take the time to re-think how you query collections.
Message excluded from import.
Maybe that’s not visible in the example from Simon, but inverse_of was added to AR to avoid loading objects from the DB if they were already loaded in memory by a previous query. So I guess that’s what’s <@U723PSM8PD2> was referring to.
Message excluded from import.
Message excluded from import.