Posts Tagged ‘ Design ’

OT2004 : Personal Practices Map

In the evening, everyone had a chance to run a Birds of a Feather session. I thought I’d give it a go and repeat the session from XtC last year.

It was a chance to talk to other developers about the little things we do that help guide development.

It was a calm and enlightening session. I felt I learned a lot from the attendees. Techniques that I would probably otherwise never know about unless I actually paired with them.

I look forward to doing this again at ADC.

Romilly generated a topic map from the results: (click here)

2004
04/01
CATEGORY
Software
TAGS


1 comment

OT2004 : Mock Objects: Driving Top-Down Development

Nat and I were first up with our talk on Mock Objects. Yes, we are still harping on about them :).

Here’s what we covered:

* OO concepts: an application is a web of collaborating objects, each providing a distinct responsibility and taking on multiple roles to provide services to other objects.
* How the process of using mock objects complements TDD to drive out the design of these responsibilities and roles.
* How our original usage of mocks for testing system boundaries such as databases, web-apps, GUIs, external libraries turned out to be a bad approach and the success we started achieving when inverting this to only mock types we can change.
* The process of using mocks very quickly points out key abstractions in your system, difference in responsibilities between objects and services objects require.
* Clearing up misconceptions about mocks, including: not using them at system boundaries and what they actually are (not stubs, not recorders, no behaviour).
* Our first public demonstration of the new JMock API to walk through a single iteration of the process.
* Usage patterns.

Feedback from: James Robertson @ Cincom Smalltalk and Mike Platt @ Microsoft.

2004
03/31
CATEGORY
Software
TAGS




4 comments

Inversion of Control and Dependency Injector Pattern

Martin Fowler has pubished a new article:

bq. In the Java community there’s been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of “Inversion of Control”. In this article I dig into how this pattern works, give it the more specific name of “Dependency Injector”, and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.

Read more

2004
01/14
CATEGORY
Software
TAGS
17 comments

What’s a YAUL? Or a YAUC?

Hani has a very valid post about util libraries.

Libraries that just have a bunch of non focussed utils in them, rarely provide a benefit to anyone other than the original authors.

When developers are looking into using a third party library, it is for a specific reason. A library that has a specific focus may meet this requirement, whereas an all-purpose util library rarely will (and even if it does, it is unlikely that it will be found).

Much of the code within the library may serve little purpose outside the context of the application it was originally built for, but not necessarily all.

By identifying the code within that has defined focus, you can extract that out and provide a library with a specific purpose.

Example

Whilst developing many parts of OpenSymphony (and our own bespoke applications that use OpenSymphony), we noticed there were many odd little methods that we found useful, which lead to the conclusion that other people would also find them useful. We slapped them together into a util library and OSCore was born.

This library lacked a clear responsiblity and in the end became a dumping ground for code that didn’t seem to belong elsewhere. As a consequence, it wasn’t successful. No one is going to choose to use a library that does this, that, a bit of this and has that really useful method there.

Eventually this was learned and the one part of the library that had a clearly defined use (PropertySet) was split out into its own project. Today, PropertySet is a well used library, whereas the rest of OSCore has faded into the background.

Incidently, this is a lesson we learned early on in OpenSymphony and the result has been many quality components since, many of which I rely on today.

YAUCs

As well as libraries, this also applies to individual classes. A class named CheeseUtil express very little about the focus of the class other than it’s got something to do with cheese. As a result util classes often grow fairly big and lack clear design (in fact, they often end up as a bunch of public static methods).

In this case a util class can be refactored into many smaller classes which can each flourish on their own, with their own design.

YAUC Example

In OSCore there’s a class called XMLUtils.

From the JavaDoc:

XMLUtils is a bunch of quick access utility methods to common XML operations.

These include:

* Parsing XML stream into org.w3c.dom.Document.
* Creating blank Documents.
* Serializing (pretty-printing) Document back to XML stream.
* Extracting nodes using X-Path expressions.
* Cloning nodes.
* Performing XSL transformations.

Authors: Joe Walnes, Hani Suleiman :)

Unless someone had specifically looked at the JavaDoc or methods of every single class in the system, there would be little chance of knowing that.

Breaking this class up into many smaller classes, errm, objects such as XMLParserFacade, XMLPrettyPrinter, NodeCloner, XPathEvaluator and XSLTransformere, expresses the intent clearer and is much more likely to be found.

(Hani and I have since learned from these mistakes).

h4. Conclusion

Small and clearly defined responsibilities for libraries and individual classes results in improved reuse as they have an increased chance of meeting part of a developer’s requirement.

2004
01/10
CATEGORY
Software
TAGS


3 comments

When simplicity backfires

I put a lot of effort into refactoring a larger, more complicated library into the lean and simple Squiggle you see today.

Annoyingly…

bq. Freshmeat tries to avoid listing projects which fall below a certain level of size and/or complexity, and yours is unfortunately a bit too simple for our application index. Your contribution has been respectfully declined.

2004
01/08
CATEGORY
Software
TAGS




7 comments

Tutorial: Using mock objects to drive top-down development

Tim Mackinnon and Nat Pryce and Steve Freeman and I are presenting a session on how mock objects can be used to drive code from the top (requirements first, infrastructure last) to produce high quality, clean and decoupled object designs that allow for business change.

Come see us at:
* XPDay Benelux – Fri 21st Nov 2003, Breda, Netherlands
* XPDay London – Tue 2nd Dec 2003, London, UK.
* OT2004 – Tue 30 Mar 2004, Cambridge, UK.

Excerpt:

Mock objects are usually regarded as a programming technique that merely supports existing methods of unit testing. But this does not exploit the full potential of mock objects. Fundamentally, mock objects enable an iterative, top-down development process that drives the creation of well designed object-oriented software.

This tutorial will demonstrate the mock object development process in action. We will show how using mock objects to guide your design results in a more effective form of test driven development and more flexible code; how mock objects allow you to concentrate more on end-user requirements than on infrastructure; and how the objects in the resultant code are small and oosely coupled, with well-defined responsibilities.

Includes:
* Brief introduction to mock objects and the dynamic mock API.
* The mock object design process explained.
* Top down vs. bottom up design.
* What to mock. And what not.

More…

2003
11/10
CATEGORY
Software
TAGS



Comments Off on Tutorial: Using mock objects to drive top-down development

Test Driven Development is not about testing

Dan writes:

bq. “Writing the test before you write the code focuses the mind – and the development process – on delivering only what is absolutely necessary. In the large, this means that the system you develop does exactly what it needs to do and no more. This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests. ”

Read the rest here.

2003
11/05
CATEGORY
Software
TAGS


Comments Off on Test Driven Development is not about testing

Discuss your maintainability patterns

If you’re anywhere near London on Tuesday 29th July, come along to the eXtreme Tuesday Club (XTC) and we can talk about the coding and design practices that make for maintainable code in the long term.

This is how we’ll do it. Prepare in advance.

Meanwhile, I’ve seen some excellent feedback on what makes for good maintainable code. There is a central overlap of core techniques that developers who have to maintain code in the long term have grown to adopted. And yet, even knowing these things work, they often slip our minds.

2003
07/22
CATEGORY
Software
TAGS

Comments Off on Discuss your maintainability patterns

Design by contract: testing implementations of interfaces

Here’s a nice way of associating contracts with interfaces and testing the implementations conform.

A sample interface:

interface CheeseMaker {
int getCheeseCount();
void addCheese(Cheese cheese);
}

With the contracts:

* there should be zero cheeses on creation.
* adding a cheese should increment the count.
* unless the cheese is a duplicate.
* when adding a cheese, the cheese cannot be null.

You can create an abstract unit test for this interface that tests these contracts. The only thing it doesn’t do is provide an implementation – instead it has an abstract factory method.

public abstract class CheeseMakerTest extends TestCase {

// abstract factory method
protected abstract CheeseMaker createCheeseMaker();

public void testZeroCheesesOnCreation() {
CheeseMaker cheeseMaker = createCheeseMaker();
assertEquals(0, cheeseMaker.getCheeseCount());
}

public void testAddingACheeseIncrementsCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Wensleydale"));
assertEquals(2, cheeseMaker.getCheeseCount());
}

public void testDuplicateCheesesDoNotIncrementCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Cheddar"));
assertEquals(1, cheeseMaker.getCheeseCount());
}

public void testNullCheeseCausesIllegalArgumentException() {
CheeseMaker cheeseMaker = createCheeseMaker();
try {
cheeseMaker.addCheese(null);
fail("expected exception");
} catch (IllegalArgumentException e) {} // good
}

}

Now, every time you create an implementation of CheeseMaker, the test should extend CheeseMakerTest and you inherit the contract tests for free.

For example:

public class BigCheeseMaker implements CheeseMaker {
// ... ommited for sanity
}

public class BigCheeseMakerTest extends CheeseMakerTest {

// factory method implementation
protected CheeseMaker createCheeseMaker() {
return new BigCheeseMaker();
}

// ... any additional tests go here

}

It’s important to note that this tests the contract but does not enforce them. It’s very flexible and there are very few contracts (if any at all) that couldn’t be expressed in a unit-test.

This helps defensive development with the added safety of unit-tests.

As a bonus, you can use TestDox to generate documentation for interfaces (much more useful than implementations), like so:

h4. CheeseMaker

* Zero cheeses on creation.
* Adding a cheese increments count.
* Duplicate cheeses do not increment count.
* Null cheese causes illegal argument exception.

2003
07/18
CATEGORY
Software
TAGS


Comments Off on Design by contract: testing implementations of interfaces

Maintainability patterns

I love tech. Look at all the fun stuff that’s happening in this development wonderland at the moment.

We have libraries to do everything under the sun. Persistence, web-apps, security, code generation, presentation, remoting, messaging, concurrency, XML processing, testing, containers, you name it. In Java-land, opensource seems to be dominating the market and we’re even starting to see books dedicated to the subject (end of shameless plug).

It’s easy to get seduced by the sparkle of how these tools can make magic happen quickly. With these tools, a system can be delivered in record time. Win!

But delivery is really just a short term win. After delivery comes maintenance and this is where most development teams get stung in the long term. It becomes harder and harder to add or refine features as time goes on. Chris Matts pointed out that over the life of a project, the cost spent on development is insignificant compared to the cost of maintenance.

It’s impossible for a sexy library alone to make your code maintainable. Using JUnit or an AOP library will not solve the problems. It’s the *techniques* that complement these that make applications more maintainable. The tools are just the icing on the cake and you really don’t have to use them.

The techniques are unfortunately less seductive than the tools, yet far more important. I often find myself answerless when faced with explaining the benefits of separating the interface from the implementation, using mock objects, inversion of control, aspect oriented programming or avoiding statics.

In most cases, I found there is no benefit of using a technique in isolation. Instead, they benefit each other. It’s the relationship between the techniques that are important and they all support one thing – maintainability. The relationships are patterns.

So, I have a theme for upcoming posts on the blog: *maintainability patterns*. What techniques we can employ to make code more maintainable and how they relate to other techniques.

2003
07/03
CATEGORY
Software
TAGS

Comments Off on Maintainability patterns