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?

  • As well, suppose in the future I want to allow a user to add a business/organization to their address book and relate contacts to specific businesses/organizations. How would I ensure my domain objects are scalable?
    – tntenigma
    Nov 15, 2022 at 21:49
  • 1
    I assume you misspoke, but note the difference between representing the table as an object, and representing a single table row as an object. I assume you mean the latter.
    – Flater
    Nov 15, 2022 at 23:00
  • Data-centric modeling is not necessarily a bad thing when all you want to create is a simple data management application. Quite the opposite - shoehorning every system into an OO corset can overcomplicate simple tasks.
    – Doc Brown
    Nov 16, 2022 at 8:42

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.