Reputation: 5248
According to a rule in the spryker/architecture-sniffer:
All the factory methods should be public by default
Is there any good argument for that? I never stumbled upon this before when using factory patterns.
Upvotes: 1
Views: 391
Reputation: 51
This rule is mainly related to the Spryker SCOS Core development.
This part of the Spryker OS is a PHP-based E-Commerce framework. As it is a framework, it aims to provide better customization and extension capabilities. Therefore a strict rule regarding open visibility of factory methods supports users in taking full control over dependency injections happening in factories in every single module.
This rule could also be useful for common OSS libraries, that aim high customizability. It implies constraints on "hidden" for customization business logic and requires a conscious opt-out from an engineer. In Sprykers case, the partnership network would use this approach to provide highly customizable Integration modules.
For typical PHP project use-cases, this rule could be less useful or even useless, deeply contradicting the protective nature of project development.
UPD: Let's take an example. Order could be a complex object including multiple dependencies, like Order Item. Having access to all parts from the beginning makes it easier for projects and enhances upgradability: there won't be a BC-break in case Core decided to access a factory method externally by switching the visibility modifier from protected to public. Therefore one can customize factory methods safely.
Upvotes: 5
Reputation: 17066
It looks like their definition of a "factory" is nothing more than a list of specific class names.
In general, there is no reason a factory must be public. Do note that different factory patterns vary wildly in terms of implementation, and you may see every creational pattern under the sun referred to as a "factory". The word itself is so broad it has almost no meaning.
Upvotes: 1