How NOT to use Spring for modularization

Posted in architektura, java, programowanie on May 10th, 2016 by Wojciech Soczy艅ski – Be the first to comment

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




My coding decalogue

Posted in java, og贸lne, programowanie on October 23rd, 2013 by Wojciech Soczy艅ski – 1 Comment
  1. You will not use inheritance, unless forced to
  2. Your methods will be not longer that 20 lines of code
  3. Your classes will be not longer as 200 lines of code
  4. You will not use private methods
  5. You will not use getters nor setters
  6. Everything will be immutable by default
  7. You will create an interface only when you create a point of extension or if you have already two classes that will implement it
  8. Object oriented style will be using for the API’s and will be as much domain specific as possible
  9. Functional style will be used inside the API’s and will be as much general as possible
  10. Composition !

Questions ?

Book review – Getting started with Google Guava

Posted in java on October 23rd, 2013 by Wojciech Soczy艅ski – 1 Comment

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 ?

  1. The book is concise and a light read – it took me maybe about 2h to read it
  2. It covers a big part of the library
  3. Personally I’ve learned about some things that I didn’t knew 馃槈
  4. 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] Guava goodness – loading a file from a directory hierarchy

Posted in java on March 25th, 2013 by Wojciech Soczy艅ski – 2 Comments

The case:

  1. we want to have an ability to override some static resources in the application
  2. we can have multiple overrides
  3. there is a hierarchy which decides which file is selected if we have multiple overrides
  4. the hierarchy is fixed from the most important to the less important directories

The code:

The other code 馃槈 :

Joy :)

[Google Guava] – One class to rule’em all – FluentIterable

Posted in java, programowanie on March 16th, 2013 by Wojciech Soczy艅ski – 2 Comments

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 (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 (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

The test:

Could not embed GitHub Gist 5178445: API rate limit exceeded for (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.