On Nov 16, 2013, at 10:01 AM, Ken Anderson <[email protected]> wrote:
> David, > > On Nov 15, 2013, at 10:34 AM, David Avendasora <[email protected]> > 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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
