So S.O.L.I.D Fu - Designing Better Code

So S.O.L.I.D Fu
Designing Better Code

Abstract
A chat about some of the most important
principles in software development. Discover
or get a refresher on these tried and tested
techniques for designing better code.

What’s SOLID?
5 Principles
● Single Responsibility Principle
● Open / Closed Principle
● Liskov Substitution Principle
● Interface Segregation Principle
● Dependency Inversion Principle
SRP
OCP
LSPISP
DIP
S.O.L.I.D

Why S.O.L.I.D?
● Maintainable
● Understandable
● Extendable
● Testable
● Debuggable
● Reusable
● Robust, less fragile
BETTER
SOFTWARE
SRP
OCP
LSPISP
DIP

class Product
{
public function getId()
public function getName()
public function getPrice()
public function getStock()
public function setStock($stock)
public function getDescription()
}
https://github.com/neilcrookes/SoSOLIDFu

class CreditCard
{
public function getExpiryYear()
public function getExpiryMonth()
public function getLast4()
public function getToken()
}

class Gateway
{
public function purchase(Shop $shop, CreditCard $card)
}

class Shop
{
public function addToBasket(Product $product)
public function removeFromBasket(Product $product)
public function getTotal()
public function getBasket()
public function checkout(CreditCard $card)
protected function sendOrderConfirmationEmail(CreditCard $card)
}

Single
Responsibility
States that
● Classes should have only one reason to change
● Therefore should have only one responsibility

class Basket
{
public function addToBasket(Product $product)
public function removeFromBasket(Product $product)
public function getTotal()
public function getBasket()
}
Class Checkout
{
public function checkout(CreditCard $card)
protected function sendOrderConfirmationEmail(CreditCard $card)
}

Class Checkout
{
public function checkout(Basket $basket, CreditCard $card)
{
try
{
$reference = $this->gateway->purchase($basket, $card);
$this->sendOrderConfirmationEmail($basket, $card);
return true;
}
catch (GatewayException $e)
{
return false;
}
}
}

Open / Closed
Objects or libraries should be open for extension, but closed for modification.
● Easy to add new features OR change behaviour
● Without modifying original
● Purists: without extending original…!?
Eh?

Open / Closed cont
Extension points
● Events
● Plugin architecture
● Composition
● Strategy pattern
● Callbacks

Open / Closed cont
Closed for modification - Clarity of intent
● Final classes
● Private members
● Encourage extension in expected / supported way
● Encourages decoupling
● Reduces risk of breaking changes

final class Checkout
{
{
try
{
$reference = $this->gateway->purchase($basket, $card);
$this->sendOrderConfirmationEmail($basket, $card);
fire(new CheckoutEvent($basket));
return true;
}
catch (GatewayException $e)
{
return false;
}
}
}

{
public function sendOrderConfirmationEmail(Basket $basket, CreditCard $card)
{
$message = "Thank you for your order.n";
foreach ($basket as $item)
{
/** @var Product $product */
$product = $item['product'];
$message .= "n" . $product->getName() . ' x ' . $item['quantity']
. ' @ £' . $product->getPrice();
}
$message .= "nnPayment has been taken from: xxxx xxxx xxxx " . $card->getLast4()
. ' Ex: ' . $card->getExpiryMonth() . '/' . $card->getExpiryYear();
mail('customer@domain.com', 'Your order at my store', $message);
}
}

Liskov Substitution
States that you should be able to swap dependencies for a subclass class without
causing unexpected results

{
public function sendOrderConfirmationEmail(Basket $basket, CreditCard $card)
{
$message = "Thank you for your order.n";
foreach ($basket as $item)
{
/** @var Product $product */
$product = $item['product'];
$message .= "n" . $product->getBasketTitle() . ' x ' . $item['quantity']
. ' @ £' . $product->getPrice();
}
$message .= "nnPayment has been taken from: xxxx xxxx xxxx " . $card->getLast4()
. ' Ex: ' . $card->getExpiryMonth() . '/' . $card->getExpiryYear();
mail('customer@domain.com', 'Your order at my store', $message);
}
}

interface PurchasableInterface
{
public function getId();
public function getPrice();
public function getStock();
public function setStock($stock);
public function getBasketTitle();
}

Interface
Segregation
● An interface should only impose the methods that a client relies on
● Split unrelated interface methods into separate interfaces

interface PurchasableInterface
{
public function getId();
public function getPrice();
public function getBasketTitle();
}
interface StockableInterface
{
public function getStock();
public function setStock($stock);
}

{
}
class Gateway
{
public function purchase(Basket $basket, CreditCard $card)
}

Dependency
Inversion
● High level should not depend on low level modules, both should depend on
abstractions
● Abstractions should not depend upon details. Details should depend upon
abstractions.
● Depend on abstractions (abstracts / interfaces), not concretes
● Code to an Interface

interface ChargeableInterface
{
public function getChargeableAmount();
}
interface GatewayInterface
{
public function charge(ChargeableInterface $chargeable,
PaymentMethodInterface $paymentMethod);
}
interface PaymentMethodInterface
{
public function getToken();
public function getDetails();
}

{
public function checkout(ChargeableInterface $basket, PaymentMethodInterface $card)
}
class Gateway
{
public function purchase(ChargeableInterface $basket, PaymentMethodInterface $card)
}

Conclusion:
Get Classy
● Actually only add some Interfaces, and an Event
● Our code is designed much better
● Easy to understand, extend
● More robust, less likely to introduce bugs
● Lots of classes is fine
● Lots of interfaces is fine

Questions
● Now?
● At the pub?
● @neilcrookes

So S.O.L.I.D Fu - Designing Better Code

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to So S.O.L.I.D Fu - Designing Better Code

Similar to So S.O.L.I.D Fu - Designing Better Code (20)

Recently uploaded

Recently uploaded (20)

So S.O.L.I.D Fu - Designing Better Code