5 ms·

I've worked with a lot of different languages, developing games and server software, for 15 years. I and everyone I've worked with always tries our best to give

I've worked with a lot of different languages, developing games and server software, for 15 years. I and everyone I've worked with always tries our best to give reasonable, readable names to things. I've never needed to call something a "Factory". Let alone a "FactoryFactory" or "FactoryFactoryFactory". I don't know what it is about Java that makes people write code and name things like this. This kind of stuff is just foreign to me, and I just don't understand any of the rationale behind it. I hear about it all the time, but can't fathom how code ends up like this.

twohlix_ 9y ago
"There are two hard problems in Computer Science: naming things, cache invalidation, and off by one errors" People give up on the naming things because the name they're seeing makes sense to them in that moment and they may not realize how confused they'll be when they come back to the code in 3 months. May be a lack of experience in maintaining "old code" or just part of the programming culture they're in.
- bayonetz 9y ago
  "Comments are for people other than yourself and that includes you because future you is not you"
flavio81 9y ago
>I don't know what it is about Java that makes people write code and name things like this. The cause is lack of abstraction and a very limited(rigid, opposite of "flexible") object system. The programmer must use some specific design patterns as workaround and thus name classes according to the semantics of the pattern applied.
pillowkusis 9y ago
I think a portion of it may be java's widespread use in large, "enterprise" environments where due to a variety of cultural and technical factors there's a high level of complexity and abstraction. Pretty soon it becomes the norm. I know plenty of java codebases that are clean, readable, and FactoryFactory-free, but never from an "enterprise" company.
beager 9y ago
Well, a factory pattern is a well-defined pattern in OO software design, and one that a developer of any experience level can look up and understand. Your particular implementation may give rise to a more plain and contextually-accurate name, but if you call it something other than a Factory, posterity may need more time and context to discern what your code does. If I'm a new developer on a project, I know what a SprocketFactory does, and I know that I'm going to get SprocketFactorys from a SprocketFactoryFactory, and I know that if I call the SprocketFactoryFactoryFactory, I'm sure as hell gonna get back a SprocketFactoryFactory, which will then give me a SprocketFactory, which will then produce Sprockets.
- lostcolony 9y ago
  I like how you assume that a mind that doesn't balk at "SprocketFactoryFactoryFactory" is also a mind that will ensure the implied contract of that name is adhered to. But I guess that sort of optimism -does- come with 'new developer on a project', so you're probably correct in what the developer will think they know.
  - beager 9y ago
    I think between a horrible application of a pattern that has a good chance of being implemented properly and a horribly named class that leaves no potential to intuit its behavior, you might fare better with the former, as a new dev. But at that level it's all subjective.
- chimprich 9y ago
  If I'm a new developer on a project and see a class called "SprocketFactoryFactoryFactory" I'm probably going to cry for a bit and wonder whether I couldn't have got a better gig, and then try to figure out a better way of producing sprockets. Human short-term memory only has a size limit of about 4 simultaneous chunks so once you're juggling those levels of indirection any development is going to be glacially slow until you've acquired a great deal of experience with the codebase. Out of interest, can you describe a concrete case where multiple levels of factory patterns have actually been justified and resulted in simpler code than an alternative?
Parcissons 9y ago
That overengineered part is the beauty of it. If you explain this to anyone outside the field, there eyes will glaze over, the will nod vehemently when asked for agreement and sign the consultant hours. Sometimes its just enough to appear clever.
ajkjk 9y ago
I think a big part of it is that common libraries do it and ask you to do it more. Spring and Tomcat and etc are, imo, abominations of complexity -- but you still often find yourself buying into their ecosystems. Especially if you're working on code that's a few years old.
- ajkjk 9y ago
  I'll add: both Spring and Tomcat exemplify this quality that a lot of earlier (2000-era) Java frameworks have (others: Hibernate, actually literally anything that embraces XML...), of being "extensible mostly in name only". You can, in theory, implement modules that tie into various parts of their functionality -- and in practice I've found myself doing it occasionally -- but it's almost always regrettable. Anything you figure out how to do in these will itself just become un-figure-outable for the next engineer who handles it. (One of the most frustrating tasks in my engineering career involved trying to debug why Spring beans loaded by a Spring-Tomcat integration layer, in the initialization of a Tomcat container, weren't discovering XML files loaded at another stage of initialization. When I look back on that year I think I might have indirectly changed jobs because of it. Hah.)
opmac 9y ago
In OOP, a factory is a pretty common design pattern, and I'm a bit surprised you've never seen it in 15 years of software development... considering it's taught in schools these days. In a nutshell, a factory is a class who's purpose is to generate instances of other classes (https://en.wikipedia.org/wiki/Factory_method_pattern https://en.wikipedia.org/wiki/Factory_method_pattern). The main reason they're used is to create objects without specifying the class of the object, however there are plenty of other reasons why they're common as well. You start stretching it when you have FactoryFactory. This presumably would be a factory that creates factories. If I saw this in a code review, I would call it out, as it could most likely be refactored to be simpler. FactoryFactoryFactory is beyond silly.
- qw 9y ago
  I think you misread the comment. The poster says that the classes did not have the word «factory» in the name. The functionality was the same.

twohlix_ 9y ago

"There are two hard problems in Computer Science: naming things, cache invalidation, and off by one errors" People give up on the naming things because the name they're seeing makes sense to them in that moment and they may not realize how confused they'll be when they come back to the code in 3 months. May be a lack of experience in maintaining "old code" or just part of the programming culture they're in.

bayonetz 9y ago
"Comments are for people other than yourself and that includes you because future you is not you"

flavio81 9y ago

>I don't know what it is about Java that makes people write code and name things like this. The cause is lack of abstraction and a very limited(rigid, opposite of "flexible") object system. The programmer must use some specific design patterns as workaround and thus name classes according to the semantics of the pattern applied.

pillowkusis 9y ago

I think a portion of it may be java's widespread use in large, "enterprise" environments where due to a variety of cultural and technical factors there's a high level of complexity and abstraction. Pretty soon it becomes the norm. I know plenty of java codebases that are clean, readable, and FactoryFactory-free, but never from an "enterprise" company.

beager 9y ago

Well, a factory pattern is a well-defined pattern in OO software design, and one that a developer of any experience level can look up and understand. Your particular implementation may give rise to a more plain and contextually-accurate name, but if you call it something other than a Factory, posterity may need more time and context to discern what your code does. If I'm a new developer on a project, I know what a SprocketFactory does, and I know that I'm going to get SprocketFactorys from a SprocketFactoryFactory, and I know that if I call the SprocketFactoryFactoryFactory, I'm sure as hell gonna get back a SprocketFactoryFactory, which will then give me a SprocketFactory, which will then produce Sprockets.

lostcolony 9y ago
I like how you assume that a mind that doesn't balk at "SprocketFactoryFactoryFactory" is also a mind that will ensure the implied contract of that name is adhered to. But I guess that sort of optimism -does- come with 'new developer on a project', so you're probably correct in what the developer will think they know.
- beager 9y ago
  I think between a horrible application of a pattern that has a good chance of being implemented properly and a horribly named class that leaves no potential to intuit its behavior, you might fare better with the former, as a new dev. But at that level it's all subjective.
chimprich 9y ago
If I'm a new developer on a project and see a class called "SprocketFactoryFactoryFactory" I'm probably going to cry for a bit and wonder whether I couldn't have got a better gig, and then try to figure out a better way of producing sprockets. Human short-term memory only has a size limit of about 4 simultaneous chunks so once you're juggling those levels of indirection any development is going to be glacially slow until you've acquired a great deal of experience with the codebase. Out of interest, can you describe a concrete case where multiple levels of factory patterns have actually been justified and resulted in simpler code than an alternative?

Parcissons 9y ago

That overengineered part is the beauty of it. If you explain this to anyone outside the field, there eyes will glaze over, the will nod vehemently when asked for agreement and sign the consultant hours. Sometimes its just enough to appear clever.

ajkjk 9y ago

I think a big part of it is that common libraries do it and ask you to do it more. Spring and Tomcat and etc are, imo, abominations of complexity -- but you still often find yourself buying into their ecosystems. Especially if you're working on code that's a few years old.

ajkjk 9y ago
I'll add: both Spring and Tomcat exemplify this quality that a lot of earlier (2000-era) Java frameworks have (others: Hibernate, actually literally anything that embraces XML...), of being "extensible mostly in name only". You can, in theory, implement modules that tie into various parts of their functionality -- and in practice I've found myself doing it occasionally -- but it's almost always regrettable. Anything you figure out how to do in these will itself just become un-figure-outable for the next engineer who handles it. (One of the most frustrating tasks in my engineering career involved trying to debug why Spring beans loaded by a Spring-Tomcat integration layer, in the initialization of a Tomcat container, weren't discovering XML files loaded at another stage of initialization. When I look back on that year I think I might have indirectly changed jobs because of it. Hah.)

opmac 9y ago

In OOP, a factory is a pretty common design pattern, and I'm a bit surprised you've never seen it in 15 years of software development... considering it's taught in schools these days. In a nutshell, a factory is a class who's purpose is to generate instances of other classes (https://en.wikipedia.org/wiki/Factory_method_pattern https://en.wikipedia.org/wiki/Factory_method_pattern). The main reason they're used is to create objects without specifying the class of the object, however there are plenty of other reasons why they're common as well. You start stretching it when you have FactoryFactory. This presumably would be a factory that creates factories. If I saw this in a code review, I would call it out, as it could most likely be refactored to be simpler. FactoryFactoryFactory is beyond silly.

qw 9y ago
I think you misread the comment. The poster says that the classes did not have the word «factory» in the name. The functionality was the same.