simple OOP classes right approach

Question

At start, I have these classes in code and consequently tables in the database.

Person
Company
Address

Both Person and Company have an address. So I have to establish a relationship between them. Person one - Address many (let's say a person can have more than one address). I know the same address can be for two persons, but that's not important as this is not relationship critical (won't search by address).

Company has an address too. So in class Address I would have both relations to Person and Company. In code, this is not a problem, but in the desing model, it shows both foreign keys and columns, and this makes for me some ambiguity when displaying on the screen (I can hide it though).

I was thinking to create another class: CompanyAddress which will inherit Address and have only one property which will hold key to Address class)

So this is idea:

CompanyAddress : Address
{
}

and

PersonAddress : Address
{
}

So CompanyAddress and PersonAddress would inherit Address class and be used to hold relation (foreign key) to Company and Person classes. This will display in database in 2 possible ways (it can show foreign keys in same table (Address) or it can store foreign key in its own table CompanyAddress). I prefer to store in same table not to use joins.

I can choose in database to have Address table that stores also foreign keys of Person and Company (this is fine I think). Or I can have PersonAddress table which stores only key and all other fields are in Address table. I prefer first approach. Still OOP model can be different for obvious reasons since it can simplify desing model where you dont have to hide keys of Company when displaying Person address in UI design model. So you see benefit of different OOP models.

Code

public class Address
{
    public string Street  { get; set; }
    public string City    { get; set; }
    public string ZIPCode { get; set; }
    public string County  { get; set; }
}

public class Person
{
    public string Name    { get; set; }
    public string Surname { get; set; }
    // relationship here one to many with class PersonAddress 
    // note: I cannot write code as I use some third party controls
    // which code is much different for usage in relationships
}

public class Company
{
    public string CompanyName   { get; set; }
    public string CompanyNumber { get; set; }
    // relationship here one to many with class CompanyAddress 
}

public class CompanyAddress : Address 
{
    // a relation with Company class
}

public class PersonAddress : Address
{
    // a relation with Person class
}

Is this good OOP or it is a bad idea?

Answer 1

It's actually hard to say whether your object-oriented design is good or bad: At the moment all you have is some pure data objects (only setters and getters) - see Anemic Domain Model. In short: Good OOP design is when your classes do have non-trivial behavior, which helps you to deal with the cases at hand.

Please also note, that Company and Person are more likely entities (their identities matter), while Address is probably just a Value Object, and how it is stored is secondary matter.

Model (and object model is no different) can't be good or bad without relation to the problem you are solving. For one problem you may need an object for every street, and for another - everything you have added to one denormalized database table.

In a sense, object-oriented design should capture characteristics and behaviors of the domain objects and communication between objects. If all you need is CRUD (create-read-update-delete), then maybe you do not need any design or programming at all - just use some of the shelf tool to model your domain.

That said, I see you are trying to reconcile relational database with OOP. It's a big thing in itself due to OOP-relational impedance mismatch. If CRUD is almost all you need, get some ORM tool (Object-relational mapping) to take boilerplate code away.

Answer 2

The CompanyAddress and PersonAddress are good but not on the class level and certainly not as inheriting entities (no is-a relationship). They should be (link) tables keeping relations between companies and addresses and between persons and addresses respectively. Then you can do anything. They do not represent anything in the real world, you probably do not want a class for them at all.

Class Person could have a property Addresses and class Address could have a property Persons which you could populate using a query. Same for company.

Answer 3

Company has an address too. So in class Address I would have both relations to Person and Company.

Addresses should not refer to a Company or Person (but rather vice versa: a Company or Person has one primary (mailing/billing) address).

What will happen to your data model if two companies or two people share an address? You won't be able to express it, so you'll have to duplicate the address somehow.

If you resolve this issue, other problems will disappear.

Answer 4

What your doing is at this point not object-oriented at all. Don't worry, this is not a value judgement, you don't have to be object-oriented if you don't want to. If you do however, you still have work to do.

First, you are data-modeling. Having properties and relations, like you sometimes see in UML diagrams is a way of describing data not objects. You yourself said that you store these things in a database.

Object-orientation is not about data, but about behavior. You have to identify what business-functionality (not technical functionality!) you have to support, and assign those functionalities (sometimes also called responsibilities) to objects. Without business-functionality an object is not an object.