CODEWITHSUNDEEP
oop
MHogge
MHogge

Reputation: 5196

What is, according to OOP, the way to handle relationship in models that has to be persisted on database?

This question is about OOP principles and not about personnal opinions.

If we have an object A that has a relationship to an object B, C and D. And all those objects need to be persisted in an NoSQL (or any object oriented database), how should I write my Object?

With ids as relationships like this:

public class A {
    String idOfB, idOfC, idOfD;
}

And the object A can be directly created after being retreived from the database.

Or with Objects as relationships like this:

public class A {
    B instanceOfB;
    C instanceOfC;
    D instanceOfD;
}

Where this will need more work to get it from the database (first getting A, then B, C and D).

The first solution needs less work on database but it does not seems to respect the OOP principles, or am I wrong? The second solution needs more work on database but is then easier to work with on the logic layer.

Upvotes: 0

Views: 130

Answers (2)

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

The most important principles of OOP are:

  • Encapsulation and Information Hiding: tells us that the internal structure of the object, the variables it contains and their types should be hidden. Basically it says there should be no getters or setters.

  • Strong Cohesion inside the object: tells us that members (variables and methods) of an object should be about the same thing, and should be interdependent. They should depend on each other.

  • Weak Coupling with other objects: tells us that other objects should have as few dependencies as possible to the object. They shouldn't know whats behind the object.

  • And of course, an object and its methods should be about some aspect of the business domain. They should avoid having technical parts.

None of this tells you how the object on the inside would look like, or what variables you define inside the object. Frankly, instance variables of an object in object oriented programming is a detail. It is not important.

So my answer is, although you should of course make the internals of an object easy to understand and pretty, it is of no consequence for object-orientation.

Your actual design should come down to what responsibilities class A has, and would it need a reference to those other objects to fulfill those responsibilities?

Upvotes: 2

Duloren
Duloren

Reputation: 2711

The object structure must be designed to meet the object planned responsibilities.

If the object is designed to provide persistence its structure should be designed to improve the persistence.

If the object is designed for business logic processing its structure must be designed for it as well.

Usually the problem is that we have objects with mixed responsibilities, for instance business logics and persistence features. Of course this mixed approach has pros, like writability, but also has weakness like that ones you shown. The lesson is that Don’t expect to find a single approach that has only positive aspects. The funny part is know different approaches to be able to assign properly responsibilities for classes and design structures that makes the implementation easier.

Upvotes: 1

Related Questions