Representing database tables as objects

Question

I'm building an address book API, where a user can input multiple contact names, phone numbers, and addresses.

My database structure would be as follows:

create table user (
id int not null primary key,
first_name varchar(100) not null,
last_name varchar(100) not null,
email_address varchar(100) not null );

create table contact (
id int not null primary key,
user_id int not null,
first_name varchar(100) not null,
last_name varchar(100) not null,
mobile_phone_number varchar(10),
business_phone_number varchar(10),
organization varchar(100),
address_street_number varchar(10),
address_street_name varchar(100),
address_city varchar(100),
address_state varchar(100),
foreign key(user_id) references user(id) );

With an entity framework like JPA, I can represent each table as an object, and each column as a field in the object.

Would that be bad OO design? What are some best practices around modeling these tables into objects?

Answer 1

That isn't bad OO design. That is no OO design.

For there to be OO design you need behavior. There's no behavior being asked for here. If you had something as basic as validation logic there could be OO design. But this is just a pile of lifeless data. There's nothing for OO to do for you yet.

I know you're just trying to find a good way to model and feel like you're being pulled in different directions. To understand what is happening to you I recommend studying the object relational mismatch.

Just having a class whose fields represent database table columns doesn't mean you have a real OO object. Real OO objects have encapsulation. They hide their innards and expect you to tell them to do something rather than ask what's hidden inside.

Sure, sometimes you just need to fling some data around and can't do all that. But when you do that don't forget that what you've built is not what OO asked you to do.

Does that mean never create these data only classes? No. You often get stuck making them when you want to communicate across a boundary like a database, network, or file system. Just understand that when you see that OO ideals are bowing to practical concerns.

That said, good OO design creates many places in the code where OO ideals do not bow. Places where true objects stand proud and defend their privacy. Keep behavior logic in these places. That's when you're doing OO design.

What you've got hold of is a pattern for talking to the database called an Object Relational Map. There are other persistence patterns.

When you're ready for a more advanced way to deal with the database look into aggregate roots. They are a feature of domain driven design. They give you the freedom to think less about how the DB is structured and more about what you have to say to it.