how serious should i take inheritance

i don't know how serious i should take inheritance..

in my application i have, as in most applications, customers, users and suppliers.

well, seems easy, but to be a stickler for details, i should do the following:

class Person {...}


class NaturalPerson extends Person {...}

class JuristicPerson extends Person {...}



class User extends NaturalPerson {...}

class Supplier extends JuristicPerson {...}

well, and what's with Customers? In my opinion they may be natural and juristic persons as well...

class JurCustomer extends JuristicPerson {...}

class NatCustomer extends NaturalPerson {...}

that'll be dumb to work with, because if i want to have all customers, i need to select the two corresponding tables...

basically i would prefer the table-per-type schema... but according to that hierarchy above, it could become a little bit complicated i think.

well, this is just an example. in many cases the hierarchy will be a lot more complex...

Solution

Unnecessary layers of abstraction add complexity without offering any benefit.

What you have to do is determine what implementation benefit can be derived from your classes sharing a common ancestor.

I think maybe the best way for you to design your app is to start with a database schema that accurately represents the entities and relationships that you are dealing with. Then create your classes to mirror that schema (table per type).

Then when considering the functionality of similar classes at that point determine if the different types would benefit from sharing a base class. For example based in this design technique you end up with a Customer and a Supplier class. Part of the requirements dictate that you need a way to get information to print a mailing label. If the process that you go through to arrive at this information is the same, it would make sense to design in an abstract class that both would then extend that would implement that method.

This would help manage copy paste coding when designing your app.