"Make objects have private/protected members" section should be improved

[dmytro-y-dev]

This section doesn't provide any useful explanation when and why to use public, private and protected access modifiers.

Consider adding explanation that

1. public methods and properties are most dangerous for changes, because some outside code may easily rely on them and you can't control what code relies on them. Modifications in class are dangerous for all users of class.
2. protected methods are as dangerous as public, because they are available in scope of any child class. This effectively means that difference between public and protected is only in access mechanism, but encapsulation guarantee is the same (3rd party developers are affected). Modifications in class are dangerous for all descendant classes.
3. private methods are your safe harbor in this doubtful world. They guarantee you that code in your methods is dangerous to modify only in boundaries of single class (which means that when you have tests for your protected/public methods that cover all calls of your private method, and as long as you don't do magic, like side effects or usage of global state, you are safe for modifications and you won't have Jenga effect).

Therefore, use private by default and public/protected when you need to provide access.

There is also one modern trend that I discovered. People, who practice TDD and cover 100% LOC with tests, usually end up with almost 0 private methods, because private methods are hard to test. Encapsulation is then usually guaranteed by usage of shim classes.

This leads to good thing - implementation can be replaced with more performant/maintainable/flexible/better class easier; but this also leads to bad thing - people try to create very thin layers of functionality, like 100 classes of 10 LOC, and every such class performs a single for loop or a single call to real class, with usually too technical name and too thin focus.

Instead, it is better to hide your implementation behind private method first and when it has grown too much (e.g. dependencies for class with private method have grown too much, or LOC are too many) or when you require more flexibility, or you start seeing that it is starting to have different focus than original class - don't hesitate to extract it to separate class.

[TomasVotruba]

Hey, thanks for nice summary.

Could you put it into short PR that would explain it on examples for entry-level programmers?

[dmytro-y-dev]

Yep, but this is just draft, so I wouldn't include it in current state. I will clean it up and provide references to respected sources, and then open PR 👍 .

[dmytro-y-dev]

Opinion on the matter from Fabien Potencier: http://fabien.potencier.org/pragmatism-over-theory-protected-vs-private.html

Guys, I don't have time to clean it up, sorry. You can use what I wrote here, extend/copy-paste, if needed. However, as always in life, there is no single proper way to write code. I feel that my first post is incomplete and requires more in-depth discussion (and it can easily become as long, as current Readme.md). So instead of overthinking, I would suggest you to share whatever works for you in Readme.md. Thanks.

[dmytro-y-dev]

Since PR is already merged and issue is long due, I close it.

@TomasVotruba Thank you for your effort in building a comprehensive guide to best practices for PHP devs! This helps a lot!

[TomasVotruba]

Glad to help 👍 I always miss simple clear example on how to code.

The credit belongs to @peter-gribanov who came up with this idea, boosted it and spread it over the internet 👍