Dependency injection vs abstract class vs inheritance vs singleton - php

Question

I have three classes:
a Logger that logs process information to a file
a Checker that validates input data
an Operations that does things on the input data.
I need Logger in both Checker and Operations to output (log) the process.
I need Checker in Operations, in order to check validity of data.
class Logger {
}
class Checker {
// inherit Logger ?
// dependency-inject Logger ?
// access Logger statically ?
// compose Logger as singleton or create new object ?
}
class Operations {
// inherit Logger ?
// dependency-inject Logger ?
// access Logger statically ?
// compose Logger as singleton or create new object ?
}
The application will create only one instance of Operations and Checker classes. The question is - in situations where no new objects are needed or created, what type of class should Logger be and how should it be implemented in the Operations and Checker classes?

Answer 1

If you are programming to interfaces, then the most flexible option is to use a decorator:
interface ILogger
{
function log($msg);
}
class FileLogger implements ILogger{
function log($msg)
{
file_put_contents('file.dat', $msg . "\n", FILE_APPEND);
}
}
interface IChecker
{
function check($var);
}
class Checker implements IChecker {
function check($var)
{
//do some checking
return true;
}
}
//decorator
class LoggingChecker implements IChecker
{
private $checker;
private $logger;
function __construct(IChecker $checker, ILogger $logger)
{
$this->checker = $checker;
$this->logger = $logger;
}
function check($var)
{
$checkResult = $this->checker->check($var);
$this->logger->log('check result is: ' . ($checkResult)? 'a success' : 'a failure');
return $checkResult;
}
}
interface IOperations
{
function doOperation($var);
}
class Operations implements IOperations{
private $checker;
function __construct(IChecker $checker)
{
$this->checker = $checker;
}
function doOperation($var)
{
if($this->checker->check($var)){
//do some operation
}
}
}
//composotion root
//create concrete logger, in this case a FileLogger instance, though you could latter create a SqlLogger or EmailLogger
//and swap it without any changes to the other classes
$logger = new FileLogger();
//create concreate checker
$checker = new Checker();
//create decorated checker
$loggingChecker = new LoggingChecker($checker, $logger);
//Operations can now be instantiated with either the regular checker, or the decorated logging checker, and it will
//work just the same, with no knowledge of the existense of loging, or indeed any knowledge of how the checker functions, beyond
//the fact it has a method called check that excepts a single parameter
$operation = new Operations($checker); //no logging is done
//OR
$operation = new Operations($loggingChecker); //logging is done
Note that i only created a decorator for IChecker in the above example for berevity.
You could also create a decorator for IOperations eg LoggingOperations that works in the same way - it depends on an instance of ILogger and IOperations.
You would instantiate it with the same concrete ILogger implementation ($logger) and IOperations implementation ($operation).
The class that uses this object would have a single dependancy on IOperations and could be instantiated with either $operation or $logginOperation and behave in the same way.
Hopefully this example gives you an idea of the flexibility of programming to interfaces and how the decorator pattern can simplify dependent classes and help enforce SRP

Answer 2

Answering directly to your question, what kind of class should logger be...
A classic example of a true singleton is a logging service. Suppose we
have an event-based logging service: Client objects request that text
be logged by sending a message to the logging service. Other objects
actually log the text somewhere (console, file, whatever) by listening
to the logging service for these logging requests and handling them.
First, notice that the logging service passes the classic test for
being a singleton:
The requesters need a well-known object to which to send requests to
log. This means a global point of access. Since the logging service is
a single event source to which multiple listeners can register, there
only needs to be one instance.
More info here Why we should consider the «Logger» class as a singleton?
For a nice logger, in case you dont have one at your framework, you should take a look of this one klogger

Answer 3

It depends , is there a possibility to have logger objects with different properties ? (e.g. to write the log into other folders or do something different with the message to be logged based on their properties) If so dependency injection is the way.
Does the logger perform the same way and doesn't even need properties ? (e.g. it just write the msg to a predefined file relative to the source folder). Than you don't even need to use singleton it could be a Utilities class with static methods.
And finally if your logger needs initialization and you initialize it only once then you could use singleton.