4 ms·

> It drives me nuts to deal with the typical Java "Each class has its own file -no matter how small" thing. Couple this with extensive use of inheritance and d

> It drives me nuts to deal with the typical Java "Each class has its own file -no matter how small" thing. Couple this with extensive use of inheritance and design patterns, and you have a recipe for awfulness. One of my previous teams had an implementation where rendering a piece of HTML would involve digging through about twenty different source files, each with maybe 3-4 lines of actual code other than the class definition boilerplate. One top-level line would send you down the inheritance hierarchy of ClassThatGetsData/ClassThatGetsDataPlusThisOneOtherThing/...PlusThisOtherOtherThing/... etc etc, then the same thing for ClassThatProcessesData/... and then ClassThatRendersData/... Adding a single bit of data to rendered HTML (e.g. a tiny star for 'this product is well-reviewed') would involve altering every single source file in the multiple trees, and maybe adding some new specialisations to make the trees even deeper. At the time, fresh out of Uni with a head full of design patterns, I thought this was just how enterprise code was meant to be structured!

radicalbyte 5y ago
It takes a long time for some people to understand that complexity is the enemy; and for patterns in particular it takes some people a long time to learn when to apply them. Same thing for algorithms: BloomFilters are the classic example. You can tell when it has hit the font page of HackerNews recently because suddenly everyone starts looking for problems that it can solve (poorly). Just don't get me started on blockchain... :-)
ravenstine 5y ago
> At the time, fresh out of Uni with a head full of design patterns, I thought this was just how enterprise code was meant to be structured! Ugh... and that's the flaw in teaching design patterns. Don't worry, that happened to me too, though I didn't go to a university. Design patterns are an advanced tool. If you're learning to code, design patterns are mostly non-applicable to the kinds of problems that newbs are solving. Design patterns are meant for specific problems, but somehow we end up believing they're the end-all-be-all and that we must be using some design pattern in our work. If you have design patterns pounded into your head, and you believe the only design patterns that exist are the one's someone has already named, then not using a particular design pattern can seem like chaos even when it's not. I wish we'd stop teaching that shit. If you've been coding long enough and faced complex enough problems, you'll either come to embrace some design patterns or you won't. Otherwise they'll likely just be misapplied. OOP fits this view of mine as well. In general, I don't think most programmers need to be aware off OOP principles because they will almost certainly misuse them. And to what end? Several single purpose classes and "tiny functions" scattered across multiple files that others are now forced to jump between.
- Too 5y ago
  Most “design patterns” are actually just workarounds for lack of expressiveness in old Java versions. In other languages or modern Java you can replace half of them with simple constructs. Factory pattern for example can be replaced with simple inline callbacks to anonymous functions. Same with many others.
novembermike 5y ago
It feels like half the usage of inheritance is also just workarounds for mocking things in unit tests or being able to access things that are private/protected. Everything ends up with an interface and an impl just because of silly language decisions.

radicalbyte 5y ago

It takes a long time for some people to understand that complexity is the enemy; and for patterns in particular it takes some people a long time to learn when to apply them. Same thing for algorithms: BloomFilters are the classic example. You can tell when it has hit the font page of HackerNews recently because suddenly everyone starts looking for problems that it can solve (poorly). Just don't get me started on blockchain... :-)

ravenstine 5y ago

> At the time, fresh out of Uni with a head full of design patterns, I thought this was just how enterprise code was meant to be structured! Ugh... and that's the flaw in teaching design patterns. Don't worry, that happened to me too, though I didn't go to a university. Design patterns are an advanced tool. If you're learning to code, design patterns are mostly non-applicable to the kinds of problems that newbs are solving. Design patterns are meant for specific problems, but somehow we end up believing they're the end-all-be-all and that we must be using some design pattern in our work. If you have design patterns pounded into your head, and you believe the only design patterns that exist are the one's someone has already named, then not using a particular design pattern can seem like chaos even when it's not. I wish we'd stop teaching that shit. If you've been coding long enough and faced complex enough problems, you'll either come to embrace some design patterns or you won't. Otherwise they'll likely just be misapplied. OOP fits this view of mine as well. In general, I don't think most programmers need to be aware off OOP principles because they will almost certainly misuse them. And to what end? Several single purpose classes and "tiny functions" scattered across multiple files that others are now forced to jump between.

Too 5y ago
Most “design patterns” are actually just workarounds for lack of expressiveness in old Java versions. In other languages or modern Java you can replace half of them with simple constructs. Factory pattern for example can be replaced with simple inline callbacks to anonymous functions. Same with many others.

novembermike 5y ago

It feels like half the usage of inheritance is also just workarounds for mocking things in unit tests or being able to access things that are private/protected. Everything ends up with an interface and an impl just because of silly language decisions.