A brief description of SOLID principles

1. Hello there!

2. Who am I?
Yoan-Alexander Grigorov
PHP developer (with pride!)
Software Engineer
Critic
Design Patterns adventurer

3. SOLID design?

4. Imagine code as a painting

6. Well... maybe not this one in particular!

8. Now that's better!

9. Nothing against modern art, but...

10. Code should be easy to recognize!

11. How a project starts:

13. Several months later...

15. What is going wrong?
● Frequently logic changes are made with “hacks”
without refactoring
● Lack of knowledge on … stuff
● Lack of discipline

16. SOLID? What's that?
● Single responsibility
● Open-closed
● Liskov substitution
● Interface segregation
● Dependency inversion

17. What SOLID can't do?
● Cure ebola
● Explain why is there PHP 7 coming out, but no PHP
6?!?!?
● Make Bulgarian politicians suck less

18. Let's break it down!

19. Single responsibility principle
Every variable, class, function, etc. should have a single
responsibility, described in it's name (if any).

20. Single responsibility principle
Basically it's bad if we have a function (or class)
that does more then what it's name says.

21. Single responsibility principle
Here is one real-life example how bad it is to break
this rule:

23. Single responsibility principle
Hidden features can have unexpected effects

24. Single responsibility principle
● Bad code example:
<?php
class InsurancePDFCreator {
// … some code
public function createPDFContents(Policy $policy);
public function downloadInsuranceCompanyLogos();
}

25. Single responsibility principle
● Good code example:
<?php
class InsurancePDFCreator {
// … some code
public function createPDFContents(Policy $policy);
}
// somewhere else
class InsuranceCompanyLogosDownloader {
public function download();
}

26. Conclusion
● Define your desired contexts carefully
● Make sure that there is only one responsibility for a
operation, class, method, module, etc.
● If you need to have a more abstract operations that
combine several stuff, find for them more abstract
names.
● And... Single Responsibility Principle is not
enough

27. Interface Segregation Principle
No system (module, class) should be required to depend
on methods it does not use.

28. Interface Segregation Principle
This is pretty much an extension to the SRP

29. Interface Segregation Principle
● Avoid having classes of “mothership” type
● Avoid the “Manager” type classes

30. Interface Segregation Principle
● Imagine this code:
<?php
class UsersManager {
public function createUser($username, $email);
public function deleteUserPicture($userId);
public function notifyUser($userId, $msg);
}

31. Interface Segregation Principle
It's bad because:
● It's provides a general-purpose interface
● When you include this class, you usually call one of
those methods

32. Interface Segregation Principle
The good way to do it:
● Use a set of client-specific classes (interfaces)
instead of one general-purpose interface
● Be more specific in your context

33. Interface Segregation Principle
Good example:
<?php
class UserCreator {}
class UserPictureDeleter {}
class UserNotifier {}

34. Conclusion
● Is extension to the Single Responsibility Principle
● Favored usage of client-specific interfaces, rather
then one general-purpose (mothership) interface

35. Open-Closed Principle
Classes should be opened for extension, but closed for
modification

36. Open-Closed Principle
<?php
class ProductDiscountCalculator {
public function calculateDiscount(Product $product)
{
// some serious business here for $discountRate
return $product->getPrice() / $discountRate;
}
}

37. Open-Closed Principle
<?php
// somewhere else a naughty developer writes this:
class MyProductDiscountCalc extends ProductDiscountCalculator {
public function calculateDiscount(Product $product)
{
// Hardcoded discount here
return 300;
}
}

38. Open-Closed Principle
Why is this so bad?
● ProductDiscountCalculator is not an interface, but a
specific class
● We can push into usage it's replacement
● The code relies on ProductDiscountCalculator, but
it's children are changing the behavior and this is
bad

39. Open-Closed Principle
REMEMBER!
● Modifying (overriding) existing methods is bad
● Extending them (e.g. add new methods or implement
abstract methods) is good

40. Open-Closed Principle
“But who is using specific types anyways? Can't we just use
interfaces?”
- Yes, that's why we should look at the next principles.

41. Open-Closed Principle
I bet you are puzzled now!
Don't be afraid, open-closed principle is used best
with his fellow brother the Liskov Substitution
principle!

42. Open-Closed Principle
● It bit better way to do it:
class MyProductDiscountCalc extends ProductDiscountCalculator {
public function myCalculateDiscount(Product $product)
{
// Hardcoded discount here
return 300;
}
}

43. Open-Closed Principle
Not the best way, but Open-Closed principle works
best with his friends from SOLID!

44. Liskov Substitution Principle
Subtypes could replace their parents, and the program
should have the same behaviour.

45. Liskov Substitution Principle
Basically we must make sure that new derived
classes are extending the base classes without
changing their behavior. It's that easy.

46. ???

47. Liskov Substitution Principle
As ridiculous as it may sound I'll explain you what
it's the meaning behind this.

48. Liskov Substitution Principle
Let's remember the previous example:
class ProductDiscountCalculator {
public function calculateDiscount(Product $product);
}
class MyProductDiscountCalculator ...
public function myCalculateDiscount(Product $product);
}

49. Liskov Substitution Principle
How do you know which is which?
<?php
if ($calc instanceof ProductDiscountCalculator) {
$calc->calculateDiscount($product);
}
if ($calc instanceof MyProductDiscountCalculator) {
$calc->myCalculateDiscount($product);
}

50. Liskov Substitution Principle
I suppose you don't do such horrible things like
type checking

51. Liskov Substitution Principle
● One solution is to use abstract method:
<?php
abstract class AbstractDiscountCalc {
public function calculateDiscount(Product $product) {
return $this->getDiscountForProduct($product);
}
abstract protected function
getDiscountForProduct(Product $product);
}

52. Liskov Substitution Principle
<?php
class DefaultProductDiscountCalc extends AbstractDiscountCalc
{
protected function getDiscountForProduct(Product $product)
{
// our main algorithm for $discountRate
return $product->getPrice / $discountRate;
}
}

53. Liskov Substitution Principle
<?php
class MyProductDiscountCalc extends AbstractDiscountCalc
{
protected function getDiscountForProduct(Product $product)
{
// Fixed discount
return 300;
}
}

54. Liskov Substitution Principle
Still not the best way, but much better!

55. Dependency inversion principle
One system should depend on abstractions (interfaces)
rather then concretions

56. Dependency inversion principle
Remember Dependency Injection?
Pretty much DI is following the Dependency
Inversion principle

57. Dependency inversion principle
● So our previous example would use an interface:
<?php
interface DiscountCalculator {
public function calculateDiscount(Product $product);
}

58. Dependency inversion principle
This way we depend on interfaces, not on specific
classes (which is the main idea behind interfaces)

59. Dependency inversion principle
You can still define a mid-level abstract class to
implement just some parts of the logic.

60. SOLID and others
● Use SOLID with TDD
● You can make DDD even better with SOLID
● SOLID principles are universal

61. Thank you for listening!
● joan.grigorov@gmail.com
● @YoanDev
● http://bgscripts.com