1

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.

Peter Badida
  • 11,310
  • 10
  • 44
  • 90
ArSeN
  • 5,133
  • 3
  • 19
  • 26
  • I don't know the PHP and I can tell my opinion, I my experience I have some cases where some method is needed only to make some local operation, for instance for java inside one package, so the method can be friendly (visible only in the package). or maybe in the C++ can be protected. I think that the answer is depended from the language and also from the use case of your factory – vincenzopalazzo Jan 20 '21 at 09:19
  • The thing is that this rule checks that *all* factory methods should be public, which I don't know why they should (independent of the language). – ArSeN Jan 20 '21 at 09:25
  • I agree with you, I don't think that all the methods need to be public, but if I understand well, the repository that you linked it is a framework and there are some internal rules. I don't know why and I don't think is necessary from a general point of view – vincenzopalazzo Jan 20 '21 at 09:30

2 Answers2

5

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.

Denis Turkov
  • 51
  • 3
  • Hmm, how is it *more* customizable by having all methods public though? I can't quite grasp that point. My point being that it would not make it less so if the rule at least allowed protected methods. – ArSeN Feb 24 '21 at 17:19
  • 1
    Factories being a part of general infrastructure are available in many places (eg Facades, Clients, Controllers). Having them public makes sure, that all factory methods are available there. At the end of the day, factory methods are made to be used externally, not only internally. When building complex models, that include the creation of multiple entities allows using particles independently (eg Order could include Order Items, using the open factory method for Order Items independently is a useful feature for projects even it's not used this way in Core). – Denis Turkov Feb 24 '21 at 21:16
1

It looks like their definition of a "factory" is nothing more than a list of specific class names.

https://github.com/spryker/architecture-sniffer/blob/64ec598e65cccef7ec72bfdc88d241663a42bfb1/src/Common/Factory/AbstractFactoryRule.php#L23

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.

jaco0646
  • 15,303
  • 7
  • 59
  • 83