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