Object-oriented – Domain Models (PHP)

domain-driven-designdomain-modelobject-orientedobject-oriented-designPHP

I have been programming in PHP for several years and have, in the past, adopted methods of my own to handle data within my applications.

I have built my own MVC, in the past, and have a reasonable understanding of OOP within php but I know my implementation needs some serious work.

In the past I have used an is-a relationship between a model and a database table. I now know after doing some research that this is not really the best way forward. As far as I understand it I should create models that don't really care about the underlying database (or whatever storage mechanism is to be used) but only care about their actions and their data.

From this I have established that I can create models of lets say for example a Person an this person object could have some Children (human children) that are also Person objects held in an array (with addPerson and removePerson methods, accepting a Person object).

I could then create a PersonMapper that I could use to get a Person with a specific 'id', or to save a Person.

This could then lookup the relationship data in a lookup table and create the associated child objects for the Person that has been requested (if there are any) and likewise save the data in the lookup table on the save command.

This is now pushing the limits to my knowledge…..

What if I wanted to model a building with different levels and different rooms within those levels? What if I wanted to place some items in those rooms?

Would I create a class for building, level, room and item

with the following structure.

building can have 1 or many level objects held in an array level can have 1 or many room objects held in an array room can have 1 or many item objects held in an array

and mappers for each class with higher level mappers using the child mappers to populate the arrays (either on request of the top level object or lazy load on request)

This seems to tightly couple the different objects albeit in one direction (ie. a floor does not need to be in a building but a building can have levels)

Is this the correct way to go about things?

Within the view I am wanting to show a building with an option to select a level and then show the level with an option to select a room etc.. but I may also want to show a tree like structure of items in the building and what level and room they are in.

I hope this makes sense. I am just struggling with the concept of nesting objects within each other when the general concept of oop seems to be to separate things.

If someone can help it would be really useful.

Many thanks

Best Answer

OOP isnt meant to just plain "seperate things". It's more about organization and intent and reusability (when appropriate). Take a look at Domain Driven Design (DDD). Specifically, identifying where your "Value Objects" are, your "Entities" are and which "Services / Factories / Repositories" are needed to support them to get you where you need to be.

In answer to your qeustion:

Would I create a class for building, level, room and item with the following structure

-Yes, it seems those would be your Models

building can have 1 or many level objects held in an array level can have 1 or many room objects held in an array room can have 1 or many item objects held in an array

-That sounds right, the Building then would be your Entity, because each building is unique and has a distinct existance, as opposed to an "item" or "room" which have a clearly defined value, but no distict existance other than it's uniqueness to who owns it.

and mappers for each class with higher level mappers using the child mappers to populate the arrays (either on request of the top level object or lazy load on request)

-This is where you're going to want expand a bit. Basically, you're going to want to create repositories / factories which will be able to fetch and load your "entities" with data. This might be what you are referring to as "Mappers", but when I hear mappers I think of "Active Record's". which are objects which save and load themselves and pretty much are 1-1 with the database. With that concept, breaking out the core "properties" per intent can become messy (it probably works for some).

Here are some good resources which should aid in your development.

Check out Domain Driven Design Concepts, there are a few Moguls out there which you'll come across very quickly which will offer you detailed insight into the theories at hand. Here are some links to get you started:

this is a pretty brief explanation: http://mattpeters.net/2009/03/24/domain-driven-design-part-1-introduction-and-entities/

this one has the cool domain name and turns out to be a great resource: http://domaindrivendesign.org/

Related Solutions

Object-Oriented Design – Use of Association, Aggregation, and Composition

The distinction between association, aggregation and composition as you describe it is a legacy going back to the old times of manual memory management. For example in C++ the memory used by objects has to be manually released and it is thus paramount to carefully design the lifecycle of composed objects. While the distinction between aggregation and composition is still being taught by many text books, it is essentially irrelevant when programming in environments with automatic memory management. If you have garbage collection all of them are just composition, period.

Encapsulation on the other hand is a much more general principle than what you describe. It is foremost the idea of bundling data and the functions that operate on this data in one module. One way to implement this is by keeping the state of the module private and expose changes to that state through public services. So client cannot access the state on their own but have to tell the module their intend by sending messages. So encapsulation is not limited to objects but applies to services as well. Actually, one way of looking at objects is to look at them as services.

Here's an example of encapsulation

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

or the same using lambda functions

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

In both cases the data, that is the variable n, is bundled together with the function inc that operates on it. And there is no way any other function could ever access n, thus we have an encapsulated module that provides counting as a service.

NB: exposing all of an object's inner state through accessors is actually a violation of encapsulation. Alas, it is such a common violation that many will confuse it with good object-oriented design.

Best Answer

Related Solutions

Object-Oriented Design – Use of Association, Aggregation, and Composition

Related Topic