Effective Java is  book in the Effective series, started by Scott Meyers with the excellent book Effective C++. The general format of the series is to present topics of high importance for intermediate to advanced users. The goal is not to teach the mechanics of the language, but the fine topics that make the difference between medi0cre users of language and advanced programmers.

Effective Java was written by Josh Bloch, one of the members of the group that defined the Java libraries. Therefore, Effective Java is a book that provides lessons based on the deep experience of the author with the design of core Java libraries. In particular, it is nice to hear from him what he thinks is wrong with some of the Java libraries, so that you don’t need to repeat the same mistakes the Java creators made.

Focus on Immutable Objects

One of the best topics of the book, and one that I advocate myself through the years, is that of trying to make objects immutable as much as possible. The idea is that objects should be in states that are well defined, and therefore the smaller the number of states, the easier it is to understand what the code is doing. Examples of using the pattern of immutable objects in Java is the String class: after construction, String objects are immutable, and any operation will create a new String that is returned as a result.

Traditional programming techniques use variables as a free-for-all, where state changes as much as needed. But once you learn functional programming, you will start to realize that values don’t need to change for your program to do something useful, and the less they change, the easier it is to figure out what is going on. In fact, in functional programming you just need to apply functions and check the results of the application — nothing else.

Of course, imperative languages such as Java still need variables on loops, but even this is not so important nowadays that we have foreach loops in all major languages other than C++.

Improvements in the 2nd edition

Many topics changed from the 1st edition of Effective Java, but the most important change was in the coverage of generics. The implementation of generics in Java is interesting and surprising, because of their use of the type erasure. That is, parametrized types in Java exist only as viewed by the compiler, and the information is erased from the resulting class files. This makes the resulting code compatible with previous JVMs, so the same code works everywhere. However, it has dangerous downsides, which require the full understanding from programmers.
Effective Java provides a deep introduction to the subject of Java generics, and after reading it you will not probably like generics a little less — but will also be more prepared to use it. The pros and cons of using Array objects instead of native arrays are explained. Also, the important concepts of extends and super are in generic types is summarized using the PECS acronym (produces-extends, consumer-super).    

Conclusion

Effective Java 2nd edition delivers what it promises. All the basic points in using Java, from creating objects, to managing resources and using generic types are discussed. Maybe some of these topics could be extended in newer editions, or even in another book. But it provides all the necessary material to transform a beginner into a well educated Java programmer.

When writing a method, one of the first decisions is the signature of the method, that is, its name and the parameters that need to be supplied to the method. The name of a method is an important decision, but let us skip it for a while. Let us just consider the number of parameters in a method.

When we first think about the number of elements in a method, we usually get it right. That is because we think about the functionality of the method and what is most naturally thought of as the arguments for that method.

Reality Check

Things get complicated, however, when we get to write an implementation. Usually, we start  getting tangled on the dependencies of the code that we want to write, and the  easiest way to get out of the situation is adding more parameters to the method. This parameters inflation is bad in most of the cases. For exemple, Robert Martin in  his book Clean Code, suggests that a method should have at most 3 parameters.

For example, suppose you want to write a method to return the add a value to the  elements stored in a list. The natural way to do this would be

class MyClass { 
  // ...
  public double addToEachElement(MyList l, double val){
    // ...
  }
}

Now, suppose however that to get hold of some information stored in the list you need an  index. This data needs to be supplied in some way. The first reflex of someone that has been trained in structured programming is to add a parameter to the method:

public double addToEachElement(
  MyList l, double val, int anIndex){ // ...

This will work in the short term, but there is a big problem with this kind of change:  now there is a difference between what we intuitively think as what the method requires, and the reality that we need to supply an extra parameter just to satisfy the implementation.

A better way to handle this situation is to use OO design techniques to our advantage.  One of the premisses of object oriented techniques is that objects should encapsulate  information that is necessary for its implementation. We just figured out that anIndex  is an implementation detail that has nothing to do with the addToEachElement method. The  conclusion is that anIndex should be a member variable of MyClass, instead of a parameter.

Testing Methods

Another reason why methods should have fewer parameters has to do with testing of code. When creating tests, it is natural that we check combinations of values passed as parameters. However, a large number of parameters represents more combinations — which means that it becomes increasingly difficult to write tests that cover the important scenarios that will be faced by the method.

Reducing the number of parameters in a method

There are a number of options that we can follow to reduce the number of parameters in the methods we design:

• making the parameter a member variable: doing this allows the values to be codified in the state of the object. It is probably one of the first approaches you can try.
• grouping parameters into a new object: if you notice that certain parameters always go together, this suggests that they should be part of an object. Create a new class that represents the functionaity of these parameters, and pass the object instead.
• dividing the method: one of the reasons why a method has many parameters is that it may be doing too much. Try to divide the method into smaller ones. You should naturally see that only some parameters are used in a given part of the method, and therefore the newly created method for that part will not required that specific parameter.

Conclusion

Once you start to think about the principles of class and method design, the number of parameters per method in your implementations will reduce drastically.

Another advantage of thinking about the parameters passed to each method is that the code base will change for the better. What was once  an amorphous set of method calls will gradually transform into something that has a  meaning.

References

Robert Martin, Clean Code:  A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008

Kent Beck et al., Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series).

From time to time I like to check on the evolution of dynamic languages, just to see what I am missing as a Java/C++ programmer. It is always an interesting travel, and each time I feel that the future will be really far away from the C-like languages that we currently use.

Last week, I spent a few hours taking a look at the progress of Smalltalk. In the Smalltalk camp there are several contenders for the best system, and it is not at all clear what the most productive system is. I have already tried VisualWorks, which is a cool environment. Although it is easy to use, there is the problem that it is closed source. This makes it practical to use VisualWorks only on commercial software, instead of writing open source software.

Even when doing commercial work, most companies will not invest money in an IDE for a language that they don’t know — which makes the barriers to use of a commercial Smalltalk is even bigger. Of course, there are several companies using Smalltalk, but there is always a specific reason for this — if you can’t find that reason you are out of luck.

Squeak

For this reason, I think an open source solution is the best bet for SmallTalk to succeed. And the best open source implementation of Smalltalk is of course Squeak. The only thing that I had against Squeak is the fact that they still insist in using a particular GUI that is completely different from any other UI in use nowadays. In fact, Squeak notion of UI is basically a copy of what a GUI might have looked like in 1980, when SmallTalk was being developed.

In particular, the idea of Squeak practically forcing users to rethink the way they use the mouse is absurd. In Morph, the Squeak GUI, every mouse action depends on a three-button mouse. To add some confusion, buttons are named by colors (instead or right-or-left button), so you need to remember what color is left or right. Many operations also require the middle button (represented by still another color), and if your don’t have a mouse with three buttons you probably need to simulate that one with control/shift combinations.

Imagine if I created a software that remapped the keyboard, and decided that each key would not produce the results that you are used to, but instead the combination of letters that I decided. Of course, you would dislike this program (to say the least). But this is exactly what Squeak requires from the user, who needs to relearn how the mouse works.

Squeak and WxWidgets

 

Hopefully, Squeak, being written in Smalltalk, is not totally bound to the decisions made by its creators. One thing that can be done is to use a separate UI, and disregard totally the mess of Morph. This was the route taken by the guys that ported WxWidgets to Squeak — resulting WxSqueak. WxSqueak is an extension to Squeak that implements the WxWidgets UI library. WxWidgets is a full featured GUI library that is supported on most platforms, such as Windows, Linux, and Mac OS. 

With WxSqueak you can create SmallTalk programs that use the WxWidgets GUI, and therefore have a native look and feel. Thus, you can create a Windows program in Squeak, with native windows, toolbars, and menus. There is no need to program in another GUI such as morph, and make your users learn a new GUI paradigm just to execute your program.

WxWidgets is still in its early stages, but I found it very feature complete. Since it uses WxWidgets, which is a mature library, there is a large number of graphical controls that can be used from your program.

In the next weeks, I will be providing an example of a program written with Squeak and WxSqueak. I be also writing about some of the features of SmallTalk and Squeak that make it so useful for programmers in general. Keep reading, and I will add more details in future posts.

Suggested Reading

Smalltalk Best Practice Patterns, by Kent Beck

Smalltalk 80: The Language (Addison-Wesley Series in Computer Science), by A. Goldberg and D. Robson

Solving problems using software is the ultimate goal of software engineers. However, few people completely realize that just writing code is not the solution for all problems we will encounter. In many cases, the solution for code organization is to write less code, instead of more.

A common mistake that software developers do is to think that the solution for each new problem in a system can be found by writing another method and/or class. While this works most of the time, it usually renders the system even more complicated to understand and modify. Therefore, adding new features by means of more code hinders additional progress in the application, instead of helping.

The best solution to this situation is to take a step back, instead of adding more code. Think: how can the architecture of this system be improved so that adding this feature would be easier? When doing this, it is a frequent result that some code will be rendered useless, while more generic code will be added to hande a large number of cases. Thus, even when some software previously written needs to be removed, we are in fact making progress because the system will be able to handle more cases than before.

Although this approach is more painful in the short run, it is nonetheless the best way to develop a system in the long run.

Some Reasons to Avoid Code Inflation

I frequently try to think of ways of solving a problem using less code. When this happens, it is like finding a beautiful solution for a complicated problem — the same feeling that we have when creating beautiful mathematics. Here is a list of reasons why you should strive to write less code:

• Software accumulates features as it grows. Although these are useful when created, most side features become useless as time passes.
• The more features a piece of code has, the less apt it is to change. Thus, it becomes harder to react to new environments.
• Adding features is sometimes inevitable. Specially in a commercial application, adding features is a by-product of accommodating new users. In a big commercial application such as MS Office, it is just necessary. However, having a huge code-base is also a liability. You have to pay to maintain all this software that is not essential to the functionality of the application.
• When a new programming paradigm arrives, it is usually the smaller code base that has the advantage. That  is why software is such a good material for start ups: a new product needs only  a handful of core features to become usable.
• A corollary of this is that you shouldn’t try to compete with established players by just replicating their features. Try to move your application to a new paradigm that was not initially foreseen by  the established player — and that would make it very hard for your competitors to adapt. For example, that is what is happening in the area of web-based software vs. Microsoft.
• Usually, the smaller code base that can handle the core of a problem is the best — simply because it is the easiest to extend.

Do you have other reasons why a large code base is a liability? Let me know what you think.

I am one of the poor souls that need to use Lotus Notes as its corporate email solution. Although I learned to appreciate the integration capabilities that the IBM product has developed throughout the years, it still looks for me as one of the most over-engineered pieces of software that was ever written.

I was positively surprised, however, with the update of the Notes client to version 8.0. After years of using the tried-and-failed client interface that they insisted in maintaining, IBM decided to move to a new client based on Eclipse.

Eclipse to the rescue

Eclipse, if you are a developer working in Java, is already your old friend. Not perfect, but has lots of good extensibility features. For example, there are thousands of plug-ins available for Eclipse, ranging from productivity tools to programming widgets.

With the support for plug-ins provided by the Eclipse core, Lotus Notes can now add a lot of cool features practically for free. For example, the new Notes client can easily embed most (but not all) Google gadgets.

Look-and-feel

The look and feel of the application was also streamlined. The email window received a long-overdue overhaul. It looks now much more like a modern email app (such as Microsoft Outlook, if that is what you’re looking for).

To me, it looks like the Lotus team spend a lot of time replicating features from the old client. To my knowledge, the toolkit used in Lotus Notes 7 was written in multi-platform C++ (probably with a lot of biddings to Java code). Now, everything is in Java, using the Eclipse toolkit, which is definitely very different from the original C++. It must have taken IBM *years* to replicate the same functionality. It is not a surprise that Lotus Notes 8 appeared only now…

Even though the transition was mostly positive, on the negative side I noticed that the application size increased. Well, in fact the new program required 1GB to install! It is crazy to imagine an application (that is not a compiler, I have to say) that may need 1GB to be installed. Of course, these days where a 1TB hard disk is not a surprise anymore, things have certainly changed. I hope I am not the only person that still remembers applications being distributed on 1.2MB disks :-)