7

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

SkyWalker
  • 13,729
  • 18
  • 91
  • 187
Sergio
  • 8,532
  • 11
  • 52
  • 94
  • 5
    A singleton frame won't be the same as a singleton connection. But they're both singletons. A decorator for a stream won't be the same as a decorator for a collection. But they're both decorators. Patterns are not something that you can put in a library and reuse for all the applications. – JB Nizet Nov 06 '11 at 22:01
  • I agree completely with you in the first two lines of your comment, @JBNizet. However, I think there are many other situations in which -for certain patterns- having an extensible library for typical instantiations could make sense (e.g., Adapter, Factory). – Sergio Nov 06 '11 at 22:07
  • 2
    Here's the way I see it: generics (almost certainly mandatory for implementing this) have been around for what, seven years? The reason there isn't a general implementation of a design pattern library is because it doesn't make sense to have one. – Dave Newton Nov 06 '11 at 22:14
  • Be careful not to go pattern crazy either... just because you can build/refactor something to use a pattern doesn't mean it's a good design choice for your particular need. Sometimes simpler is better (saves time, code is easier to understand). – Bryan Nov 06 '11 at 22:35
  • 1
    Good observation @Bryan. I am thinking more in the case when using patterns seems to be a natural choice. – Sergio Nov 06 '11 at 22:38
  • @JBNizet: To give you an example, it doesn't matter what is lazily initialized, [it just is](http://msdn.microsoft.com/en-us/library/dd642331.aspx). – Steven Jeuris Nov 06 '11 at 23:42

9 Answers9

4

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.

Emmanuel Bourg
  • 9,601
  • 3
  • 48
  • 76
  • 1
    Agreed. But very often many instantiations of such common concepts are repetitive, and a bit of infrastructure for implementing such typical cases could be useful. – Sergio Nov 06 '11 at 22:16
  • @Sergio Perhaps what you really need are something along the lines of code templates that can act as examples, and be used for simple situations where you need to implement a pattern. – Bryan Nov 06 '11 at 22:40
  • @Sergio True, that why you have classes like java.beans.PropertyChangeSupport in the JDK to implement easily a property change notification mechanism, but that remains specific to a domain. – Emmanuel Bourg Nov 06 '11 at 22:43
  • -1 I don't use Java often and was able to find [PerfectJPattern](http://perfectjpattern.sourceforge.net/index.html). I can only imagine that's not the only library available. Design patterns imply doing the same thing over and over again. Through proper use of generics and some more advanced language features you can go a long way in minimizing the boilerplate code you have to write. – Steven Jeuris Nov 06 '11 at 22:45
3

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.

SkyWalker
  • 13,729
  • 18
  • 91
  • 187
1

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:

Steven Jeuris
  • 18,274
  • 9
  • 70
  • 161
  • Look at the ISingleton and IStrategy interfaces of this API, they are just empty... The implementations are just for specific domains, it's not a one size fits all API. – Emmanuel Bourg Nov 06 '11 at 22:54
  • @EmmanuelBourg: I didn't get a chance to try out the library yet. But they specifically state it is supposed to be reusable (context-independent). Given that a no-Java expert like me is able to create a reusable generic observer makes me believe there is more behind the library than empty interfaces. – Steven Jeuris Nov 06 '11 at 23:08
  • The fact that it seems to be based on work from [Bertrand Meyer](http://en.wikipedia.org/wiki/Bertrand_Meyer) is also a strong indicator. – Steven Jeuris Nov 06 '11 at 23:16
  • It's reusable but does it actually fit everyones need? Does it perform asynchronous notifications? vetoable notifications? notification on a UI Thread? The field of use of a pattern is much broader than the use cases you can capture in a reasonably sized API. – Emmanuel Bourg Nov 06 '11 at 23:18
  • @EmmanuelBourg: Only one way to find out. ;p Unfortunately I didn't get to that yet as I didn't have any Java projects since then. (lucky me) – Steven Jeuris Nov 06 '11 at 23:19
  • @EmmanuelBourg perfectjpattern-api contains only interfaces, but perfectjpattern-core contains implementations. It is up to you to reuse the implementations or do your own on top of the interfaces ... maybe you have a very special use case. Additionally, not all patterns are componentizable until there is a language feature that would allow it ... e.g. Singleton, though IoC tackles this issue very nicely and marking your instances with ISingleton could be convenient in some cases. – SkyWalker Oct 10 '16 at 18:32
1

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

simpatico
  • 10,709
  • 20
  • 81
  • 126
  • Given the [skeptical response on my answer](http://stackoverflow.com/questions/8030665/class-library-for-design-patterns-in-java/8030954#8030954), I'm wondering whether you have used this library and found it useful. – Steven Jeuris Nov 14 '11 at 08:18
  • I've not used PerfectJPattern (yet) but I do use dp4j. – simpatico Nov 14 '11 at 17:57
0

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.

Don Roby
  • 40,677
  • 6
  • 91
  • 113
  • In fact this question originated exactly like that: I found my self repeating similar code and start factoring this in a library. Then I realized that certain classes in this library had names such as: Adapter, Factory, etc... and that triggered the question. – Sergio Nov 06 '11 at 22:44
0

JT Design Pattern Framework for Java/j2EE

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
0

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.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Hi @duffymo, Sometimes when you sketch a solution in your mind, a ring bells and you realize you have been there already, and the easiest and faster thing to do is just to solve the problem as something similar you did on the past. Sometimes this similarity consists on a complex piece of code, other times it is a simple programming pattern, in both situations it seems to me that having a bit of reusable code can make sense. As I mentioned in the question, I do not think that is possible to do with any programming pattern, but with few of them that could be useful. – Sergio Nov 07 '11 at 08:54
  • Nah, I prefer knowing that patterns and doing the code on the fly. – duffymo Nov 07 '11 at 17:26
0

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

AndreasScheinert
  • 1,918
  • 12
  • 18
-1

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

Deleted
  • 4,804
  • 1
  • 22
  • 17
  • That argument hardly holds for all design patterns. – Steven Jeuris Nov 06 '11 at 22:52
  • 1
    @StevenJeuris: over the last 20 years of writing C++, then Java then C#, I feel that it does. There is a place for it that we never need to delve into however: inside the base class library (BCL,RT,STL) of your platform that is. – Deleted Nov 06 '11 at 22:54
  • So you are saying, it is OK for design patterns to be implemented in base frameworks (e.g. events in C#), but it is not OK to create them yourself? – Steven Jeuris Nov 06 '11 at 22:59
  • @StevenJeuris: Let me clarify: it's ok to create them yourself in the due process of building something as part of the implementation, but it is not acceptable to start with a genericised library of patterns. The framework guys (at least with C++, Java and sort of C#) went through years of peer review before they committed to code. None of us should do that, unless we're building space shuttles or something. Therefore there is no reason to "library-ify" them. Just apply ad-hoc. It's expensive, unnecessary and will give you a legacy of shooting yourself in the foot. – Deleted Nov 06 '11 at 23:04
  • Agreed, but that doesn't mean it is not possible right? That is why he was asking for an existing library. I was [sick and tired of Java's default approach of the observer pattern](http://stackoverflow.com/questions/8030665/class-library-for-design-patterns-in-java/8030954#8030954), which is why I spent time in doing it properly. I didn't have to create an entire patterns library for that. – Steven Jeuris Nov 06 '11 at 23:12
  • @StevenJeuris: everything is possible, but is it right or an effective use of your time? WRT the Java observer pattern; it's rather good. In fact I find I rather like the simplicity and the fact that it's not baked into the compiler implementation in C#. – Deleted Nov 06 '11 at 23:21