Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Facades #35

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Facades #35

wants to merge 2 commits into from

Conversation

nibra
Copy link
Member

@nibra nibra commented Aug 13, 2022

1. Summary

The facade pattern (also spelled façade) is a software-design pattern commonly used in object-oriented programming.
Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more
complex underlying or structural code. A facade can:

  • improve the readability and usability of a software library by masking interaction with more complex components behind
    a single (and often simplified) API
  • provide a context-specific interface to more generic functionality (complete with context-specific input validation)
  • serve as a launching point for a broader refactor of monolithic or tightly-coupled systems in favor of more
    loosely-coupled code

Developers often use the facade design pattern when a system is very complex or difficult to understand because the
system has many interdependent classes or because its source code is unavailable. This pattern hides the complexities of
the larger system and provides a simpler interface to the client. It typically involves a single wrapper class that
contains a set of members required by the client. These members access the system on behalf of the facade client and
hide the implementation details. [Wikipedia: Facade Pattern]

2. Why Bother?

In Joomla, we have lots of places with code like this:

$this->app->getIdentity()->authorise(...)

or

Factory::getUser()->authorise(...);

While Factory::getUser() is deprecated, $this->app->getIdentity() relies on knowledge about the internal structure.
Being able to use

User::authorise(...);

instead, would lower the cognitive load a lot. Additionally, it would make it easier for us to make changes in the
underlying code without breaking extensions that use the feature in question.
authorise() is just a single example here; there are several other places, where the facade pattern would simplify our lives:

  • App(lication)
  • Auth(orisation)
  • Config
  • Session
  • Lang(uage)
  • Doc(ument)
  • Database
  • Mail(er)
  • Event
  • Log(ger)

use \Joomla\CMS\Application\CMSApplicationInterface;
use Joomla\CMS\Factory;

class App extends Facade
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a good idea to add a requirement for typehint?

/**
 *  @method Documeny getDocument()
 *  @method Potato getPotato()
 *  ....
 * /
class App extends Facade

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, absolutely makes sense.

* Database
* Mail(er)
* Event
* Log(ger)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also Layout? Currently LayoutHelper::render('blabla.layout')
And Toolbar :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The list was not ment to be exhaustive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants