search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

OOP and PSR-4 in backdrop? #3014

Open donquixote opened 6 years ago

donquixote commented 6 years ago

(I write this as a curious 3rd party, who is not (yet) involved with Backdrop development)

Background

Currently, one major difference between Backdrop and Drupal 8 is that D8 has classes and interfaces in a PSR-4 directory structure, whereas Backdrop still has most of the procedural code from Drupal 7.

I think that the move to PSR-4 and objects was correct, and Backdrop should follow one day or another. However, I think that some things should have been done differently in Drupal.

A lot of the classes are entities / domain objects, or "managers" with more than one responsibility. Overall, I see a lack of "SOLID" principles.

Proposed change

If and when Backdrop wants to become more object-oriented (OOP), I suggest to start with small components with single responibilities. Every proposed class that does not look "SOLID" should be on hold, until someone has a better idea.

A good strategy to achieve this is to focus on "behavior objects" instead of entities or manager-type services. I opened a Drupal issue for this, #2956549 Policy: Atomic behavior objects , I don't know yet where this is going. But even if a consensus is found in this direction for Drupal 8, there are still all the existing classes which I find generally too big.

Backdrop has the chance to avoid mistakes (subjective opinion, please forgive me) that were made in D8.

I also think that Composer integration would help, but this is a separate issue with its own pros and cons, see #2257.

generalredneck commented 5 years ago

A port of the xautoload module would achieve this I believe https://www.drupal.org/project/xautoload

klonos commented 5 years ago

I think that the move to PSR-4 and objects was correct, and Backdrop should follow one day or another.

OOP and the higher bar it raised was one of the reasons why Drupal 7 was forked into Backdrop. While many of the "seasoned" Backdrop core team is equally skilled with OOP, many of the contributors in the community are "tinkerers" and self-taught PHP devs, which still find OOP confusing. If we switched to OOP, we'd be loosing that part of the community.

klonos commented 5 years ago

I also think that Composer integration would help, but this is a separate issue with its own pros and cons

Many of the more "professional" members of the community expressed an interest in this, as it would allow automation of their deployment/release workflow. I am personally all of that, so long as we support composer (as opposed to requiring it).

generalredneck commented 5 years ago

I do believe though that we should have to option to incorporate it which is why I suggest something like xautoload. It gives you a choice as well as the ability to abstract out portions of code to improve maintainability between many versions of a module including D7 d8 and backdrop... much the same way entity api or ctools works... with the added advantage of auto loading. Not saying put it in core... but hella useful in contrib world.