Question

I find my self writing again and again the same programming patterns in many new projects. I have been thinking about creating my own reusable library of typical implementations of such patterns -not trying to cover all possible design patterns, but only them that experience has shown that it makes sense to put such typical implementations in a library (e.g., adapter, factory, etc ...)- but before I would like to know if there is not an existing library for this purpose already available for Java?.

I know that it is very difficult to completely generalize programming patterns in a way that they could be reused across different implementations with complex requirements (e.g., composition of patterns, classes participating in more than one pattern, etc ...). However, most of the time the pattern instantiations I need are quite simple and standard, and in many situations the implementation work could be sped up a bit with the use of such a library.

Thanks for your feedback.!

Was it helpful?

Solution

This is precisely the reason why I created PerfectJPattern. Just make sure to check out and understand the code examples. They are available for download as well as in the site documentation pages for each of the Pattern implementations. If you read the GoF book, then you will understand the examples more easily.

For instance, if you want to use the Composite Pattern in your code, and if you use PerfectJPattern you only need to specify which interface (generic parameter and class instance) you would like to use as Composite and the rest is provided to you, see PerfectJPattern Composite. At the bottom of that page, a working example is provided that shows how to accomplish that.

Another aspect you should also take into account, is that in PerfectJPattern you do not necessarily need to reuse the generic Pattern implementations (e.g. perfectjpattern-core Maven submodule), you also do have the choice to only reuse the pure abstract level (perfectjpattern-api Maven submodule) and provide the implementation yourself. In PerfectJPattern you have the flexibility of reuse at different levels of abstraction since there is a fine-grained layered design reflected also in the Maven project structure. Reusing the perfectjpattern-api gives you an abstract template guideline if you wish, that will help you speed up your own Design Pattern implementations. However, ideally you should reuse as much as possible.

Update: following up on a comment below, it is worth noting that not all Patterns can be fully compotentized see From Patterns to Components. Some Patterns can be only partially componentized and some others not at all like the case of the Singleton. The Singleton depends too much on the context and that's why you can only find an interface in PerfectJPattern. However in PerfectJPattern the following Patterns are fully componentized e.g. Observer, Command, Adapter, Decorator, Composite, Proxy, Visitor, DAO, etc.

OTHER TIPS

Design pattern are just... patterns. They aren't classes ready to use for anyone, but common concepts found across several projects. That's why you won't find a Design Pattern API.

I disagree with the other answers that no reuseable implementations can be created for design patterns. However, it might not always be straightforward, and involves a lot of abstract programming.

Coming from C# I was missing the simplicity of the observer pattern in Java. (events in C#) After finishing a reusable generic observer for Java I came across the PerfectJPattern library.

It might be worthwhile to check it out.

A componentized pattern is in essence a context-independent, reusable and type-safe variation of the original pattern that covers at least as many use-cases as the original pattern and that does not require developers to re-implement the same boilerplate code in every different context. Design Patterns are reusable in terms of design, componentized patterns are reusable in terms of design and code.

Kudos for wanting to reduce any form of duplication possible. "Don't repeat yourself" is one of the most important principles in programming.


As some extra arguments design patterns can be centralized in a library I give you some further examples:

What you are looking for is PerfectJPattern.

Checkout dp4j. It allows you to implement the Singleton pattern with @Singleton and lazy initialize it with @Singleton(lazy=true). It is a "collection of reusable componentized Design Patterns implemented in Java".

For the Singleton recommend dp4j. To implement a Singleton you annotate your class with @Singleton and to lazy initialize it you annotate with @Singleton(lazy=true).

If you find yourself repeating similar code in multiple projects, it might be a good idea to extract the portions that are repeated into a library of reusable code in hopes of avoiding repeating yourself in the future.

This is unlikely to lead to fully general reusable implementations of design patterns.

A lot of the patterns are built into the Java SE - you may not notice.

Decorator is all over the java.io package.

The java.sql package is AbstractFactory.

All the wrapper classes are Flyweights.

I stand with those who say don't look for a pattern library. They should be discovered as you write your code.

It is possible in a languange which offers higher order functions and some other stuff. Here are some slides which references a paper which discusses 'the origami pattern' library. It shows 'library code' for the following patterns: Composite, Iterator, Visitor, Builder. So if you want to try that out on the jvm you can today, just use scala. http://www.slideshare.net/remeniuk/algebraic-data-types-and-origami-patterns

Do you see a forest or trees?

Design patterns should become apparent rather than be selected up front. By the time they become apparent, you don't need the pattern because the code exists. Then you marvel at how the solution solved itself and your brain subconciously selected the right approach. It gives you that warm fuzzy "i trust that code" feeling.

If you build a design pattern library, you have built yourself a big hammer (or hammer factory, or hammer factory factory [1]) and everything becomes a convenient nail (including screws) resulting in lots of sore thumbs and bowls of spaghetti in your development team.

[1] http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top