PHP Design Patterns – Using Data Transfer Objects for Sharing Data Between Classes

designdesign-patternsobject-orientedPHP

I found an article by Martin Fowler that has made me doubt my design choices, particularly about data objects. Martin Fowler has written an article about what he thinks is a code smell.

In this article, he says:

The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class. Then you start refactoring to move that behavior in there. Often simple questions and initial refactorings can be the vital step in turning anemic objects into something that really has class.

Now, on to my own use case of data classes/objects/DTOs/whatever. 🙂

I am writing a set of classes that move credits from our company's sim to the sim of a recipient. This process has three stages:

Validation: at this stage, the data is validated – have we moved credits to this person's account before? Have we handled this item before? Can we retry, or have we reached the "manual mode" threshold?
Process: at this stage, we do the actual work of moving the credits from one account to the other. We use the objects retrieved in the validation phase, to lower the number of queries to the database, and also to improve our application's performance.
Post-process: at this point, we check the data and if the data must be auto-corrected (I.E. the user has entered wrong information and we know how to automatically fix it), we mark it for autocorrection.

Now, the items 2 and 3 are using a lot of data that is retrieved or initialized in stage 1: the event manager, the order and payment and transaction objects, and so on. What we do is the following:

The validation object stores all of its retrieved data that is useful to the rest of the process in a data transfer object (DTO). This object has only setters and getters.
The rest of the classes (the process class and the post-process class) accept the DTO as their constructor argument and do their processing, event management, and data manipulation on those objects. In the end, those objects are persisted in the database.

Is the data object (or the data transfer object) not recommended here? Should we use another way for sharing data between these three classes?

Best Answer

Should we use another way for sharing data between these three classes?

No, that is not the point of what Fowler is talking about. The usage of a DTO is probably fine (Fowler himself recommends it, especially in a remote scenario). The point is that during refactoring, such a DTO might become a better place for operations which work exclusively on the data stored within the DTO (that actually does not mean to put the whole validation, processing and post-processing code in there).

Candidates are typically operations which might be reused in more than one of the steps you described above. Another indicator is when you start implementing something like a FooDTOManager class for a specific class FooDTO, instead of implementing the operations directly in FooDTO. What you should consider is the name your give to the DTO - it will ideally express some kind of abstraction and some kind of responsibility. Use this responsibility as a guideline when deciding about which operations you put into the DTO, and which not.

However, if the only responsibility of your DTO objects (currently) is to transfer some data from step x to step y, then leave it as it is. Later, when your program evolves, you might find operations which may be suited as operations for this DTO - if there are currently none, it is ok, don't start to seek for a different solution.

Approach 1: Use a property in `bar`

Make commonlib a property in bar and declare getters and setters. Share that one instance of commonlib that you declared in main between foo1 and foo2.

abstract class bar {
    protected $commonlib;
    
    public function __get($property) {
        if (property_exists($this, $property)) {
            return $this->$property;
        }
    }

    public function __set($property, $value) {
        if (property_exists($this, $property)) {
            $this->$property = $value;
        }
        return $this;
    }
}


class foo1 extends bar{
    public function someMethod() {
        $this->commonlib->addQueries($fromSomeWhere);
    }
}

class foo2 extends bar{
    public function someMethod() {
        $this->commonlib->addQueries($fromSomeWhereElseAndInADifferentWay);
    }
}

class main {

    public $commonlib = new commonlib();

    public function start(){
        //goal is to share one instance of $this->commonlib between foo1 and foo2 
        //so that they can both add to the properites of $this->commonlib (global
        //between the two)
        $foo1 = new foo1();
        $foo1->commonlib = $commonlib;

        $foo2 = new foo2();
        $foo2->commonlib = $commonlib;

        $foo1->someMethod();
        $foo2->someMethod();

        //now execute all of the queries after foo1 and foo2 add their query
        $this->commonlib->RunQueries();

}

Edit:

Approach 2: Pass common lib as an argument and only put algos in foo1 and foo2

Thus,

class foo1 {
    public function addQueries($commonlib) {
        $commonlib->addQueries($fromSomeWhere);
    }
}

class foo2 {
    public function addQueries($commonlib) {
        $commonlib->addQueries($fromSomeWhereElseAndInADifferentWay);
    }
}

class main {

    public $commonlib = new commonlib();

    public function start(){
        //goal is to share one instance of $this->commonlib between foo1 and foo2 
        //so that they can both add to the properites of $this->commonlib (global
        //between the two)
        $foo1 = new foo1();
        $foo2 = new foo2();

        $foo1->someMethod($commonlib);
        $foo2->someMethod($commonlib);

        //now execute all of the queries after foo1 and foo2 add their query
        $this->commonlib->RunQueries();

}

Design Patterns – Where to Parse Data Obtained with a DAO

Typically an unmarshalling construct can be used.

The job of the unmarshaller would be simply to translate from the string to your domain specific DTO. Your DAO or DTO will not need to change if the transmission format changes. Additionally, the unmarshalling strategy can be mocked out for unit tests (and tested separately). Depending on your enterprise architecture pattern, you can invoke the unmarshaller anywhere (in the DAO, the DTO, using AOP, ...).

Many widely used software packages use the marshalling/unmarshalling concept including Spring, JAXB, and the AWS Java SDK. I suggest that you take a look at these libraries to get some ideas as to how you can implement and fit into your design (you may find a ready made solution that fits your needs).

Best Answer

Related Solutions

PHP Object-Oriented Programming – Sharing Objects Between Classes

Approach 1: Use a property in bar

Approach 2: Pass common lib as an argument and only put algos in foo1 and foo2

Design Patterns – Where to Parse Data Obtained with a DAO

Related Topic

Approach 1: Use a property in `bar`