Re: Using composition instead of inheritance
Re: Using composition instead of inheritance
- Subject: Re: Using composition instead of inheritance
- From: Mike Schrag <email@hidden>
- Date: Tue, 29 May 2012 18:25:19 -0400
In the absence of the fancier solution (something like partial entities), I think I would make an app variant of the entity (where the class of the app one extends the class of the framework one) and model-rewrite the non-app variant to be the app variant.
ms
On May 29, 2012, at 6:22 PM, Paul Hoadley <email@hidden> wrote:
> Hi Ken,
>
> On 30/05/2012, at 3:10 AM, Ken Anderson wrote:
>
>> My first question would be - how do you actually benefit from having this data separated?
>
> I don't. It's just a side effect of wanting to have an app-specific EO based on a more general framework-level EO.
>
>> Is there a reason that you don't just create a new entity for the new project that can represent the entire organization?
>
> Just code/entity reuse. I already have a framework-level Organisation entity. It's just that different applications want to be able to hang different attributes and relationships off it.
>
>> If the reason is that you have code that you would typically use in more than one project, I would consider building that into POJOs . In general, I find that the benefits of splitting up entities (either through inheritance OR composition) seldom outweighs the benefits of having them together, unless there are some circumstances that totally warrant it. If you could provide more information on the perceived benefits, people might be able to help you better.
>
> It's basically the exact scenario described in the Javadocs for Mike Schrag's partial entities:
>
>> A very common case where this becomes useful is that of a Person entity. Person is an entity that is used in many different scenarios, each of which requires additional attributes and relationships. For instance, you may have a task management application and you want to embed your calendaring framework into it. The common Person base entity may have "username" and "password" attributes, the tasking application may add an "activeTasks" relationship, and the calendaring framework may add a "scheduledEvents" relationship as well as "dayStartTime" and "dayEndTime" attributes. Note that partials are not designed to address the issue of "roles," where different people in the system may have different roles at different times. Partial entities are designed to address the issue of combining high level modules together to form more complex static entity declarations.
>
>
> That's precisely the problem I'm trying to solve. Until now I've done it via inheritance. I was going to see if composition was any easier, but after diving into it, it seems to be about as hairy as inheritance, just in different places. What I settled on was adding a new column to the Organisation table using a migration, and adding a matching attribute to the model at application startup. Apart from not having the convenience of the Velocity template methods, it certainly seems to work fine.
>
> I'm still interested to know what other people are doing, though. Given the problem described by Mike above, how are people solving it?
>
>
> --
> Paul.
>
> http://logicsquad.net/
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden