• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Using composition instead of inheritance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using composition instead of inheritance


  • Subject: Re: Using composition instead of inheritance
  • From: Ken Anderson <email@hidden>
  • Date: Tue, 29 May 2012 12:40:29 -0500

Paul,

My first question would be - how do you actually benefit from having this data separated?  Is there a reason that you don't just create a new entity for the new project that can represent the entire organization?

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.

Ken

On May 29, 2012, at 1:16 AM, Paul Hoadley wrote:

Hello,

I'm after some general modelling advice.  I've been using inheritance for years to model app-specific versions of a framework-level Person (user) entity.  This works well enough, though it presents the same small headaches time after time for each new application.

I also have a framework-level Organisation entity to model a user's organisation.  I need to customise this for a new application, and I thought this time I would use composition instead of inheritance—I'll create a new FooOrganisation entity which has a to-one relationship to Organisation (without the inverse relationship), and then the additional attributes and/or relationships which are app-specific.

The application is still in development, but there's a demo deployment, and while I _can_ wipe the database, there are existing Organisation EOs in it, and it would be nice if I didn't have to.  I'm using migrations, so I can perform any one-off fix-ups in a post-migration step.

So, do people model like this?  Are there any pitfalls?  What's the best way to ensure referential integrity, such that Organisation and FooOrganisation remain 1-1—'owns destination' and 'propagates primary key'?  (Selecting those will require I scrap the DB and create the FooOrganisations first, won't it?)  Would dynamically adding some properties to the model at runtime be a better option here if I just want to store, say, a few limited extra attributes on an entity?


-- 
Paul Hoadley
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
  • Follow-Ups:
    • Re: Using composition instead of inheritance
      • From: Paul Hoadley <email@hidden>
    • Re: Using composition instead of inheritance
      • From: Mike Schrag <email@hidden>
References: 
 >Using composition instead of inheritance (From: Paul Hoadley <email@hidden>)

  • Prev by Date: Re: D2W: Selectors for enum types?
  • Next by Date: Re: Using composition instead of inheritance
  • Previous by thread: Using composition instead of inheritance
  • Next by thread: Re: Using composition instead of inheritance
  • Index(es):
    • Date
    • Thread