One of the anti-patterns that I encounter quite recently in the “enterprise” Java world is a one that I call the “Spring context template”. The motivation behind it is to enable code reuse and modularization. Unfortunately most of the time it creates more problems that it solves.
How does this pattern emerge ?
there is some code that has a potential for reuse – e.g. common boilerplate for a server
the wiring for that code is done via Spring XML context
to allow reuse, the code is extracted along with the Spring XML context into a separate module/library
there are extension points left in the XML context to supply your own implementation for some beans
in order to use that module/library you have to import it’s main context XML and declare beans with expected id’s
What are the problems with the approach above:
namespace pollution – hard to guess if any of our application beans clash with the ones declared by the lib
no easy way to identify all extension points
usually the lib has a few context XML files that may depend on each other, it makes it harder to replace a part of the default implementation
these kinds of libs tend to be stacked one after another which makes the whole thing even more complex
Usually the problems with that kind of design are easily solved by a proper use of encapsulation:
a library might be morphed into a service/microservice
we might use the builder or factory pattern to hide implementation details and provide well documented extension points
Posted in java on October 23rd, 2013 by Wojciech Soczyński – 4 Comments
As a big fan of the Google Guava library, I was very happy when I’ve got a chance to review this new book from Packt Publishing – “Getting started with Google Guava“. The book has 120 pages of content and is available in several formats from the major internet book stores.
The book covers a lot of a quite big library which Google Guava is. From the basics like Function, Collections and Files to more advanced topics like Concurrency and the Event bus.
The book is of the series “Community experience distilled”. The series name is a good description of the book content. The content is very distilled. Each feature of Guava is explained in a “keyword, short description, example, summary” fashion. This is by no means a weakness of the book – if you have the right attitude. If you are looking for a quick run over the library main features along with code examples, and you want to just scratch the surface, this book is for you. But if you require some more in depth description you will be possibly disappointed.
Personally for me, the book would be a lot better if it could introduce some more context in each chapter describing a part of the library. Speaking of the context I mean i.e in the part about functional programming – what is functional programming, what are the benefits of using it etc. It would be more beneficial for the (assumed) target of the book – novice programmers who want to get some good understanding of Guava. Also the book misses a chapter on good practices – what kind of patterns to avoid,what is especially important in scope of the Collections being the most used part of the library.
While reading the book, the most irritating part of the experience was looking at the example code. In my opinion the samples in the book were just to big and maybe to detailed, often they would span through pages, which doesn’t help when reading.
Enough complaining, what are the good parts ?
The book is concise and a light read – it took me maybe about 2h to read it
It covers a big part of the library
Personally I’ve learned about some things that I didn’t knew 😉
The full code can be used as a copy-paste resource for experimenting with different solutions
Summary – a seasoned developer will be disappointed but the book could be useful for novices.
Google Guava has a lot of interesting utility classes, just to name a few: Optional, Joiner, Splitter, EventBus, Collections2 etc. But the essence of the whole library is condensed in just one single class – FluentIterable.
The FluentIterable class let’s you combine a set of operations on a collection in a single pipeline, plus it has some nifty methods too :).
To start a pipeline, you should use the simple FluentIterable.from(collection) method:
Then you can perform typical collection operations. For the purpose of the example, let assume that we want to square all even numbers from 1 to 100 and select from the result the first number that is greater than 17 and smaller than 50.
Note that for a range comparison I have used the Guava Range class which is a cool utility for dealing with ranges. One can also replace the “generateInput” method with a combination of a ContiguousSet and Range invocations:
The last but not the least interesting method in the FluentIterable is the transformAndConcat method. It allows to perform a transformation of a collection of some objects and merge the outputs, assuming that the result of a single item transformation was also a collection. This is very handy for situations like making a flat structure from some kind of Tree or a nested List. A common example is a list of files in a tree structure of the file system.
Note in the above example, that I have used an “identity function”. The identity function is a function that simply returns its input.
We are near the end, so for the close up I would like to tell a few words about performance. I have done some tests using the Google Caliper benchmarking library. The case was about squaring every item of a collection which was an even number. I have made two implementations:
…a vanilla Java one:
Could not embed GitHub Gist 5178414: API rate limit exceeded for 126.96.36.199. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
… and a Guava based one:
Could not embed GitHub Gist 5178440: API rate limit exceeded for 188.8.131.52. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
Could not embed GitHub Gist 5178445: API rate limit exceeded for 184.108.40.206. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
The test was run 10 times (10 reps) for 20 trials. On the average the Guava solution took about 1,5x time of the Java one.
All in all I think that the performance penalty is not very big and it is beneficial to use the FluentIterable class for the sake of coding pleasure, readability and testability.