&
Alessandro Cappellozza
12/10/2019
eppak
Ogni elemento di un programma (classe, metodo, variabile) deve avere una sola responsabilità, e che tale responsabilità debba essere interamente incapsulata dall'elemento stesso. Tutti i servizi offerti dall'elemento dovrebbero essere strettamente allineati a tale responsabilità.
class User {
protected function formatResponse($data) {
}
protected function validateUser($user) {
}
protected function loadFromDB($id) {
}
}Afferma che le entità (classi, moduli, funzioni, ecc.) software dovrebbero essere aperte all'estensione, ma chiuse alle modifiche; in maniera tale che un'entità possa permettere che il suo comportamento sia modificato senza alterare il suo codice sorgente.
Ereditarietà dell'implementazione
Ereditarietà dell'interfaccia
class LoginService {
protected function login($user) {
if ($user istanceof Admin) {
$this->authenticateAdmin($user);
} else if ($user istanceof user) {
$this->authenticateNormal($user);
}
}
}interface ILogin {
public function authenticateUser($user);
}
class UserLogin implements ILogin {
public function authenticateUser($user) {
}
}
class AdminLogin implements ILogin {
public function authenticateUser($user) {
}
}
class LoginService {
protected function login($user) {
$this->authenticate($user);
}
}"Se q(x) è una proprietà che si può dimostrare essere valida per oggetti x di tipo T, allora q(y) deve essere valida per oggetti y di tipo S dove S è un sottotipo di T."
interface IRepository {
public function load($id);
}
class Userimplements IRepository {
public function load($id) {
return DB_table('users')->where('user_id', '=', $id);
}
}
class Admin implements IRepository {
public function load($id) {
return FileSystem::getData(id);
}
}Un client non dovrebbe dipendere da metodi che non usa, e che pertanto è preferibile che le interfacce siano molte, specifiche e piccole (composte da pochi metodi) piuttosto che poche, generali e grandi.
class Driver {
public function operate(Car $car) {
$car->getFuel();
$cat->shiftGear();
$car->steer();
}
}
interface ICar {
public function getFuel();
public function shiftGear();
public function steer();
}
class Car implements ICar {
private $gasoline = 0;
public function getFuel() { return $gasoline; }
public function shiftGear() {}
public function steer() {}
}
class ElecticCar implements ICar {
public function getFuel() { return null; }
public function shiftGear() {}
public function steer() {}
}I moduli di alto livello non devono dipendere da quelli di basso livello. Entrambi devono dipendere da astrazioni; Le astrazioni non devono dipendere dai dettagli; sono i dettagli che dipendono dalle astrazioni.
interface IConnection {
public function connect();
}
class DBConnection implements IConnection {
public function connect() { }
}
class PasswordReset implements IConnection {
private $db;
function __constructor(IConnection $conn) {
$this->db = $conn;
}
}Lista di parametri troppo lunga (per metodi o funzioni).
Feature envy o data envy ("invidia dei dati"): una classe che usa massicciamente i servizi o i dati di un'altra.
Costanti magiche: valori letterali (numeri, stringhe) che appaiono direttamente ("cablati") nel codice.
Espressioni complesse di basso livello (per esempio aritmetiche, di manipolazione di stringhe, ...).
What comments ("commenti cosa"): commenti che spiegano cosa fa una certa porzione di codice (sintomo che il codice non è sufficientemente chiaro di per sé).
Generalità speculativa: codice scritto in una forma più generale del necessario per poter essere eventualmente applicato in futuro in contesti più ampi.
L'extreme programming ha una specifica regola contro questa pratica, "You Aren't Gonna Need It" ("non ne avrai bisogno"): "implementa sempre le cose quando ne hai effettivamente bisogno, mai quando prevedi di averne bisogno".[5]
Shotgun Surgery resembles Divergent Change but is actually the opposite smell. Divergent Change is when many changes are made to a single class. Shotgun Surgery refers to when a single change is made to multiple classes simultaneously.
A single responsibility has been split up among a large number of classes. This can happen after overzealous application of Divergent Change.
Divergent Change resembles Shotgun Surgery but is actually the opposite smell. Divergent Change is when many changes are made to a single class. Shotgun Surgery refers to when a single change is made to multiple classes simultaneously.
You find yourself having to change many unrelated methods when you make changes to a class. For example, when adding a new product type you have to change the methods for finding, displaying, and ordering products.
Sometimes different parts of the code contain identical groups of variables (such as parameters for connecting to a database). These clumps should be turned into their own classes.
If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions.
Someone was motivated to create inheritance between classes only by the desire to reuse the code in a superclass. But the superclass and subclass are completely different.
You should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do.
In object-oriented programming, and especially in Domain-Driven Design, objects are said to be anemic if they have state but lack behavior. Some kinds of objects, such as Data Transfer Objects (DTOs), are expected to simply be a collection of data.
A way to implement and apply SOLID design principles, Design Patterns and improve code quality in our software projects.
class InsertionSort {
public function sort(array $array) {
// 1 level
for ($i = 0; $i < count($array); $i++) {
// 2 level
$x = $array[$i];
for ($j = $i - 1; $j >= 0; $j--) {
// 3 level
if ($array[$j] > $x) {
$array[$j + 1] = $array[$j];
$array[$j] = $x;
}
}
}
return $array;
}
}class InsertionSort {
public function sort(array $array) {
for ($i = 0; $i < count($array); $i++) {
$array = $this->insert($array, $i);
}
return $array;
}
protected function insert(array $array, $i) {
$x = $array[$i];
for ($j = $i - 1; $j >= 0; $j--) {
$array = $this->swap($array, $x, $j);
}
return $array;
}
protected function swap(array $array, $x, $j) {
if ($array[$j] > $x) {
$array[$j + 1] = $array[$j];
$array[$j] = $x;
}
return $array;
}
}class HomeController
{
protected function indexAction()
{
if ($this->security->isGranted('ADMIN')) {
$view = 'admin/index.html.twig';
} else {
$view = 'home/access_denied.html.twig';
}
return $this->render($view);
}
}class HomeController
{
protected function indexAction()
{
if ($this->security->isGranted('ADMIN')) {
return $this->render('admin/index.html.twig');
}
return $this->render('home/access_denied.html.twig');
}
}if (filter_var($email, FILTER_VALIDATE_EMAIL) === false) {
throw new InvalidEmailException;
}
$emailDnsServiceProvider->verfiy($email);class Email {
public function __construct(string $email) {
// validate email
}
}
$emailDnsServiceProvider->verify(new Email($email));class Bucket {
protected $products = [];
// many other things...
}class Bucket {
/** @var ProductCollection */
protected $products;
// many other things...
}
class ProductCollection implements Iterator { // ... }This is the direct example of the Law of Demeter, only talk to your friends, where you should never use more than one object operator. The exception exists for Fluent Interface for example, which is another approach and doesn’t belong to this rule.
Applicazione legge di Demetra
function delTmpFiles($p) { ... }
function sort(array $a) {
for ($i = 0; $i < count($a); $i++) { ... }
}function deleteTemporaryFiles($path) { ... }
function sort(array $array) {
for ($index = 0; $index < count($array); $index++) { ... }
}The original rule says we must have not more than 50 lines per class, which in PHP is really easy to reach even with a small entities, due to code styles and PHPDoc comments. But anyway, what we should do it’s to keep them as small as possible. The aim here is also to avoid the God Object anti-pattern
We don’t even need an example here, the rule is so extreme and simple,no more than two instance variable per class, this ensure you’re respecting the High Cohesion and the Single Responsibility Principle. If it contains more than two variables, then maybe your class it’s doing too much
class Car {
protected $speed;
protected $people;
public function getSpeed() { ... }
public function setSpeed($speed) { ... }
public function setPeople($people) { ... }
public function getPeople() { ... }
}class Car {
protected $speed;
protected $people;
public function onBoardPerson() { ... }
public function dropOffPerson()
{
if ($this->people === 0) {
throw new CarEmptyException;
}
$this->people--;
}
public function accelerate($speed)
{
$this->speed += $speed;
}
public function decelerate($speed) { ... }
}