Design patterns implemented in Java

<i>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.</i><p>This needs to be at the top, in the introduction. Especially in Java and C#, I&#x27;ve seen far too much &quot;over-patterned&quot; code, in contrast to the opposite.

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 &#x2F; PDE &#x2F; 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 &quot;Practical API Design&quot; (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 &quot;Java Application Architecture&quot; (which contains decoupling strategies, but you only learn to appreciate those after you have encountered the generic problem pattern).

Is anyone aware of a similar C# repository?

I would also mention &quot;Emergent Design&quot; 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.

For PHP, <a href="https:&#x2F;&#x2F;github.com&#x2F;domnikl&#x2F;DesignPatternsPHP" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;domnikl&#x2F;DesignPatternsPHP</a> neatly documented with Sphinx

Thank you! The code and the docs look great!

&quot;Design patterns implemented in Java&quot;<p>I&#x27;d argue that Design Patterns mostly appeared <i>because of</i> 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&#x27;s OOP is really strict and limited; no real functions that can be passed around (not even in Java 8); recursion can&#x27;t use tail call optimization... etc etc<p>because of ALL this, then developers had to resort to applying the same workarounds. And such workarounds were collected, tagged, and proposed as<p><pre><code> Design Patterns </code></pre> by the gang of four.<p>But seriously, if the authors write,<p><i>&quot;All designs should be as simple as possible. You should start with KISS, YAGNI (...)&quot;</i><p>Then they should be looking at alternatives to Java in the first place. It&#x27;s 2017 and there are other alternatives that even run in the JVM (if this is a requirement).