Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Deep vs. Flat Object Model [closed]

Tags:

object

oop

model

Which would you recommend - a deep objects hierarchy (where each object hold a reference to it child objects), or flat objects (where you provide services to retrieve child objects)?

Let's assume that you are creating a database management application. You will have objects such as:

  • Server
  • Database
  • Columns
  • Views

Which option would you recommend:

  1. Each Server object holds a list of Database objects. Each Database object holds a list of Columns and a list of Views, etc.
  2. Each object is a "dumb" object, holding only its own properties, and you provide a set of services to retrieve the hierarchy, such as GetServerDatabases(Server), GetDatabaseColumns(Database).
like image 533
SaguiItay Avatar asked Jan 23 '23 14:01

SaguiItay


1 Answers

If you're going on OO design principles, then both hold true. The second option is known as a coordinating object, and helps to prevent the state of your API/Core (whichever name you want) from being tampered with and breaking.

The 1st option would be how it is held internally, and you could optionally allow access to the Database's server property if you want to allow that.

My own preference would be to restrict any setters on the 4 objects, and force this through the coordinating/façade object (façade pattern). Let the Server offer its databases as a property, and so on down the chain.

As pointed out the Server.Databases property might be heavy. In which case this can be accessed via the coordinating object (the façade) instead.

So:

GetServers()
GetDatabases(Server)
GetColumns(Database)

and so on

like image 74
Chris S Avatar answered Feb 01 '23 11:02

Chris S