I thought it would be a fun to write a series of blog posts looking at different design patterns in Java. So the first thing I did was go to the In...
For further actions, you may consider blocking this person and/or reporting abuse
I don't think the number of patterns has anything to do with Java (if it's not generalisable beyond Java I have to question if it's really a pattern). I think it has more to do with some people's proclivity to formalise the most trivial of things.
If you are going to go through all the patterns, you should double check that they really are patterns and also try and gauge how useful they really are.
...yeah that sounds like me
100 is too many we don't need to name every solution to a problem (pattern). Some of them are language fault but some of them are peoples fault.
Example Service layer pattern from my experience produced a lot of anaemic domain models as people used domain models as data models and did everything regarding business logic inside of a service. It was much easier in most of cases just to use controller -> repository -> domain do some logic -> return to controller -> client. It would be less code and easier to debug.
We need less patterns and more developers thinking about what do we actually need and stop cloning project architectures just because you are used to it. This mainly goes to employers, tech leads, and seniors.
Why do I need to use transformers and such in cases where DTOs will only be copy/paste some fields and ignore others. Maybe sometimes converting numbers to string. Isn't it easier to make DTO constructor that accepts object of some type and extract fields into DTO?
I saw Unit Of Work pattern while working with .NET Core. I never wanted to implement it nor did I need. Created simple repositories (in this case called by many anti-pattern) and used methods to fetch data to avoid wirtting same LINQ many times. Why would I write Unit Of Work? Just because someone wrote a blog about it and now all listed stuff must apply to me?
Hope you see the point I'm trying to make here.
Amen
I didn't see Model-View-ViewModel on your list which I wrote an article about back in 2011. The link to the Java code isn’t working in that article here is the code on GitHub. The readme has a broken link to the accompanying paper that IBM published that compares MVC, MVP, and MVVM in Java. Here is the PDF version.
Another one I didn't see is ”aggregate root” which is the key pattern in domain driven design. I coded that up in Java on GitHub and wrote a five part epic blog about it linked to from the readme.
I recently watched an interesting video which basically convincingly argues that “input-output plug-ins” to pure business logic is the key to clean architecture. Warning: the video spends the first 10 minutes talking about human evolution which seems utterly random but trust me watching the full video is well worth it.
I am not sure what the official name of the pattern in that video is. A quick google of ”plugin pattern” seems to be something on a smaller scale that is also not on your list.
Also I don’t see the “transaction script” pattern which is identified as the default old school EJB stateless session bean pattern. The timeless classic book “Pojos In Action” by Chris Richardson describes it and why it is problematic. That book presents code in Java to implement domain driven design and the ideas in the timeless classic Eric Evans book. I don’t think you can buy an electronic version of Eric Evan’s masterpiece “domain driven design: tackling the complexity in the heart of software” but it is worth getting hold of a copy.
I would be wary of taking a “more is better” view of patterns.
If you are using a certain deployment architecture and technology stack I would recommended trying to find a minimal set of patterns and frameworks that are sympathetic to your choices.
Things change over time so it is a moving target. Patterns can become anti-patterns when new approaches supersede them. By way of example when I started out I was told that the Core J2EE Patterns were what I should use. Today I know that modern software shouldn’t be written that way.
Devs should learn the patterns that are idiomatic to their stack and architectures. It is a good idea to be on the constant lookout for upgrades that replace the need for an given set of patterns with something more productive.
Only a few of these patterns can be considered as "Java" patterns, specifically the J2EE ones (download.oracle.com/otn_hosted_doc...). The rest is a mixture of Gof patterns (based on Smalltalk I believe), Enterprise integration, SOLID etc. that are language agnostic. Maybe you meant Object Oriented design patterns?
Looking at your list, there are some patterns there that could be combined with other patterns. Strategy and command are fairly similar, as are the factory and builder patterns.
If you do end up writing these posts (and I really hope you do!) I'd love to see examples of the patterns used in the wild. 😀
Every design pattern is supposed to solve a particular kind of problem. So unless the list contains duplicates, I don't think it is too much.
On the other hand, 100 patterns are maybe too much to keep in mind. Further, for each pattern you have to spend time to understand it. Maybe also to memorize and practice.
It don't think that the high number of design pattern implemented with Java has something to do with the expressiveness of its syntax. Rather the business domains in which it is being used.
Some people claim that Kotlin solves a number of problems of the Java syntax. Still the underlying patterns are present, just with a more elegant syntax.
On the other hand a certain set of pattern depends on particular languages feature. E.g. the Converter pattern makes only sense if you have a type system. So while there is probably a subset, I'd expect a different set of commonly used pattern for other programming languages, say JavaScript or Erlang.
Only if people apply design pattern indiscriminately. Also one person's design pattern may be another person's anti-pattern. So I guess this question can't be answered.
Hi Andrew,
I just bumped into this article and registered here. I like the idea about a series on design patterns. Not sure how things work here, but I'm hooked on feature flags right now and would love to help with that part. Let me know if you are open for a chat. ;)
Great Collection.
I would love to see blogs around Domain Driven Design, Event Sourcing, CQRS with Examples.
A list of DOs and DON'Ts as well.
I can get my head around this topic. Too Subjective and Less examples
Very interesting! I might have to check out that book...
Constructor method != Builder method