Initialisation inline or in Constructor ?

private Map<String, String> nodeValueMap = new HashMap<String, String>();
private Map<String, NodeHandler> nodeHandlers = new HashMap<String, NodeHandler>();			

Or

public MyClass() {
    this.nodeValueMap = new HashMap<String, String>();
    this.nodeHandlers = new HashMap<String, NodeHandler>();			
}

Well, I think I might have a rule of thumb… If you don’t actually have a constructor, then you should use inline instantiation. As soon as you need to do some more complex logic in the constructor (in the case above I might want to initialise the map with some objects) then move all the initialisers into the constructor ?

i.e. don’t have multiple patterns going on.

As an aside, a quick discussion with Alistair (of how big is my potato fame) reminded me of the fact that you can actually do an instance initialisation like:

{
    this.nodeValueMap = new HashMap<String, String>();
    this.nodeHandlers = new HashMap<String, NodeHandler>();			
}

Although what the case for doing so is im not sure, might be nice if you are making a STRUCT kind of object.

Also I didn’t realise that you can declare a class inside a method:

public void doSomething() {
    public class InnerClasss{
        public void sayHello() { System.out.println("hello");}
    }

    InnerClass inst = new InnerClass();
    inst.sayHello();
}

Alistair had used this for testing some reflection code, when he needed some test classes to work with.

Share

A Professional journal

I have been reading a few bits and pieces about the craftsmanship of software design. At the same time, I ave been thinking about ways to formalise my own learnings about software development. After reading about Corey haines’ pair programmin tour at cuberik it occured to me that this might be a good way to think about the process of developing as a software crafstman. As consultants, we move from project to project, working with different people in our own organisation and also within the client organisation.

Every new place brings different attitudes to code and design and provides an opportunity to pick up tricks and compare your own set of tools with those of others. At the same time, as a relatively experienced developer, you get to share your own ideas and experience with the people you work with. By working on comunication of these ideas, you learn more about them yourself and become more practised in their use.

Whilst this is at some level an intuitive process, by making it a concious process I think the results might be more focused. With this in mind, I have created a keyword for this blog called “a journeymans’ diary”. This is the first post in the series.

I plan to try and make at least one post a week, with lessons learned that week. The topics will be focused purely on software design, building code line by line.

UPDATE:

So I have changed my mind about this and now prefer to think of the whole thing as about being a “Professional”. Im keeping this post as a bit of history, but have now renamed this category, to avoid the craftsmanship overtones.

Share

Runtime Exceptions

 public void testExceptions() {
		TestExceptions tst = new TestExceptions();
		tst.iThrowARuntimeException();
	}

 private static class TestExceptions {

		public void iThrowARuntimeException() throws SomeRuntimeExceptionICreated {
			throw new SomeRuntimeExceptionICreated();
		}

	}

	private static class SomeRuntimeExceptionICreated extends RuntimeException {

	}
Share

Encapsulation, What is it Good for ?

I just had a moment of clarity about refactoring and encapsulation. Its a simple truth and is one of the basic tenants of the concept and I had kind of forgotten about it.

It occured to me because I was working with some javascript. Its very easy to end up with lots of global methods in JS unless you use your closures properly.

By putting variables inside functions you can make them private.

Why is this useful. Well consider that you want to CHANGE one of those functions. Change ? who would EVER want to do that ?

If it is declared as a private function you KNOW FOR SURE that no-one else is using it and therefore that YOU CANNOT BREAK ANY OTHER CLASSES.

Therefore it is COMPLETELY SAFE TO REFACTOR.

great isnt it!

Such a thing you take for granted and yet when you work with a different language domain it suddenly reminds you of all the good things about OO.

Share