SOLID Compliance

Yii 3.0 Ask a question
1

Hello,

In the roadmap it is announced that Yii3 will follow best practive as SOLID :

“Be based on best practices such as SOLID, GRASP etc. and teach them to community.”

But, i’m following the dev of Yii3, and what I see is that there is a lot of attributes in new classes déclared as private, which, for me, completely breaks the Open Close Principle of SOLID.

"In object-oriented programming, the open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”;[1] that is, such an entity can allow its behaviour to be extended without modifying its source code. " (Wikipedia).

I think most of these must be declared protected to ensure SOLID compatibility. Is it planned?

Thank you

PS :
This is a repost from the Issue board (https://github.com/yiisoft/yii-core/issues/185).

I was answered this :
I think you’re misinterpreting open/closed principle. It is not about “make everything public/protected, so I can change everything”. It is about allowing to change one implementation by another, so you can use custom components without changing framework code. For example, you can freely change DB or URL manager components without editing a single Yii file. It already works pretty fine in Yii 2, and in Yii 3 should be even easier due to relying on DI and interfaces.

I never said Open/Close meant “make everything protected/public”, but Open Close is not about replacing or using custom components (i have no doubt this is the case), it is about extending and polymorphism.

Here is another part of the definition : " A module will be said to be open if it is still available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs."

How am I suppose to extend a class if most of it’s attributes are not accessible?

2

Open-Closed reads as “you should be able to extend a classes behavior, without modifying it”.

A class or module (a set of related classes) should hide its implementation details (i.e. how exactly things are done) but have a well defined interface that both allows its usage by other classes (public methods) and extension via inheritance ( protected and public methods).

3

So having many things private means that it’s not meant to be extended in these parts. If customization isn’t possible then there should be an issue created and we’ll re-design a class.

4

I love these buzzwords :wink: … and I think there are are philosophical and practical aspects to consider.

Some say “only open well planned points ‘open’ as it’s part of the API and needs to be tested and kept stable”
Others say: “do not ‘close’ without good reason”

Looking at it as “Framework designer” I understand the approach of keeping methods private: If it’s not kept private it is a place to hook in for everybody who uses the framework and modifying/improving the internal logic of a class becomes a minefield as even minor changes may break everything for those who extended my class. So it’s an advantage to keep methods private, letting people just override where I planned people to override. (It just gives me more freedom to make changes in the future without causing a incompatibility nitemare - I just need to keep the public and protected methods stable)

Looking at it from the “framework user” point of view, I hate everything private. Often just a little behavoral change is necessary, but when the framework designer did not think about letting to change/extend this behavior there is no way and it often ends up in a ugly copy/paste implementation of methods (or dirty tricks like accessing something private with reflection)

So from the user POV it’s always too closed as long something is private - but when changes break his extended class he also does not like it.

2 Likes
5

Ok thank you. I understand your point of view even if I agree more with the other one (good resumé by AndreasP)