41–50 of 68 posts
Are the generated names verified to be non-real? There could be some overlap.
There is definitely overlap, it tells me that HttpSession is not real, and guess what, https://docs.oracle.com/javaee/6/api/javax/servlet/http/Http...
Earlier quoted context omitted.
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
It is fancy around these parts to bash OOP and other things that aren't JavaScript/Clojure/Haskell/Rust/etc; DRY, SRP, LSP, OCP are very valuable. There's a reason there's a score of enterprise-grade software being written with exactly those principles in mind. I am not discounting Functional Programming in anyway. But to dismiss OOP and the design patterns is a fool's errand. It has its place, and rightly so. Look a…
This is sort of like making fun of German for using long combinations of smaller words to denote a concept. Or making fun of medical jargon. (ha ha, you said subdermal hematoma not bruise) Once you know what the individual words mean, you can use them in different places, and know right away what the class does. Do you need to use 80% of these? No, but they're there, like parts in a car, in case you need to tinker.
And it's not like anyone is typing these words out. IDEs have auto-completion for that purpose.
Earlier quoted context omitted.
And it's not like anyone is typing these words out. IDEs have auto-completion for that purpose.
Moreover, in Eclipse you can do camel-case completion. So you can type "ACV" and get "AbstractCookieValueMethodArgumentResolver". (I'm not sure if other IDEs do this)
It's not surprising that a Markov chain could put together plausible sounding class names, because yeah, there are definitely patterns that class names fall into. What's surprising is that one third of the names it's showing me are actually real. I mean, "MetaMetaContextHierarchyConfig" actually exists?
I got "ConfigClassesAndProfileResolverWithCustomDefaultsMetaConfig.ResolverConfig" as real (which I failed to pick... I mean, really ?) and had to doublecheck it really is. Sadly, it's true. What the hell, Spring Framework?
And of course, what about testing the custom overrides of that config?
Well just use the ConfigClassesAndProfileResolverWithCustomDefaultsMetaConfigWithOverridesTests!
Seriously.
It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
My favorite example is the single responsibility principle, which, while a useful guideline, is 100% qualitative. All classes and functions do more than one thing.
Is making a sandwich one thing? Is putting mustard on the bread one thing? Is opening the mustard jar one thing?
The exception might be if you had a function call bitFliper that turned 0s to 1s and vice versa. But that's probably as close as you could get in most programming languages.
Earlier quoted context omitted.
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
It is fancy around these parts to bash OOP and other things that aren't JavaScript/Clojure/Haskell/Rust/etc; DRY, SRP, LSP, OCP are very valuable. There's a reason there's a score of enterprise-grade software being written with exactly those principles in mind. I am not discounting Functional Programming in anyway. But to dismiss OOP and the design patterns is a fool's errand. It has its place, and rightly so. Look a…
"The principle of least surprise" is sadly missing from this API.
Earlier quoted context omitted.
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
It is fancy around these parts to bash OOP and other things that aren't JavaScript/Clojure/Haskell/Rust/etc; DRY, SRP, LSP, OCP are very valuable. There's a reason there's a score of enterprise-grade software being written with exactly those principles in mind. I am not discounting Functional Programming in anyway. But to dismiss OOP and the design patterns is a fool's errand. It has its place, and rightly so. Look a…
This is where the mess begins, because it becomes so cryptic to figure out how to use the FactoryFactory to create your own Factory to create some other types you need. It may be trivial to people who've been hacking with the same languages and frameworks for years, but the principle of least surprise is abandonded for new users attempting to use a framework for the first time.
Functional programming suffers from the same overuse of idioms which are unwelcoming to novices, and often throws away some useful ones in favor of ease of use. FP doesn't necessarily dismiss OOP, and it's often used in combination with functions to write practical programs.
Functional programmers don't see OOP as a problem - it's a very practical tool. The problem is that it's the wrong tool for many problems - particularly if you're just computing functions[1]. That a lot of developers are proficient with OOP and see it as a good way to develop programs is part of the cause - they're blind to alternative methodologies and shoehorning something into an object where it doesn't fit is seen as a being skillful. Also, anything that doesn't conform to the language's narrow view of "the right way" is considered an anti-pattern.
[1]:http://www.yegor256.com/2014/05/05/oop-alternative-to-utilit...