5 ms·

Design patterns implemented in Java

84 points by PleaseHelpMe 9y ago

userbinator 9y ago
All designs should be as simple as possible. You should start with KISS, YAGNI, and Do The Simplest Thing That Could Possibly Work principles. Complexity and patterns should only be introduced when they are needed for practical extensibility. This needs to be at the top, in the introduction. Especially in Java and C#, I've seen far too much "over-patterned" code, in contrast to the opposite.
- TremendousJudge 9y ago
  I think this has a lot to do with how OOP is taught. At uni, on the same semester we were introduced to C++ with classes, OOP, UML, and design patterns. This of course creates in the mind an association between all of these things -- a feel of 'if I'm doing OOP then I should also use these patterns'. The thing is, during the class we understood what the patterns were. However, since the actual programming project was comparatively small we didn't actually understand what a need for following these patters looks like. We didn't see a case where the simple way just didn't cut it, we were simply told to use them because they are good. The effect of this is that, unless someone with experience then comes and mentors you, you will overengineer all of your solutions because you don't know any better. We were taught the patterns but didn't understand the reasons. And I suspect many other engineers have had similar experiences
  - agumonkey 9y ago
    I wrote a bit of C recently, it's impressive how patternless it makes you think. At least not in the OOP way. You may think in patterns, but it's not encoded in source. It's implicit structure. It's also very different because every bit of help you allow in your source is carefully thought out, you want it to fit the fragile land of C and also now you're moving bytes somehow explicitely, you tend to think more about memory and cpu perf.. again less pattern envy. ps: I also forgot to say, even though I'm a fp head these days, imperative C felt fun, that is if you carefully stay into state -> state mindset ;)
    - concede_pluto 9y ago
      Unfortunately this means you wrote several copies of essentially the same code but with minor differences, and if you find and fix a bug in one the others are still wrong.
  - watwut 9y ago
    You need to learn them to be able to read the code that uses them - whether it is used the right way or not. E.g. if you encounter the word 'adapter' or 'decorator', it is easier if you know what it means (and that you should not use those words for things that are not patterns).
    - potbelly83 9y ago
      yep, especially when working on a large established code base, reading code written this way is an important skill set even if you don't write it.
blahman2 9y ago
Thank you! The code and the docs look great!
flavio81 9y ago
"Design patterns implemented in Java" I'd argue that Design Patterns mostly appeared because of Java. Because of people hitting the wall with Java; Java does not allow metaprogramming; Java did not allow class members (it allows instance members); Java does not allow multiple inheritance; Java has a cumbersome and underpowered exception handling system; Java's OOP is really strict and limited; no real functions that can be passed around (not even in Java 8); recursion can't use tail call optimization... etc etc because of ALL this, then developers had to resort to applying the same workarounds. And such workarounds were collected, tagged, and proposed as Design Patterns by the gang of four. But seriously, if the authors write, "All designs should be as simple as possible. You should start with KISS, YAGNI (...)" Then they should be looking at alternatives to Java in the first place. It's 2017 and there are other alternatives that even run in the JVM (if this is a requirement).
- evanspa 9y ago
  Java has always allowed for class members using the "static" keyword. The GoF book predates the public release of Java. The code samples in GoF are in C++ and Smalltalk. Correct me if I'm wrong, but Java 8 does allow functions to be passed around. E.g., if a function takes as input a Runnable, I can pass a no arg lambda expression as input.
  - gozur88 9y ago
    There are actually a bunch of different kinds of functions you can use in lambda expressions in Java 8 (43, to be exact). https://www.tutorialspoint.com/java8/java8_functional_interfaces.htm https://www.tutorialspoint.com/java8/java8_functional_interf... Beyond that, by at least 1.4 you could pass methods using the reflections API, though that was kludgy in a lot of ways.
- TremendousJudge 9y ago
  You realize that Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 while Java 1.0 was published in 1996 right?
- jasode 9y ago
kenoyer130 9y ago
I would also mention "Emergent Design" along with KISS and YAGNI. Do not start your code base with a collection of design patterns. This is the usual cause of a complete over designed mess. Instead as the code grows look for the patterns to emerge and then apply them.
cjnicholls 9y ago
Is anyone aware of a similar C# repository?
- cjnicholls 9y ago
  After a little research i have found a repo with C# examples. https://github.com/abishekaditya/DesignPatterns https://github.com/abishekaditya/DesignPatterns
_pmf_ 9y ago
My take: you do not truly understand modularity until you have had to work with a third party framework where your software is integrated as plugin. Working with Eclipse / PDE / CDT has taught me more about modularity (good and bad) in 2 years than a decade of green field development (plus, I can now write a usable Eclipse plugin faster that I can write the equivalent Vim function ...). I also recommend "Practical API Design" (which contains both large scale advise and tiny but important details regarding source compatibility vs binary compatibility with aspects that have been unknown to me after several years of developing Java) and "Java Application Architecture" (which contains decoupling strategies, but you only learn to appreciate those after you have encountered the generic problem pattern).
coolg54321 9y ago
For PHP, https://github.com/domnikl/DesignPatternsPHP https://github.com/domnikl/DesignPatternsPHP neatly documented with Sphinx

84 points by PleaseHelpMe 9y ago

All designs should be as simple as possible. You should start with KISS, YAGNI, and Do The Simplest Thing That Could Possibly Work principles. Complexity and patterns should only be introduced when they are needed for practical extensibility. This needs to be at the top, in the introduction. Especially in Java and C#, I've seen far too much "over-patterned" code, in contrast to the opposite.

TremendousJudge 9y ago
I think this has a lot to do with how OOP is taught. At uni, on the same semester we were introduced to C++ with classes, OOP, UML, and design patterns. This of course creates in the mind an association between all of these things -- a feel of 'if I'm doing OOP then I should also use these patterns'. The thing is, during the class we understood what the patterns were. However, since the actual programming project was comparatively small we didn't actually understand what a need for following these patters looks like. We didn't see a case where the simple way just didn't cut it, we were simply told to use them because they are good. The effect of this is that, unless someone with experience then comes and mentors you, you will overengineer all of your solutions because you don't know any better. We were taught the patterns but didn't understand the reasons. And I suspect many other engineers have had similar experiences
- agumonkey 9y ago
  I wrote a bit of C recently, it's impressive how patternless it makes you think. At least not in the OOP way. You may think in patterns, but it's not encoded in source. It's implicit structure. It's also very different because every bit of help you allow in your source is carefully thought out, you want it to fit the fragile land of C and also now you're moving bytes somehow explicitely, you tend to think more about memory and cpu perf.. again less pattern envy. ps: I also forgot to say, even though I'm a fp head these days, imperative C felt fun, that is if you carefully stay into state -> state mindset ;)
  - concede_pluto 9y ago
    Unfortunately this means you wrote several copies of essentially the same code but with minor differences, and if you find and fix a bug in one the others are still wrong.
- watwut 9y ago
  You need to learn them to be able to read the code that uses them - whether it is used the right way or not. E.g. if you encounter the word 'adapter' or 'decorator', it is easier if you know what it means (and that you should not use those words for things that are not patterns).
  - potbelly83 9y ago
    yep, especially when working on a large established code base, reading code written this way is an important skill set even if you don't write it.

blahman2 9y ago

Thank you! The code and the docs look great!

flavio81 9y ago

"Design patterns implemented in Java" I'd argue that Design Patterns mostly appeared because of Java. Because of people hitting the wall with Java; Java does not allow metaprogramming; Java did not allow class members (it allows instance members); Java does not allow multiple inheritance; Java has a cumbersome and underpowered exception handling system; Java's OOP is really strict and limited; no real functions that can be passed around (not even in Java 8); recursion can't use tail call optimization... etc etc because of ALL this, then developers had to resort to applying the same workarounds. And such workarounds were collected, tagged, and proposed as Design Patterns by the gang of four. But seriously, if the authors write, "All designs should be as simple as possible. You should start with KISS, YAGNI (...)" Then they should be looking at alternatives to Java in the first place. It's 2017 and there are other alternatives that even run in the JVM (if this is a requirement).

evanspa 9y ago
Java has always allowed for class members using the "static" keyword. The GoF book predates the public release of Java. The code samples in GoF are in C++ and Smalltalk. Correct me if I'm wrong, but Java 8 does allow functions to be passed around. E.g., if a function takes as input a Runnable, I can pass a no arg lambda expression as input.
- gozur88 9y ago
  There are actually a bunch of different kinds of functions you can use in lambda expressions in Java 8 (43, to be exact). https://www.tutorialspoint.com/java8/java8_functional_interfaces.htm https://www.tutorialspoint.com/java8/java8_functional_interf... Beyond that, by at least 1.4 you could pass methods using the reflections API, though that was kludgy in a lot of ways.
TremendousJudge 9y ago
You realize that Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 while Java 1.0 was published in 1996 right?
jasode 9y ago

kenoyer130 9y ago

I would also mention "Emergent Design" along with KISS and YAGNI. Do not start your code base with a collection of design patterns. This is the usual cause of a complete over designed mess. Instead as the code grows look for the patterns to emerge and then apply them.

cjnicholls 9y ago

Is anyone aware of a similar C# repository?

cjnicholls 9y ago
After a little research i have found a repo with C# examples. https://github.com/abishekaditya/DesignPatterns https://github.com/abishekaditya/DesignPatterns

_pmf_ 9y ago

My take: you do not truly understand modularity until you have had to work with a third party framework where your software is integrated as plugin. Working with Eclipse / PDE / CDT has taught me more about modularity (good and bad) in 2 years than a decade of green field development (plus, I can now write a usable Eclipse plugin faster that I can write the equivalent Vim function ...). I also recommend "Practical API Design" (which contains both large scale advise and tiny but important details regarding source compatibility vs binary compatibility with aspects that have been unknown to me after several years of developing Java) and "Java Application Architecture" (which contains decoupling strategies, but you only learn to appreciate those after you have encountered the generic problem pattern).

coolg54321 9y ago

For PHP, https://github.com/domnikl/DesignPatternsPHP https://github.com/domnikl/DesignPatternsPHP neatly documented with Sphinx