Chapters

18 Chapters | 1:54:58 |

01

SOLID: The Good, The Bad & The Real World

3:22
02

Single-Responsibility Principle: What is it?

7:38
03

SRP: Responsibilities

6:24
04

Refactoring for SRP

7:23
05

SRP: Takeaways

4:12
06

Open–Closed Principle

7:24
07

OCP: Autoconfiguration & tagged_iterator

4:36
08

OCP: Takeaways

5:48
09

Liskov Substitution Principle

4:19
10

Liskov: Unexpected Exceptions

6:43
11

Liskov: Substituting a Class

7:24
12

Liskov: What Changes *Are* Allowed?

7:12
13

Liskov Takeaways & Service Alias

4:54
14

Interface Segregation Principle

6:29
15

ISP: Refactoring & Takeaways

9:24
16

Dependency Inversion Principle

5:31
17

Refactoring Towards Dependency Inversion

6:53
18

DIP: Takeaways

9:22

> OOP > Write SOLID Code & Impress your Friends

Buy Access to Course Buy Access

05.

SRP: Takeaways

|

Autoplay

Previous Chapter

Next Chapter

Login or Register to check out the script

5 Comments

Sort By

Login or Register to join the conversation

Sargath 5 years ago

There is also important to remember about the tests. With this implementation we can only test public methods of `UserManager` (for instance, the Boston way input-output). In such case we cannot unit test token generation in separation. So I would slightly argue about some concepts presented here ;)

Cheers

|

MolloKhan SFCASTS Sargath 5 years ago edited

Along with what Ryan said, I'd say there are other ways to test private methods.

1) Use reflection to be able to access to the private method
2) Test it indirectly. In this case, you can test what $user->getConfirmationToken() returns
3) Add an integration test for checking the whole process works (create a new user, follow confirmation, link, etc)

1 |

Sargath MolloKhan 5 years ago

I wouldn't test private methods because it means that you test the implementation and not the interface with a black box testing approach. This might lead to fragile tests and bad composition thus encapsulation.
There is only one case that I would test private methods. When I have got a legacy codebase and method is crucial to be tested before the refactor.

So with this manner I would only check exposed, public interface. I encourage you to check https://github.com/sarven/u... there are some nice tips out there

Cheers

|

MolloKhan SFCASTS Sargath 5 years ago

Thanks for the link Sargath, it seems useful. One last thing I have to say about testing private methods. I'd rather use reflection or making the method public (and tag it as internal method "do not call this directly") than not testing it at all. Validating your logic works as expected brings much more value than achieving encapsulation

|

weaverryan SFCASTS Sargath 5 years ago edited

Hey Sargath!

That's a very valid point - thanks for sharing it! We do mention this point later in the OCP section... actually talking about SRP :p - it's at the very end of the chapter - https://symfonycasts.com/sc...

But you're absolutely right. I'm not sure if SRP specifically "concerns itself" about testability. But, in the real world, if I have complex logic, I WILL split it into its own class / public method *just* to be able to unit test it. That, in itself, is another reason for "splitting".

Cheers!

1 |

Symfony 5.2

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.2",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "composer/package-versions-deprecated": "^1.11", // 1.11.99.1
        "doctrine/annotations": "^1.0", // 1.12.1
        "doctrine/doctrine-bundle": "^2", // 2.3.1
        "doctrine/doctrine-migrations-bundle": "^3", // 3.1.1
        "doctrine/orm": "^2", // 2.8.4
        "knplabs/knp-time-bundle": "^1.15", // v1.16.0
        "phpdocumentor/reflection-docblock": "^5.2", // 5.2.2
        "sensio/framework-extra-bundle": "^6.0", // v6.1.2
        "symfony/console": "5.2.*", // v5.2.6
        "symfony/dotenv": "5.2.*", // v5.2.4
        "symfony/flex": "^1.9", // v1.21.6
        "symfony/form": "5.2.*", // v5.2.6
        "symfony/framework-bundle": "5.2.*", // v5.2.6
        "symfony/http-client": "5.2.*", // v5.2.6
        "symfony/mailer": "5.2.*", // v5.2.6
        "symfony/property-access": "5.2.*", // v5.2.4
        "symfony/property-info": "5.2.*", // v5.2.4
        "symfony/security-bundle": "5.2.*", // v5.2.6
        "symfony/serializer": "5.2.*", // v5.2.4
        "symfony/twig-bundle": "5.2.*", // v5.2.4
        "symfony/validator": "5.2.*", // v5.2.6
        "symfony/webpack-encore-bundle": "^1.6", // v1.11.1
        "symfony/yaml": "5.2.*", // v5.2.5
        "twig/cssinliner-extra": "^3.3", // v3.3.0
        "twig/extra-bundle": "^2.12|^3.0", // v3.3.0
        "twig/twig": "^2.12|^3.0" // v3.3.0
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.2", // 3.4.0
        "fakerphp/faker": "^1.13", // v1.14.1
        "symfony/debug-bundle": "^5.2", // v5.2.4
        "symfony/maker-bundle": "^1.13", // v1.30.2
        "symfony/monolog-bundle": "^3.0", // v3.7.0
        "symfony/stopwatch": "^5.2", // v5.2.4
        "symfony/var-dumper": "^5.2", // v5.2.6
        "symfony/web-profiler-bundle": "^5.2" // v5.2.6
    }
}

Previous Chapter

Next Chapter