What I Learned This Week (Week 48/2013)

Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.

First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.

Second, I want to share my findings with you. I hope that you can use some of them in your daily work.

Let’s get started and find out what I learned in week 48.

What I Learned in Week 48

First, Small can be beautiful too.

I am Spring guy. That shouldn’t be a surprise to anyone. However, it doesn’t mean that I would think that alternative methods for writing software with Java would be bad. I just happen to like Spring Framework.

This week I read a blog post titled Humble Architects by Johannes Brodwall, and it made me think about complexity. This blog post makes several good points but this section caught my eye:

Every technology comes with a cost. Many technologies come with an infinitesimal benefit.

Here’s a list of technologies that I’ve experienced as having consistently higher cost than benefits, and thus will never use (if you don’t know them, don’t worry. The point is the number): JavaServer Pages, Java Server Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS (all implementations), JBoss.

Here’s a list of technologies that I happily use: JUnit, Jetty, Joda-time, Java Standard Edition.

When I saw this section for the first time, I wondered how he could be productive without using a framework. Then I remembered that when I started writing software with Java programming language, I had to do the same thing because there were no frameworks.

So I wrote web applications by writing servlets, and I was productive. One thing that I remember about those times was that we ended writing our own "libraries" which helped us to write less verbose code. Typically these libraries dealt with request parameters, managed dependencies, and so on. In other words, we were writing our own frameworks.

The problem was that many of those framework were clumsy and inelegant. This might have been caused by our lack of experience but this feeling was one of major reasons why I was extremely happy when the first web frameworks were published.

I was even more happier when the first dependency injection containers were released because they freed me from dealing with the dependencies of my application. I could finally get rid of those factories which constructed my components. It felt like a huge leap forward.

This week I learned that small can be beautiful too. If using a framework makes sense to us, we should use it. However, we should remember that often we choose to use a familiar framework for every problem we face. The next time when have to make this decision, we should ask ourselves this question:

Do I really need all this stuff?

Will you ask this question? I know that I will.

Second, Aim for immutability.

This week I ran into the slides of the presentation (Immutable Java) which Tero Parviainen gave at Java Day Riga 2013.

When I was scanning through the slides I became annoyed. I was annoyed because of one simple reason:

I was feeling guilty because I knew that I could do a better job for ensuring that my classes are immutable.

After I realized this, I knew that I have to do something about it. Although I doubt that it is impossible/impractical to make all objects immutable (mainly because of Hibernate), I decided to start following these rules:

  • Use immutable types for dates (Actually I am already doing this because I use Joda-Time).
  • Declare field as final when its value cannot be changed after it has been set for the first time.
  • Ensure that the information of entities cannot be changed outside the entity class.
  • Make your value objects immutable.
  • Make all read-only classes immutable. This includes DTOs.

This seem like a pretty comprehensive set of rules, and I feel confident that if I follow these rules, I can improve my code. What do you think?

Third, Use custom types instead of basic types (but don’t overdo it).

I have spent a lot of time thinking about custom types, and it has been really really hard to find an answer for this question:

When can I justify the complexity of using a custom type instead of a basic type?

I know that using a custom type adds a semantic meaning to the my code. This is something I cannot achieve with using just basic types like Strings. However, most of these custom types would be only thin wrapper classes, and using them seems to add extra complexity to my code.

There is one exception though:

When I want to group more than one properties together, it is clear that I should use a custom type. E.g. It makes no sense to add streetAddress, city, and zipCode fields into every class that has an address. Instead I will create an Address class which has streetAddress, city, and zipCode fields, and add it to every class which has an an address.

What should I do with single fields then?

This week I read a blog post titled Never, never, never use String in Java (or at least less often :-), and I think that I found an answer to that question.

If a value has a semantic meaning which is important to the domain-specific language of the application and (or) you want to ensure that only valid inputs are accepted, you should consider using a custom type.

I am not entirely happy with this rule but it is a good start. What do you think about it?

Fourth, Name "things" by using domain-specific language.

I think (hope) that every developer understands that giving descriptive names to methods, variables, and classes is important because it makes the code readable. I think this way too.

And yet, sometimes I forget it.

This week I ran into to the following controller method which was written by yours truly:
[cc lang="java" tabSize="2" height="*" width="*"] public String submitRegistrationForm(RegistrationDTO dto) {
//Add implementation here.
[/cc] This method has three following problems:

  1. Although it is called when the registration form is submitted, its name doesn't describe what happens when it is invoked.
  2. The name of the form object class isn't very good. It is clear that is a data transfer object, and yet I have chosen to add the suffix DTO to its name. This doesn't help us to understand what kind of information it contains.
  3. The name of the method parameter doesn't describe its purpose.

I believe that we should name things by using domain-specific language. In this case it means that we should use terms which are related to a registration process. When we follow this rule, we end up with the following method:

[cc lang="java" tabSize="2" height="*" width="*"] public String registerNewUserAccount(RegistrationForm newUserAccount) {
//Add implementation here.
[/cc] The second method looks a lot better and it fixes all the problems found from the original method. This might seem like nitpicking but things like this make large codebase much more understandable.

The best part about this is that it doesn't require a lot of work because all modern IDEs have great refactoring capabilities.


Fifth, Annoyment can be a powerful ally if you know how to deal with it.

If you get annoyed when you are reading a technical blog post or watching a presentation, you have two ways of dealing with this:

  1. You can ignore the blog post or presentation and think that this person is an idiot who doesn't know what he is talking about. You might even make a witty remark and try to signal to this person that you are better than him.
  2. You can figure out why you are annoyed and try to to learn something from it.

It is quite easy to choose the first (and very unproductive) option. However, if you take the time to search your feelings, you might notice that the reason why you are feeling annoyed is not that this person is an idiot.

It might be something much more personal.

Are you sure that you aren't feeling annoyed because you know that this person makes a valid point?

Are you sure that you don't like his point because it forces you out of your comfort zone?

I have noticed that every time when I have felt annoyed, I have learned something from it. It is a wonderful feeling!

Are you sure that you don't want to feel this way too?

What Did You Learn This Week?

Share your learning experiences or other comments on the comment section.

4 comments… add one
  • Anssi Kuutti Dec 9, 2013 @ 22:57

    Good stuff as always Petri! Although I'd argue the instance of the registration form still isn't correctly named. Think about the code:


    Intuitively you would assume this code gets the first name of newly created user account, but to my understanding the user account isn't created yet necessarily? I think the registration form instance could be named: registrationForm or registrationFormData. What do you think?

    • Petri Dec 10, 2013 @ 0:03


      I was actually pretty happy with that name until you mentioned that it might be possible to mix the RegistrationForm object up with the created user account. It hurts but I have to agree with you. The name of that method parameter is not very good.

      The reason why I didn't originally use the name registrationForm was that I thought that the name of the class would be enough to reveal its purpose. Although this might work in the method signature, it probably isn't good enough when we think about the big picture.

      Thus, I would probably rename that method parameter to registrationForm and give the name newUserAccount to the created domain object.

      Any other opinions about this?

  • Ranga Reddy Mar 17, 2014 @ 8:37


    Can you post some best practices while writing Spring, Hibernate and Core Java.

    • Petri Mar 17, 2014 @ 15:42


      Sure. I added a new card to my Trello board so that I don't forget this (I cannot give an exact deadline for this blog post).

Leave a Reply