The thread of discussion started by Mike Spille’s comments on Rob Martin’s entry got me thinking.

"You Aren’t Gonna Need It" is not only a stupid statement, it’s also incredibly arrogant.  It takes some guts to listen to a suggestion and without even thinking about it, trying to understand what motivated it or even, heaven forbid, doing some research, retort "You aren’t gonna need it".

If my past experiences have taught me anything about the evolution of software, it’s "It Ain’t Predictible", or IAP (I’ve always wanted to dub a three-letter acronym, and it looks like your chances of coining such a term are largely increased if you use street-speak, so here is my contribution).

Seriously, it’s just mind-boggling what users will sometimes do with software you put out there.  They will twist it in forms you would never have imagined in your wildest dreams, ask for improvements, discover bugs on corner cases you didn’t even think were possible. 

Now that I am reminiscing, I actually remember vividly that about fifteen years ago, I faced this very problem when I was using a C++ library that wouldn’t let me override what I needed.  I just ended up downloading the source and replacing a few "private" with "public".  Little did I know I had just uncovered the IAP principle.

I don’t know, maybe Rob and I have different ways of solving problems, but we certainly have a different view on teaching.  If a student comes to me and shows me a design that I consider superfluous, I am not going to say "You aren’t gonna need it", but more something like "Okay, we could sit down after class and you could give me a few examples where your design will be better suited than the simpler one I recommend, but right now, I would suggest you focus on the task at hand so that you can fulfill the number one task that as a software developer, you will be facing at every step of your whole career:  deliver your code on time."

Rob Martin
wonders whether Data Transfer Objects (DTO, also known as value objects)
should have accessors or not:

The programmer was aghast. "DTOs are always made with private
variables and getters and setters!" he said. "Why?" I asked.

Rob argues that DTO’s should not have accessors but only public fields, which
should be the only way to access them:

In my view OO programs contain two kinds of entities: Objects and Data
Structures […] On the other hand there is no good reason to use getters and
setters in a data structure. A data structure is simply a packet of data,
nothing more.

While I agree with him about the distinction between Objects and Data Structures, the point that Rob
is missing is that it is quite common to start with a Data Structure and have it
evolve toward an Object as your code changes over time.  This has happened
to me countless times and the few times where I gave in to the simplicity of
declaring my Data Structures with public fields cost me some time when I had to
change not only the said structure but all the calling code to use accessors and
constructors instead of direct access.

Another reason why you should always use accessors for your DTO’s is that of
uniformity.

When I am trying to get a value from an object, I don’t want
to have to think "mmmh… is Employee a DTO or an Object?  I think it’s a
DTO so I’ll just write employee.firstName…  oops, no, I forgot it’s an
Object now, so I have to use employee.getFirstName()".

Uniformity is crucial. 

I already have enough to think when I
write my code, I don’t want to spend extra time second guessing myself or having to
browse the class I want to use before I can do something as simple as getting a
value.

Getters and setters are
not going away. Deal with it.

Don’t believe what
wannabe pundits and OO purists tell you. At the end of the day, every object becomes a primitive type.

Unfortunately, Java doesn’t have the prettiest way to handle getters and setters, which leads up to a lot of code obfuscation. Granted, we are now very much used to visually identify the pattern:

  private String m_firstName;
  public String getFirstName() {
    return m_firstName;
  }
  public void setFirstName(String fn) {
    m_firstName = fn;
  }

  private Integer m_socialSecurityNumber;
  public Integer getFirstName() {
    return m_socialSecurityNumber;
  }

Note that in the above example, I declared the field right next to its getters and setters, which improves readability and locality, in my opinion, but it’s a technique that is pretty much never used, making it even harder to find which fields are exposed with getters and setters and which ones are stricly part of the private implementation of the class.

Compare this to the terse but to-the-point pseudo-code:

  property String name;
  property readonly Integer socialSecurityNumber;

In order to support the most flexibility for attributes, a language needs to offer the three functionalities. Here is how Ruby, C# and Java address these three problems:

Note that another important feature supported by both Ruby and C# — but unfortunately not Java — is that of “Universal Access”. Regardless of how you choose to define your properties, they all end up going through the same code line when executed. In other words, you can start by define “attr_accessor first_name” and then later use more complex logic by defining “def first_name=”. In either cases, assigning this attribute will always end up calling the assignment method.

It’s too bad that properties didn’t make it in Tiger.

JUnit

Why does a TestCase get instantiated as many times as it contains test methods?

Try this:

public class MyTest extends TestCase {

  public MyTest(String name) {
    super(name);
    System.out.println(“Created a MyTest”);
  }

  public void testA() {}

  public void testB() {}
}

and you will see “Created a MyTest” displayed twice.

My initial reaction when I see code that puzzles me is to give the author the
benefit of the doubt, so my first thought was “Maybe they do this to make sure that test methods are independent from each other, that is, a test cannot fail because of a side effect created by another test method”.

Then I realized that this justification was stupid for two reasons:

• If I want two test methods to be truly independent, I will just put them in two different classes.
• The setUp() method is called before each test method, thus guaranteeing that the state of the object is restored before each invocation.

The more I thought about it, the more I realized that being able to share some state between test methods, such as a JDBC connection or a parsed XML file, was actually quite useful. The problem is that JUnit
makes this simply impossible:  you have to put this code in setUp() and
therefore, rerun it before every test method.

At this point, and after finding all these deficiencies in JUnit’s design and implementation, I am beginning to think we are once more stuck with a de facto standard that is utterly broken.

Unless someone can explain to me this behavior?

Why do we put Java fields at the top of the class?

Here is a typical example:

public class Employee {
  private String m_firstName;
  private String m_lastName;

  public Employee(String firstName, String lastName) {
  …

From day one, this convention has always struck me as odd and
counter-intuitive, especially coming from a C++ background where developers go
to great lengths to hide private members.

When I read a source code for the first time, I couldn’t care less about the
log instance and resource bundle it uses, or all the private HashMaps needed to
maintain its state.  My attention usually goes immediately to the outline
of the class showing all the public methods, and then to the constructor. 
All the rest is noise to me at this early stage.

Since it has now (sadly) become a standard, I put the Java fields of my
classes at the top, like everyone else, but I still can’t figure out why such a
nonsensical convention happened in the first place.

Any suggestion?