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:
Which option would you recommend:
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With