There’s a trend in object-oriented design to favor aggregation over inheritance.  Allen Holub’s article "Why extends is evil" describes the problems with inheritance well.

The biggest problem with inheritance is it creates a tight coupling between a parent class and its descendant classes.  We’re all taught back in Programming 101 to encapsulate implementation details into functions and methods with well defined interfaces.  Later, we can change the implementation details without having to worry about breaking the rest of our code as long as we don’t change the interfaces.

But inheritance has a way of creeping in and destroying this encapsulation.  So, you might change an implementation detail of a base class method without changing its interface or semantics at all, and in the process, you might badly break a subclass. In other words, you can’t safely change a base class without first understanding the impact of the change on all of its subclasses.

continue reading "Aggregation with Automatic Delegation"

Part 1 of this series examined the problem of how to build unit tests when adding new features to legacy code that may not be structured perfectly, that is, typical real-world legacy code. How do you structure your new code or refactor the legacy code so that you can stub out the legacy services needed by your code when testing?

For most cases, we found techniques that work, but with a bit of pain. You can extract interfaces for your legacy services and write your new code against those interfaces. But, every time you add a new method to the legacy service, you must also add it to the interface and add it to each of your dummy test stubs. That’s a bit tedious. When your legacy service requires you to subclass, you can subclass with a simple adapter class and then use composition so that the adapter delegates to your real class, which is no longer a subclass of the legacy service. While that works, it’s certainly a bit awkward and confusing.

continue reading "Techniques for stubbing out dependencies when unit testing Java code (part 2/2)"

This is the first of a two-part series talking about how to stub out dependencies on other services when writing unit tests for Java code.

Setup. Suppose you’re a developer working on a large, old piece of software.  Like most real-world software that has been around for a while, your application is buggy; it’s had lots of developers working on it; the code is not structured well or consistently; and the code is not covered adequately by unit tests, or perhaps it has no unit tests at all.  Despite the code’s problems, there is not a good business case for spending several years and millions of dollars to do a big bang overhaul/rewrite.  (In my experience, management almost never approves rewrites.  And, that’s probably a good thing.  See Joel Spolsky’s famous article on rewriting software.)

continue reading "Techniques for stubbing out dependencies when unit testing Java code (part 1/2)"

Anthony W. Ulwick offers a commonsensical approach to understanding the criteria for making customers successful in his book, "What Customers Want." His methodology calls for the gathering of jobs and desired outcomes through a series of interviews with customers. The challenge is that we don’t always know how to get that kind of information nor do we have the skill to navigate an interview towards our desired goals. Here, I offer some tips for making your interviews productive.

Don’t assume your customer is confident in the value his job provides the organization.

It’s important to understand that people don’t usually feel comfortable discussing the details of their job with anybody outside of their company and sometimes even with people inside their company. The latter is usually the result of the lack of confidence in the value they provide. In the comedy Office Space, one character started feeling nervous when explaining his role to Optimization Analysts. He described his job as being the guy who gets requirements from the customer and asks his secretary fax them to the programmers.  (No wonder he didn’t want to admit his job. Had he followed Ulwick’s method, he’d be a little more confident about the value he brings to his organization.) Remind your customer that unlike The Two Bobs, you’re there to make him successful, not to rationalize the existence of his job.

continue reading "So, what would you say you do here?"

Have you heard that Men are from Mars and Women are from Venus? It’s an attempt to explain the differences between men and women in order to improve communication between the two. When he asks, "Can I go out with the guys tonight?" He means, "Can I go out with the guys tonight?" When she responds, "Do whatever you want to do." She means, "No." The same kind of communication issues exist between users and developers.

I remember reading about a consultant back in the 80’s who responded to a call from a user who had two computers in her office. One computer would receive a nightly batch of records and produce a hard copy report. She would then manually key-in the data into the second computer. The consultant was asked to revise the software that produced the report so that the columns were ordered differently.  "Change the order of the report’s columns from A, B, C to A, C, B."  A reasonable consultant would have said, "Yes ma’am" and begin working. After all, this is a customer-driven requirement.

continue reading "How to Design the Perfect Product"