Tuesday, November 23, 2004

Testing private methods

While researching ways to "sneak around" interfaces and package access (I seem to remember hearing there's some way to do this), I came across this:


I'm with Bill on private method testing. Unit testing allows you to test at the granularity of the method, and the reason you break code up into private methods is to manage complexity. But if you can't test at that level, it's defeating.

My guess is that they were backfilling when they said that. Because JUnit can't test private methods, let's say it's a bad thing to do.

Friday, November 19, 2004

How do you tell someone their code/design is bad?

In the comments following Weblogs Forum - OOP Case Study: The Bank Account Class (Part 3), Michael Feathers states "...where I think we fail in the industry is that we have not accepted the reality that there is a lot of really crappy code out there. A lot. ... We need to realize that many people have screwed up and that there are things we need to do to fix that beyond helping people acquire better design skills."

Although this is certainly true, what I'd really like to know is what are these things that we need to do? I think this is more in the realm of psychology. A big question that I have for Michael is: How do you tell someone that their code or design is bad in such a way that you don't encourage them to slam the door in your face? Do you confront them or do you try to present ideas that may lead them into making their own conclusion? Or are there other ideas for this (which sounds like it may be more like something in Esther Derby's domain, and folks like her).

Thursday, November 18, 2004

Java and operator overloading

A consistent form of amusement since the beginning of Java is how the designers bashed operator overloading in C++, without really examining the problem, which is basically that operator overloading in C++ is complex and hard for the programmer to get right.

However, with a garbage collector and other improvements afforded by Java and C#, operator overloading becomes fairly straightforward, as the Java designers would have noticed had they looked at Python, a language which predates Java and which supports operator overloading without any fuss. C# has since demonstrated that operator overloading could have been added to Java without making it painful (at this point in Java's lifetime, however, there are probably more important problems to be solved).

In the meantime, Java's String class with its + and += shows how difficult it was for the Java designers to excluded operator overloading from the language. Sometimes operators are helpful. Or, put another way, the thing about syntactic sugar is that it's sweet.

I thought of all this when I came across the following in the Javadocs for BigDecimal:

For the sake of brevity and clarity, pseudo-code is used throughout the descriptions of BigDecimal methods. The pseudo-code expression (i + j) is shorthand for "a BigDecimal whose value is that of the BigDecimal i added to that of the BigDecimal j."

Whoever wrote this class was clearly missing operator overloading.

Tuesday, November 16, 2004

Static vs. Dynamic

I've added a new article here. (As I have changed the RSS feed to this web log, I will announce all articles here).

Monday, November 15, 2004

IT Conversations and Podcasting

On the drive down and back to Albuquerque, I listened to nothing but interviews and presentations from the IT Conversations web site. I was amazed that I had managed to put so many onto a single MP3 CD that it would last me all those hours.

There were a small number of these that I skipped past, but in general I found value in almost every one, including technical insights that were quite useful. A fair number of the presentations were from conferences, so I had the benefit of hearing some of the conference talks without having to go. It seems that more conferences would do this, at least capturing things like keynote presentations and panel discussions that are already open to the public (I'm thinking in particular of the Software Development conference, but I could easily imagine something like the Python conference capturing a number of their presentations for IT Conversations). It seems like the downside is negligible and that it could only help promote the conferences.

They had a number of discussions about podcasting itself, and most of the comments were ones that made sense to me -- in particular that it's a different medium because you can't skim it like you can a web log, and thus the content and editing become much more important. I would like to further explore the possibility of podcasting but issues of hosting become important. Not just the volume of data transfer that becomes necessary, but If people require the enclosure model then that's something that I won't want to have to create and manage (I've got too many other things to do). I'll need some other system to host podcasts for me, ideally in the same way that blogger does it (i.e. free and easy). That's a bigger commitment because of the bandwidth requirements.

If you know of such services please note them in a comment.

Composition vs. "wiring"

At last week's seminar I created a new exercise during the threading portion. The goal of the exercise was to get people comfortable with the idea that threading can cause collisions over shared resources, and that the synchronized keyword prevents these collisions.

While people were solving this exercise I discovered that although the concept of composition was clear to everyone, the idea of setting up a number of object instantiations and wiring them together (by handing a reference of one object to the constructor for another object), was very unclear. As this is, to me anyway, one of the fundamental idioms for solving problems, I've found it interesting that either (1) I wasn't conveying the concept (probably thinking it to be obvious) or (2) somehow the way we approach objects distracts us from such a fundamental idea. It's almost as if an electrical engineer who spends too much time with equations and models doesn't know how to actually wire together a set of chips.

Another observation that comes from this is the overuse of Singleton. I have noticed that there seems to be a movement in parts of the design patterns community to deprecate or even ban Singleton. I wonder if this isn't because of all the emphasis on the design of classes and how you use inheritance and polymorphism in interesting ways, and the underlying assumption that people will naturally know how to design programs using these classes. Without more explanation about how you create objects and wire them together into a program, singleton may be what people tend to think about.

Just enough Java

Last week I gave an in-house seminar in Albuquerque. For the last few years I've been focusing on more advanced seminars like Thinking in Patterns and Designing Objects & Systems. So this is the first time that I have given anything like "Thinking in Java" for quite awhile. On top of that, this group had very mixed programming experience and they asked that I give just enough Java to get the to JDBC, Servlets and JSPs, since what they wanted to do was basic web programming.

As a result, I was forced to strip out everything from the seminar that was non-essential. This was a particularly interesting exercise. When I go to all the trouble of digging in and figuring everything out, I tend to get fascinated/attached to particular subjects and examples and have a hard time letting them go. It all seems important. But in this case I had the challenge of not overwhelming significant parts of the audience, and also leaving enough time for introductory JDBC, Servlet and JDBC exercises on the last day. I had to let go of a lot.

I also wanted to introduce more exercises to break up the lectures. From my experience with the Thinking in Patterns seminar, I find that people work best if you give them one concept and then immediately have them do something with that concept.

At the end of the week, everyone seemed quite happy, including me. I discovered that giving people less, but making sure they had a strong understanding of what they get, is far more satisfying that giving them lots of stuff but with only a passing grasp of what they see.

This seminar has made me re-think what I'm doing. Not Thinking in Java per se, but the seminars that come from the book. Originally I created the seminar and developed the book from the seminar, so I always thought in terms of a one-to-one mapping between the book and the seminar. But Java continues to expand, increasing its surface area like an expanding sphere. It has long past the point where you can cover a significant part of it in a week unless the group is already reasonably proficient in the language.

So it appears that there need to be several seminars, serving different needs. For example, there are a lot of people who are motivated to use Java just so they can do basic web programming with JDBC, Servlets and JSPs. Subjects like reflection, serialization, RMI, native methods, in-depth collections, etc. are not essential to such a pursuit. On the other hand, there are folks who know the basics of Java and would like to have more depth in some of the other interesting areas of the language. There are at least two seminars here, rather than the former single seminar.