Writing SOLID code (in practice)

WRITING SOLID CODE
(IN PRACTICE)

WRITING SOLID CODE IN PRACTICE
ABOUT ME
Tomasz Wojcik (@prgTW)
• backend dev@backoffice team
• been with DocPlanner since dinosaurs
• worships Grumpy Cat, morning coffee 
and code reviews in the middle of the night
ó actually :P
/prgTW /prgTW /prgTW

WHAT “SOLID” STANDS FOR | THEORY

• SRP
• OCP
• LSP
• ISP
• DIP

• SRP
• OCP
• LSP
• ISP
• DIP
Single Responsibility Principle

• SRP
• OCP
• LSP
• ISP
• DIP
Open/Closed Principle

• SRP
• OCP
• LSP
• ISP
• DIP
Liskov Substitution Principle

• SRP
• OCP
• LSP
• ISP
• DIP
Interface Segregation Principle

• SRP
• OCP
• LSP
• ISP
• DIP
Interface Segregation Principle
Dependency Inversion Principle

CODE EXAMPLE

<?php 
 
class RandomGithubEmoji 
{ 
public function fetch(): string 
{ 
$cacheFile = __DIR__ . '/random_emoji'; 
 
if (is_file($cacheFile) && time() - filemtime($cacheFile) <= 3) 
{ 
return file_get_contents($cacheFile); 
} 
 
$response = file_get_contents('https://api.github.com/emojis'); 
if (!$response) 
{ 
return 'https://assets-cdn.github.com/images/icons/emoji/trollface.png?v6'; 
} 
 
$emojis = json_decode($response, true); 
$randomEmoji = array_rand($emojis); 
 
file_put_contents($cacheFile, $randomEmoji); 
 
return $randomEmoji; 
} 
} 
CODE EXAMPLE | PRACTICE

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
Typical answers:

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
Typical answers:
• hardcoded integer & strings
• introduce constants
• move to method arguments

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
Typical answers:
• extract code to methods

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
Typical answers:
• many return points

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
Typical answers:
• many return points
• throw exception  
in error handling

LET’S START REFACTORING

SINGLE RESPONSIBILITY PRINCIPLE

SINGLE RESPONSIBILITY PRINCIPLE | THEORY

• class/module should have only single responsibility

• the above is defined as single reason for change

• the above is defined as single reason for change
• related services should be aligned with this responsibility

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
SINGLE RESPONSIBILITY PRINCIPLE | PRACTICE

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
 
 
 
 
 
 
 
{ 
} 
 
 
 
 
 
 
 
 
 
 
file_put_contents($cacheFile, $randomEmoji);
cache control

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
 
 
 
 
 
 
 
 
 
 
 
 
 
$response = file_get_contents('https://api.github.com/emojis');  fetching data

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
if (!$response) 
{ 
}
error handling

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
$emojis = json_decode($response, true); data transformation

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
$randomEmoji = array_rand($emojis);
 
 
 
return $randomEmoji;
random emoji logic

• cache control
• fetching data
• error handling
• data transformation
• random emoji logic

class FileCache• cache control
• fetching data
• error handling

class FileCache
class FileGetContentsFetcher
• cache control
• fetching data
• error handling

class FileCache
throw new Exception
• cache control
• fetching data
• error handling
custom one

class FileCache
throw new Exception
class JsonSerializer
• cache control
• fetching data
• error handling
custom one

class FileCache
throw new Exception
class JsonSerializer
class RandomGithubEmoji
• cache control
• fetching data
• error handling
custom one

<?php 
 
{ 
{ 
 
 
 
 
 
 
 
if (!$response) 
{ 
} 
 
 
 
 
} 
} 
 
 
 
 
 
 
 
{ 
} 
 
 
 
 
 
 
 
 
 
 
file_put_contents($cacheFile, $randomEmoji);
cache control

<?php 
 
{ 
{ 
 
 
 
 
 
 
 
if (!$response) 
{ 
} 
 
 
 
 
} 
} 
cache control
 
 
 
 
 
 
$cache = new FileCache(__DIR__ . '/random_emoji'); 
 
$randomEmoji = $cache->fetch(); 
if (null !== $randomEmoji) 
{ 
} 
 
 
 
 
 
 
 
 
 
$cache->put($randomEmoji);

<?php 
 
{ 
{ 
 
{ 
} 
 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
 
 
 
 
 
 
 
 
 
 
 
 
 
$response = file_get_contents('https://api.github.com/emojis');  fetching data

<?php 
 
{ 
{ 
 
{ 
} 
 
 
if (!$response) 
{ 
} 
 
 
 
} 
} 
fetching data
 
 
 
 
 
 
 
 
 
 
 
 
 
$response = (new FileGetContentsFetcher)->fetch('https://api.github.com/emojis');

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
return 'https://assets-cdn.github.com/images/icons/emoji/trollface.png?v6';  error handling
<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
 
} 
 
 
 
} 
}

error handling
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
throw new UnableToFetchEmojiException;
<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
 
} 
 
 
 
} 
}

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
 
} 
} 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
$emojis = json_decode($response, true); data transformation

<?php 
 
{ 
{ 
 
{ 
} 
 
if (!$response) 
{ 
} 
 
 
 
 
} 
} 
data transformation
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
$emojis = (new JsonSerializer)->deserialize($response, 'json');

<?php 
 
{ 
{ 
{ 
} 
 
$response = (new FileGetContentsFetcher)->fetch('https://api.github.com/emojis'); 
if (!$response) 
{ 
throw new UnableToFetchEmojiException; 
} 
 
$emojis = (new JsonSerializer)->deserialize($response, 'json'); 
 
$cache->put($randomEmoji); 
 
} 
}

<?php 
 
{ 
{ 
{ 
} 
 
$response = (new FileGetContentsFetcher)->fetch('https://api.github.com/emojis'); 
if (!$response) 
{ 
throw new UnableToFetchEmojiException; 
} 
 
$emojis = (new JsonSerializer)->deserialize($response, 'json'); 
 
$cache->put($randomEmoji); 
 
} 
}
 
 
 
 
 
 
new FileCache(__DIR__ . '/random_emoji'); 
 
 
 
 
 
 
new FileGetContentsFetcher 
 
 
 
 
 
new JsonSerializer
DEPENDENCY INJECTION | PRACTICE

DEPENDENCY INVERSION PRINCIPLE

DEPENDENCY INVERSION PRINCIPLE | THEORY

• used to decouple software modules

• high-level modules shouldn’t depend on low-level-modules, they both should
depend on abstractions

• class members should be interfaces or abstracts

• class shouldn’t derive from concretions (composition over inheritance)

• methods shouldn’t derive from already implemented methods

• methods shouldn’t derive from already implemented methods
• variables must be created via injection or creational patterns (eg. factories)

https://en.wikipedia.org/wiki/Dependency_inversion_principle

DEPENDENCY INVERSION PRINCIPLE | PRACTICE

DEPENDENCY INJECTION
(NOT PART OF SOLID ACTUALLY)

DEPENDENCY INJECTION | THEORY

• providing dependencies from outside of the dependent class

• providing dependencies from outside of the dependent class
• class mustn’t use new or static methods

<?php 
 
{
/** @var Cache Interface */ 
private $cache ; 
 
/** @var FetcherInterface */ 
private $fetcher; 
 
/** @var SerializerInterface */ 
private $serializer; 
 
public function __construct(Cache Interface $cache , FetcherInterface $fetcher, SerializerInterface $serializer)
{ 
$this->cache = $cache ; 
$this->fetcher = $fetcher; 
$this->serializer = $serializer; 
}
 
// ...
}

 
 
 
/** @var CacheFactoryInterface */ 
private $cacheFactory; 
 
 
 
 
 
 
 
CacheFactoryInterface $cacheFactory
 
$this->cacheFactory = $cacheFactory;
<?php 
 
{
/** @var Cache Interface */ 
private $cache ; 
 
/** @var FetcherInterface */ 
private $fetcher; 
 
/** @var SerializerInterface */ 
private $serializer; 
 
public function __construct(Cache Interface $cache , FetcherInterface $fetcher, SerializerInterface $serializer)
{ 
$this->cache = $cache ; 
$this->fetcher = $fetcher; 
$this->serializer = $serializer; 
}
 
// ...
}

OPEN/CLOSED PRINCIPLE

OPEN/CLOSED PRINCIPLE | THEORY

• class should be open for extension
• class behaviour can be changed in derived classes
• protected instead of private methods

• class should be closed for modification
• there should be no reason to change class code
• interfaces

• class should be closed for modification
• there should be no reason to change class code
• interfaces
• think of dependencies coming from 3rd party vendors

OPEN/CLOSED PRINCIPLE | PRACTICE
<?php 
 
interface RandomEmojiInterface 
{ 
}

<?php 
 
 
 
 
 
class Emoji 
{ 
/** @var string */ 
private $url; 
 
public function __construct(string $url) 
{ 
$this->url = $url; 
} 
 
public function getUrl(): string 
{ 
return $this->url; 
} 
} 
 
{ 
public function fetch(): Emoji 
}

 
 
 
 
 
 
 
 
/** @var string */ 
private $url; 
 
public function __construct(string $url) 
{ 
$this->url = $url; 
} 
 
public function getUrl(): string 
{ 
return $this->url; 
} 
 
 
 
 
 
<?php 
interface EmojiInterface 
{ 
public function getUrl(): string; 
 
// here we COULD add additional features 
} 
 
class Emoji implements EmojiInterface 
{ 
 
 
 
 
 
 
 
 
 
 
} 
 
{ 
public function fetch(): EmojiInterface; 
}

INTERFACE SEGREGATION PRINCIPLE

INTERFACE SEGREGATION PRINCIPLE | THEORY

• many specific interfaces are better than one generic

• client shouldn’t be aware and forced to depend on methods it doesn’t use

• client shouldn’t be aware and forced to depend on methods it doesn’t use
• helps keeping parts of the system decoupled

INTERFACE SEGREGATION PRINCIPLE | PRACTICE

<?php 
 
interface CacheInterface 
{ 
public function get($key); 
 
public function put($something); 
 
} 
 
class FileCache implements CacheInterface 
{ 
// get, put 
}

<?php 
 
{ 
 
 
public function getMany(array $keys); 
 
public function putMany(array $items); 
} 
 
{ 
// get, put 
// getMany, putMany 
}

<?php 
 
{ 
 
 
 
 
public function invalidate($key); 
 
public function invalidateMany(array $keys); 
 
public function invalidataAll(); 
} 
 
{ 
// get, put 
// getMany, putMany
// invalidate, invalidateMany, invalidateAll 
}

<?php 
 
{ 
 
 
 
 
public function invalidate($key); 
 
public function invalidateMany(array $keys); 
 
public function invalidataAll(); 
 
public function gc(); 
 
public function countAll(); 
} 
 
{ 
// :( 
}

LISKOV SUBSTITUTION PRINCIPLE
(BARBARA LISKOV)

https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
COVARIANCE & CONTRAVARIANCE | LSP | THEORY

LISKOV SUBSTITUTION PRINCIPLE | THEORY

• objects of type T can be replaced by any subtype S of type T without altering
desired properties of the program/module (eg. correctness)

• signature requirements
• covariance of return types
• contravariance of method arguments
• no new exceptions being non-derived from exceptions thrown in super type

• signature requirements
• covariance of return types
• contravariance of method arguments
• no new exceptions being non-derived from exceptions thrown in super type
• behavioral conditions
• preconditions cannot be strengthen in subtype
• postconditions cannot be weakened in subtype
• invariant in supertypes have to be preserved in subtype

COVARIANCE & CONTRAVARIANCE | LSP | PRACTICE

<?php 
 
interface T 
{ 
} 
 
interface S extends T 
{ 
}

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
 
// --------------------------- 
 
 
interface A 
{ 
public function do(T $t); 
} 
 
interface B extends A 
{ 
} 
<?php 
 
interface T 
{ 
} 
 
{ 
}

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
 
// --------------------------- 
 
 
interface A 
{ 
} 
 
{ 
} 
<?php 
 
interface T 
{ 
} 
 
{ 
}
invariance of method argument

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
 
// --------------------------- 
 
 
interface A 
{ 
} 
 
{ 
public function do(S $s); 
} 

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
 
// --------------------------- 
 
 
interface A 
{ 
} 
 
{ 
} 
covariance of method argument

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
 
// --------------------------- 
 
 
interface A 
{ 
} 
 
{ 
} 
not allowed here, why?

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
 
// --------------------------- 
 
 
interface A 
{ 
} 
 
{ 
} 
… violating A::do signature 
… violating “preconditions cannot be strengthen in subtype”

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
// --------------------------- 
 
class A 
{ 
public function do(): S; 
{ 
} 
} 
 
class B extends A 
{ 
public function do(): T; 
{ 
} 
} 

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
// --------------------------- 
 
class A 
{ 
{ 
} 
} 
 
{ 
{ 
} 
} 
contravariance of return type

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
// --------------------------- 
 
class A 
{ 
{ 
} 
} 
 
{ 
{ 
} 
} 

<?php 
 
interface T 
{ 
} 
 
{ 
} 
 
// --------------------------- 
 
class A 
{ 
{ 
} 
} 
 
{ 
{ 
} 
} 
… violating A::do signature 
… violating “postconditions cannot be weakened in subtype”

SUMMARY

BEFORE | SUMMARY

AFTER | SUMMARY

BENEFITS OF WRITING SOLID CODE

BENEFITS | SUMMARY

BENEFITS | SUMMARY
• code is well organised and more declarative
• code is easy to read and understand (short learning curve)
• code is loosely coupled and thus reusable
• code is easy to adapt
• code is easy to extend
• code is easy to refactor
• code is easy to unit test
• code is easy to replace/mock in functional tests
• … etc. etc.

Q’N’A
Questions?

THANK YOU!
docplanner.com/career
Join us!

Writing SOLID code (in practice)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a Writing SOLID code (in practice)

Similar a Writing SOLID code (in practice) (20)

Último

Último (20)

Writing SOLID code (in practice)