Timeline for Why should I use a factory class instead of direct object construction?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21, 2022 at 16:48 | comment | added | Sinaesthetic | ^ Just in case someone wants to start an argument over the accuracy of this as opinion - Bob Martin coined the term and he explains exactly this misunderstanding in his book Clean Architecture. Just wanted to leave the note here for someone that is still trying to learn the difference. Easier to look at SRP as a system level architecture concern whereas SoC is an component level architectural concern. | |
| Oct 21, 2022 at 16:36 | comment | added | Sinaesthetic | Just need to point out that this has nothing to do with SRP -- it's SoC (separation of concern). SRP is more of a people problem with regard to code, not a code problem with regard to function. "one reason to change" actually refers to stakeholders - it's a commentary on conflicting intent (e.g. payroll vs. finance which are similar enough to collide and break each other). | |
| Jun 4, 2020 at 11:43 | comment | added | Code Name Jack | Nice answer, but I have one disagreement, new being evil is more of C++ thing. for C#/Java new is perfectly alright with most programmers. | |
| Feb 11, 2018 at 18:25 | comment | added | jgmjgm | I'm programming on a codebase where because the OOP implementation doesn't allow overloading the constructor, the use of public constructors is effectively banned. This is already a minor problem in languages that do allow it. Like create temperature. Both Fahrenheit and Celsius are floats. You can however box those, then problem solved. | |
| Dec 9, 2017 at 1:54 | comment | added | Breno Salgado | Perfect answer. Right on point with the 'theory meets reality' part. Just think of how many thousands of developers and human time spent cargo-cult praising, justifying, implementing, using them to then falling to the same situation you described, is just maddening. Following YAGNI, Ive never identified the need to implement a factory | |
| May 4, 2015 at 15:55 | history | edited | KeithS | CC BY-SA 3.0 | added 10 characters in body |
| May 4, 2015 at 15:52 | comment | added | KeithS | A protected and/or internal constructor would be such a signal; this constructor would only be available to consuming code whether in a subclass or within the same assembly. C# does not have a keyword combination for "protected and internal" meaning only subtypes within the assembly could use it, but MSIL has a scope identifier for that type of visibility so it's conceivable the C# spec could be extended to provide a way to utilize it. But, this really doesn't have much to do with the use of factories (unless you use the restriction of visibility to enforce a factory's use). | |
| Feb 11, 2015 at 16:12 | comment | added | supercat | Another problem with public constructors is that there's no nice way for a class Foo to specify a public constructor should be usable for the creation of Foo instances, or the creation of other types within the same package/assembly, but should not be usable for the creation of types derived elsewhere. I don't know of any particularly compelling reason a language/framework couldn't define separate constructors for use in new expressions, versus invocation from subtype constructors, but I don't know of any languages that do make that distinction. | |
| Aug 14, 2014 at 17:48 | comment | added | jean | Love this answer, in special after reading all other ones. I can add almost all (good) new coders are too much dogmatic about principles by the simple fact they really want to be good but don't learned yet the value of keeping things simple and don't overkill. | |
| Aug 14, 2014 at 16:24 | history | edited | KeithS | CC BY-SA 3.0 | added 855 characters in body |
| Aug 14, 2014 at 16:13 | history | answered | KeithS | CC BY-SA 3.0 |