
Design patterns implemented in Java - PleaseHelpMe
https://github.com/iluwatar/java-design-patterns
======
userbinator
_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
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
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
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.

------
_pmf_
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).

------
cjnicholls
Is anyone aware of a similar C# repository?

~~~
cjnicholls
After a little research i have found a repo with C# examples.
[https://github.com/abishekaditya/DesignPatterns](https://github.com/abishekaditya/DesignPatterns)

------
kenoyer130
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.

------
coolg54321
For PHP,
[https://github.com/domnikl/DesignPatternsPHP](https://github.com/domnikl/DesignPatternsPHP)
neatly documented with Sphinx

------
blahman2
Thank you! The code and the docs look great!

------
flavio81
"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).

~~~
ivan_gammel
Tail call optimization is a way for compiler to align functional recursive
algorithm with stack-based procedural reality. Since Java is not a functional
language and has sufficient expressive power to write iterations as...
iterations, good programmer will just write a for loop and will not bother
about a feature that is basically unnecessary in multi-paradigm language. Oh,
by the way, recursion is a functional design pattern, isn't it?

~~~
flavio81
> Since Java is not a functional language and has sufficient expressive power
> to write iterations as... iterations, good programmer will just write a for
> loop and will not bother about a feature that is basically unnecessary in
> multi-paradigm language.

Ok, so you think recursion is unnecessary _in a multi-paradigm language_.

Which implies also that multi-paradigm languages shouldn't be really multi-
paradigm languages... Java, by the way, is hardly a multi-paradigm language.

And you imply that the reason one uses recursion is because one can't "write
iterations as ... iterations".

You should realize that recursion is used whenever expressing the problem in a
recursive way would make the problem easier to program and/or clearer to
express, etc. Not because of recursion being fancy or fashionable.

Recursion is a computer science technique, not a "Design Pattern".

