DRY Principle – Good Practices for DRY Principle in Design Patterns

design-patternsobject-orientedPHP

I am trying to follow the DRY principle in my programming as hard as I can. Recently I have been learning design patterns in OOP and I have ended up repeating myself quite a bunch.

I have created a Repository pattern along with a Factory and Gateway patterns to handle my persistence. I'm using a database in my application but that shouldn't matter since I should be able to swap out the Gateway and switch to another kind of persistence if I wished.

The problem I've ended up creating for myself is that I create the same objects for the number of tables I have. For example these will be the objects I need to handle a table comments.

class Comment extends Model {

    protected $id;
    protected $author;
    protected $text;
    protected $date;
}

class CommentFactory implements iFactory {

    public function createFrom(array $data) {
        return new Comment($data);
    }
}

class CommentGateway implements iGateway {

    protected $db;

    public function __construct(\Database $db) {
        $this->db = $db;
    }

    public function persist($data) {

        if(isset($data['id'])) {
            $sql = 'UPDATE comments SET author = ?, text = ?, date = ? WHERE id = ?';
            $this->db->prepare($sql)->execute($data['author'], $data['text'], $data['date'], $data['id']);
        } else {
            $sql = 'INSERT INTO comments (author, text, date) VALUES (?, ?, ?)';
            $this->db->prepare($sql)->execute($data['author'], $data['text'], $data['date']);
        }
    }

    public function retrieve($id) {

        $sql = 'SELECT * FROM comments WHERE id = ?';
        return $this->db->prepare($sql)->execute($id)->fetch();
    }

    public function delete($id) {

        $sql = 'DELETE FROM comments WHERE id = ?';
        return $this->db->prepare($sql)->execute($id)->fetch();
    }
}

class CommentRepository {

    protected $gateway;
    protected $factory;

    public function __construct(iFactory $f, iGateway $g) {
        $this->gateway = $g;
        $this->factory = $f;
    }

    public function get($id) {

        $data = $this->gateway->retrieve($id);
        return $this->factory->createFrom($data);
    }

    public function add(Comment $comment) {

        $data = $comment->toArray();
        return $this->gateway->persist($data);
    }
}

Then my controller looks like

class Comment {

    public function view($id) {

        $gateway = new CommentGateway(Database::connection());
        $factory = new CommentFactory();
        $repo = new CommentRepository($factory, $gateway);

        return Response::view('comment/view', $repo->get($id));
    }
}

So I thought I was using design patterns correctly and keeping good practices, but the problem with this thing is that when I add a new table, I have to create the same classes just with other names. This raises suspicion in me that I may be doing something wrong.

I thought of a solution where instead of interfaces I had abstract classes which using the class name figure out the table they need to manipulate but that doesn't seem like the right thing to do, what if I decide to switch to a file storage or memcache where there are no tables.

Am I approaching this correctly, or is there a different perspective I should be looking at?

Best Answer

The problem you are addressing is quite fundamental.

I have experienced the same problem when I worked for a company that made a large J2EE application that consisted of several hundred web pages and over a million and a half lines of Java code. This code used ORM (JPA) for persistence.

This problem get worse when you use 3rd party technologies in every layer of the architecture and the technologies all require their own data representation.

Your problem can not be solved at the level of the programming language you are using. Using patterns is good but as you see it cause repetition of code (ore more accurately put: repetition of designs).

The way I see it there are only 3 possible solutions. In practice these solutions come down to the same.

Solution 1: Use some other persistence framework that allows you to state only what must be persisted. There is probably such a framework around. The problem with this approach is that it is rather naive because not all you patterns will be persistence related. You wil also want to use patterns for user interface code so you'd then need a GUI framework that can re-use the data representations of the persistence framework you choose. If you can not re-use them you'll need to write boiler plate code to bridge the data representations of the GUI framework and the persistence framework.. and this is contrary to the DRY principle again.

Solution 2: Use another - more powerful - programming language that has constructs that allow you to express the repetitive design so you can re-use the design-code. This is probably not an option for you but suppose for a moment it is. Then again when you start creating a user interface on top of the persistence layer you'll want the language again to be powerful enough to support creating the GUI without having to write boiler plate code. It is unlikely that there is a language powerful enough to do what you want since most languages rely on 3rd party frameworks for GUI building that each require their own data representation to work.

Solution 3: Automate the repetition of code and design using some form of code generation. Your worry is about having to hand-code repetitions of patterns and designs since hand-coding repetitive code/design violate the DRY principle. Nowadays there are very powerful code generator frameworks out there. There are even "language workbenches" that allow you to quickly (half a day when you have no experience) create your own programming language and generate any code (PHP/Java/SQL - any thinkable text file) using that language. I have experience with XText but MetaEdit and MPS seem to be fine as well. I strongly advice you to check one of these language workbenches out. To me it was the most liberating experience in my professional life.

Using Xtext you can have your machine generate the repetitive code. Xtext even generates a syntax highlighting editor for you with code completion for your own language specification. From that point you simply take your gateway and factory class and turn them into code templates by punching holes in them. You feed them to your generator (which is called by a parser of your language that is also completely generated by Xtext) and the generator will fill in the holes in your templates. The result is generated code. From that point on you can take out any repetition of code anywhere (GUI code persistence code etc).

Related Solutions

Design Patterns – Is ‘Mapper’ a Valid Design Pattern or a Variation of ‘Factory’?

Although this is the first time I hear of the Mapper pattern, to me it sounds more like the Builder pattern rather than the Factory.

In the Factory pattern you encapsulate the logic for creating objects of a number of related classes. The prime example would be a situation where you need to create an object of a particular subclass of some abstract base class depending on some parameters. So a Factory always returns a pointer or a reference to the base class, but it actually creates an object of the appropriate derived class based on the parameters you give it.

In contrast, a Builder class always creates objects of the same class. You would use it if the creation of an object is complicated, e. g. its constructor takes lots of arguments, not all of which may be available instantly. So a builder object might be a place which stores the values for the constructor arguments until you have them all and are ready to create the "product", or it may provide reasonable default values and let you only specify the arguments whose values you need to change. A typical use case for the Builder pattern is for creating objects you might need in a unit test, to avoid cluttering the test code with all the creation logic.

To me a Mapper sounds like a variant of a Builder, where the constructor parameters come in the form of a database record or some other "raw" data structure.

Object-oriented – Xerox SOLID example in PHP

First, lets understand what was the issue: The Staple job knows about many more methods which it doesn't use today, (e.g., the print method) but which are available for it to use, should it want to. However, the Job class "thinks" that the Staple class will be "a good citizen" and never use the print method at all.

There are many potential big issues here - For some reason, the Staple job may start using the print method - by accident or intentionally.

Then down the road, either any changes to the print method may go untested,
OR, any changes to the print method will trigger a regression test in the Staple job also,
AND, any impact analysis for changes to the print job will necessarily involve impact analysis of the staple job too.

This is just the issue of Staple knowing about the print functions. Then there's the case of the Print job knowing all about stapling functions. Same problems.

Very soon, this system would reach a point where any change will require a full blown impact analysis of each module and a full blown regression test.

Another problem is that today, all jobs which can be printed can be stapled, and vice versa on this particular printer.

However, tomorrow, there could be a need to install the same firmware on a device that only prints or only staples. What then? The code already assumes that all Jobs are printable and stapleable. So any further granular breakdown / simplification of responsibilities is impossible.

In more recent terms, imagine a class called "AppleDevice" which has functions for MakePhoneCall as well as PlayMusic. Now your problem is while you can easily use this on an iPhone, you cannot use it for an iPod since the iPod cannot make phone calls.

So, the issue is not that the Job class is all-powerful. In fact, that's how it should be, so that it can act as a common link in the entire "workflow" where someone may scan a job, then print it, then staple it etc. The problem is that the usage of all its methods is not restricted. Anyone and everyone could use and abuse any method whenever they want to, thus making the maintenance difficult.

Hence, the Dependency Injection approach of only telling users "exactly what they need to know, and nothing more" ensures that calling modules only use the code that they are meant to. A sample implementation would look like:

interface IStapleableJob { void stapleYourself(); }
interface IPrintableJob { void printYourself(); }
class Job implements IStapleableJob, IPrintableJob {
....
}

class Staple {
  public static void stapleAllJobs(ArrayList<IStapleableJob> jobs) {
    for(IStapleableJob job : jobs) job.stapleYourself();
  }
}

class Print {
  public static void stapleAllJobs(ArrayList<IPrintableJob> jobs) {
    for(IPrintableJob job : jobs) job.printYourself();
  }
}

Here, even if you pass a Job object to the Staple and Print methods, they dont know that its a Job, so they cannot use any methods that they are not supposed to. Thus, when you make any changes to a module, your scope of impact analysis and regression testing is restricted. That's the problem that ISP solves.

Best Answer

Related Solutions

Design Patterns – Is ‘Mapper’ a Valid Design Pattern or a Variation of ‘Factory’?

Object-oriented – Xerox SOLID example in PHP

Related Topic