• 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: structure opinions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: structure opinions


  • Subject: Re: structure opinions
  • From: David Avendasora <email@hidden>
  • Date: Sat, 16 Nov 2013 11:45:20 -0500


On Nov 16, 2013, at 10:01 AM, Ken Anderson <email@hidden> wrote:

David,

On Nov 15, 2013, at 10:34 AM, David Avendasora <email@hidden> wrote:

Yeah, once you’ve abstracted the different properties and behaviors to different Roles, those can all inherit from a common Role superclass, but that is only really useful if there are attributes and relationships that you need to save in the database that the different subclasses all have in common, otherwise you are again forcing an architecture on something that doesn’t really need it, and could become a limitation in the future.


I respectfully disagree.  They at least share “Role Name” between them.  AND, if you want to iterate over roles, and add new roles in the future, it’s much more convenient to have a to-many relationship for them.

If a Role is an Interface instead of a superclass, it doesn’t stop you from iterating over an NSArray<Role> or adding new implementors in the future...

But that’s really irrelevant because you are *absolutely right* that in this situation it will be much less work, much less code, and much, much easier for the next programmer to understand what’s going on if you do things in a way that allows EOF to manage all of it. Which eliminates using an Interface here because, as you pointed out, you can’t create a relationship in an EOModel to an Interface, even if the Interface extends EOEnterpriseObject.

I often tend to 

After re-reading my email, the "But, this could be an example of too much abstraction” didn’t really carry the weight I was intending. I was meaning “But this is an obvious example of too much abstraction.”, and not only that, because of the reasons above, it pretty much proves that in the case of AccountingRole, SuperuserRole, etc, inheritance *is* the correct pattern to use, when so often, it’s not.

So, I respectfully agree. :-)

Dave

—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™
—————————————————————————————
David Avendasora
Senior Software Abuser
Nekesto, Inc.





 _______________________________________________
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

References: 
 >Re: structure opinions (From: Ray Kiddy <email@hidden>)
 >Re: structure opinions (From: David Avendasora <email@hidden>)
 >Re: structure opinions (From: Ken Anderson <email@hidden>)
 >Re: structure opinions (From: David Avendasora <email@hidden>)
 >Re: structure opinions (From: Ken Anderson <email@hidden>)

  • Prev by Date: Re: structure opinions
  • Next by Date: Re: Postgresql connection issue
  • Previous by thread: Re: structure opinions
  • Next by thread: Re: structure opinions
  • Index(es):
    • Date
    • Thread