Extend mapper or use utility class?

PHP
1

Hi guys, I’m sorry if the thread title is a bit vague.

I’m working on a booking application at the moment, and at some point I need to check if a certain date is available for booking.

I use a DateMapper class which handles the processing of objects representing bookable dates on my system. This wraps a database connection and does all the querying.

The checking of the date will happen within multiple methods of an overall Controller/CommandGroup/Module class.

My question is, should I implement the code for checking the booking date in DateMapper or should I use a utility class e.g. DateManager or DateChecker.

That is:


$mapper = new DateMapper($connection);
$result = $mapper->isAvailable($dateString);

class DateMapper {
    function __construct($connection) {
         $this->connection = $connection;
    }
    function isAvailable($dateString) {
         return count($this->query("SELECT...", $dateString)); //query the db
    }
}

or


$checker = new DateChecker(new DateMapper($connection));
$result = $checker->isAvailable($dateString);

class DateMapper {
    function __construct($connection) {
         $this->connection = $connection;
    }
}

class DateChecker {
    function __construct($mapper) {
         $this->mapper = $mapper;
    }
    function __isAvailable($dateString) {
         return count($this->mapper->query("SELECT...", $dateString));
    }
}

My understanding is that the benefit of using a utility class e.g. DateChecker is when that class may potentially use many different DateMappers with different interfaces. Would there be another reason to use an extra class like this?

Since I don’t foresee the need to use different DateMappers in the system, is there a problem putting the code for the date checking within the mapper itself?

My OOP is fairly rusty (haven’t done much serious programming for a couple years now) so I do apologise if the answer is glaringly obvious!

2

Also another maxim I hear a lot is “More testable code is better code”.

In this case I could simply hard-code the logic into the part of the application where the date checking occurs, but if I did that it would be harder to test - if I made a class of the logic, or put the logic in the DateMapper class, it’s definitely more testable e.g. by mocking the appropriate object.

Is that right?

3

Kyber, thank you for your reply, you always give great responses to posts.

J Arkinstall is correct, the DateMapper is actually a subclass of a generic DataMapper type object I should have done something like this for clarification:

class DateMapper extends SomeGenericDataMapper { }

So that is to say, if the DateMapper object may be used across the application, but the particular logic for date checking is only in one place/method, I make the logic available only to that one place/method by NOT putting into the more ‘globally used’ DateMapper?

4

Yes, that was what I meant. Now mind that it’s all very subjective; But as a general guideline, I think that lots of small objects that are only used in a limited place, instead of fewer objects that combines all these efforts, is good for reducing complexity.

5

By the looks of the post, it is a date mapper - a mapper for booking dates in the database - as opposed to a data mapper, which is the general term for all mappers.

6

It’s called a data mapper - not a date mapper.

Hard to give a definite answer to that. If the rules can be enforced in the gateway (DataMapper), then do it there. But often, your logic will involve all sorts of external dependencies and then it doesn’t work too well to enforce it in the data access layer. A separate utility class can certainly be a useful way to handle those cases.

Yes, keeping complexity down. If some piece of logic is only used in one part of your application, there is no need to make it available to all the other places. It’s basic divide-and-conquer tactics.