wickedcoolthoughts

.Net Type Safety

2008-03-26T23:38:00.000-07:00

Working with the ternary(conditional) operator in C# I came across an interesting problem. The following piece of code does not compile.


class Cat{}
class Computer{}
......
Object obj = need_a_cat? new Cat():new Computer();
......

The above code fails with an error that " there is no implicit conversion between Cat and Computer". That is correct ;).However still wondering why is a type checking required in the above case.

On the contrary with enums where type checking is expected there is no type checking!


enum Day_Of_Week { sun, mon, tue ....}

String DoSomething(Day_Of_Week day) {
.......
}

....

DoSomething(Day_Of_Week.sun+109);

The above call DoSomething(Day_Of_Week.sun+109); should have failed during compilation. But it doesn't ;)

Refactoring vs Redesign??? or Restructuring

2008-02-14T04:05:00.001-08:00

Is it refactoring or a redesign?
Its a 'big refactoring'.
We spent the last two weeks on refactoring.
You guys are doing redesign and calling it as refactoring.

I am sure that most of us would have come across questions/statements like the above on various occassions. The above statements initially gave me a sense that its the magnitude of the change that differentiates between a refactoring and redesign.

Last evening I had a chance to chat with Martin Fowler regarding this and here is Martin's words.
"Rather than Refactoring vs Redesign I would like to see it Refactoring vs Restructuring. Refactoring is one of the ways to restructure your code. You can restructure your code by rewriting a class also. Refactoring is my preferred way of restructuring. While each transformation(refactoring) will result in a small change, a sequence of transformations(refactorings) can produce a significant restructuring.".

More about refactoring can be found here.

OR Mappers for .Net, NHibernate vs LLBLGen

2008-01-30T06:13:00.000-08:00

In one of our previous projects we had to make a choice between the OR mappers NHibernate(1.x) and LLBLGen(2.5). It was a difficult decision and we ended up discussing various aspects. The decisive factors for the choice were mostly non-technical, like familiarity with the product, the clients willingness to pay/not to pay for a product, support requirements etc. Under such circumstances we may have to make a choice that we may not be quite happy with, as developers.

However a little time on the design and practices can help us to overcome some of the limitations. I would like to look at the differences/similarities and explain how some obvious design practices can solve some limitations.

1.What is?

NHibernate: OR Mapper. Works on plain objects.
NHibernate helps you to persist your domain objects.

LLBLGen: OR Mapper + Code generator.
Works on generated(from a database schema) entity classes.
LLBLGen helps you to deal with the data access tier.

2. Support: You know it :-). Its between free and paid software.

3. Documentation: There is quite a bit of documentation available for both LLBLGen and NHibenate. Also the source code is available for both.

4. Supported Databases: Both NHibernate and LLBLGen works for all major databases.

5. Mapping of objects to databases: NHibernate uses HBM(xml) files for database mappings while LLBLGen generates code using a visual OR mapping tool. While NHibernate XML mappings are not easily refactored the LLBLGens binary project file which makes it quite difficult to control the versions. This could be a serious limitation with big teams.

6. Database First or Domain Objetcs first: Its a matter of taste.

One argument is that, with LLBLGen typically the database is created first and the entity classes are generated. After any changes to the database the entity classes need to be generated again. Since the refactoring and IDE supports for the SQL is not as good as programming languages creating the database first may slow you down a bit.

Reallistically this problem(if at all) can be solved to some extent by creating a domain layer above the data acess layer and play around with your domain objects first and later think of the persistence.

7. Design style: In couple of projects using LLBLGen I have seen the entity classes are being passed between the client and server(across different layers). Using the entity classes as a replacement for your domain objects has some limitations.

The LLBLGen entity classes introduces coupling to the data access code and also has limitations to work with some frameworks (if I remember it correctly .. the LLBLGen documentation talks about this somewhere. eg: WCF support).

The interface of the generated classes is a little polluted to use them as domain objects.

This has nothing to do with LLBLGen, but is all result of using the data access entities as domain objects.

8.Productivity: If we use the LLBLGen generated entity classes to replace the domain objects we may save some time and effort. What percentage of the total effort? Does it provide enough value for you? ..need to consider these questions before we make a decision.

If we go with a domain layer over the entity classes there is not much productivity gain. Or am I missing something here???

Disclaimer: The above is based on some preliminary evaluation of the products.

I would like to hear from someone who has used both of these products seriously.

Classification of objects

2008-01-17T02:50:00.000-08:00

Think no software for this post!

1. I have a collection of objects of different classes, some rectangles, some circles, some hexagons and few points. All of the above objects can be drawn and draw is the core/distinguishing behaviour of all the objects above. How can I classify the above objects/classes further? Is it possible to come up with a single common class that can represent all the objects? If so, is that class good enough to convey a concept without ambiquity?

2. I have another collection of objects lets say some humans, some robots and some cars. Lets say all the humans party on the weekends ;-), the robots assemble cars and the cars can be driven. Assume that these are core behaviour of the respective classes. Given the requirements above can I classify the objects further? With the above mentioned core/distinguishing behaviours of the objects further meaningful classification is not possible.

3. Now let us say there is a radar which needs to track all moving objects.

From problem 2 (above) the humans, robots and cars are all objects which can move and we were not interested in the move behaviour until the tracking requirement was introduced. Now we can say humans, robots and cars has ability to move and we are interested in this behaviour.

The objects which were otherwise unrelated is now related because of the new behaviour move. And move here is not the distinguishing behaviour of any of the objects/classes.

OK, now we can group objects/classes based on their distinguishing behaviours or some other common behaviour. When objects/classes are classified based on their distinguishing behaviour the resulting class is widely accepted and is applicable whereever the objects are used.

Eg: Rectangle is a kind of Shape and holds good always.

However in the grouping based on a non-distinguishing behaviour the resulting group does not define a class will not be applicable always.

Eg: Robot is a kind of Movable (even if we say so) was not applicable till the tracking requirement was introduced.

So what is the distinguishing behaviour of the objects? Its up to YOU to decide as needed by the domain.

The design of the above in a programming languge is a personal preference and I prefer to maintain the conceptual integrity in the design. Some considerations are covered in the post Abstract Class vs Interface.

Abstract class vs interface continued...

2008-01-14T05:51:00.001-08:00

Hope to clarify some questions/confusions on my previous post on Abstract class Vs Interface. Here I am trying to look at the conceptual difference only.

"Of course an interface defines a type": Interesting thought. I would appreciate examples to have a better understanding of the statement.

If interface here refers to the java interface (Walkable as in my previous post), the behaviour walk specified by the interface is not sufficient to define a class/type of objects referred by the Walkable interface.

If interface is used to refer the messages you can send to an object, I would say the type defines the interface.

When modeling a problem say BankAccount,

we do not start from deposit(...) , withdraw(...) interfaces to define the type BankAccount. We would rather start from the BankAccount.

However when we do classification of objects we do start from the interfaces of the objects to create a class/type.

"just wanted to know if we cannot say "walk" as a behavior/type?":

Perfect to say, walk is a behaviour. However not sufficient to define a class/type of objects referred by the Walkable interface as mentioned above.

Again Abstract class vs Interface...

2008-01-10T07:22:00.000-08:00

While pairing with a fellow thoughtworker (http://thoughtworker.in) we ended up discussing Abstract class vs Interface and he found this explanation useful.

A Class (abstract or not) defines a type while an interface does not.

In my domain anything that can be drawn is a shape(including a point) and thus behaviour defines a type.

abstract class Shape
{
public abstract draw();
}

In another domain which includes a Robots, Humans and Pets,
If I need to treat all objects that can walk similarly, I would like to have an abstract handle to of all the above and that ends up in a

interface Walkable{

void walk();

}

...Robot implements Walkable{...}
...Human implements Walkable{...}
...Pet implements Walkable{...}

and merely something that can walk does not define a type here. Its a mechanism to tie together otherwise unrelated types Robot, Human and Pet.

Test your unit tests + 1 anna

2008-01-10T06:27:00.000-08:00

There is no new idea here, however my priliminary search in google did not bring up something similar to what I want to write about.

This is just another observation I had with unit tests (applicable to others as well). When the tests were run in the build all of them passed always. However when I ran a single test there were some unexpected failures.

A close look into the tests revealed that the tests, the faling test had a dependency on some other test runs. Yes they are bad tests and tests are not supposed to be written that way. But they still exist!

Again how can we find them early?

Shuffle the test order. Write a RandomTestRunner Decorator?

BTW we were discussing the Decorator pattern (hammer) today and everythings seems like a nail ;)

Test your Unit Tests?

2008-01-09T04:48:00.001-08:00

When I was working on a project in the past I stopped the webserver and database before running the unit tests. To my surprise I found 40+ unit tests started failing. As you would guess the tests did not use the proper test doubles (mocks/stubs..).

The next interesting finding was some tests started failing when they were run repeatedly (the same test multiple times in a single build).

Both of the above problems are not typical in a fresh development project with people having the right experience with testing/TDD. However these problems could emerge when your team has

- less experience in testing or
- you are working on a legacy codebase which is not testable.

With the legacy codebase, refactoring the codebase is an option to make it testable. However you need tests to refactor with confidence. Its a cyclic dependency problem. So the idea should be to add tests as early as possible. Such tests may be often added at a higher level and may not be proper unit tests. Such tests should be refactored later as the refactoring of the legacy codebase progresses. Due to various reasons some of such tests remain unattended and remain in the codebase. Most of the times the reason why they continue to be in the system is because we do not know that they needs to be addressed.

So what can we do about it?

1.Automate your build scripts to shutdown all the integrating systems, as a part of your build script, before you run the unit tests. Stop the webserver, database server, disable network connections etc..

2.Automate the build script to repeat the tests (the same test multiple times in a single build) occassionally (may be with the nightly build). We can use a decorated TestRunner for this.

So we have added two parameters of the unit test quality to our build
the 'unitness' and 'repeatability'.

Design Patterns : Explosion of strategies

2008-01-04T04:20:00.000-08:00

"What could too many strategies in your application mean?", was an interesting question while we were discussing the Strategy pattern in ThoughtWorks(Bangalore) patterns study group.

The thoughts around this was there is a possibility to combine the strategies to higher level entities and behaviours.

Lets look at the example of Bank account and the evolution of the BankAccount object.


class BankAccount {

 public Money withdraw(Money amount){

  if(account_locked)
   throw new AccountLockedException();

  else if(transaction_limit_exceeded)
   throw new AccountLockedException();

  else {
   //more logic
   balance.subtract(amount);
   //more logic
   return amount;
  }


 }

}

Looking at the if-else structure the instant answer for this issue was a Strategy pattern. OK Now we have


abstract class WithdrawalStrategy {

 abstract Money withdraw(Money money);

 public static final ACCOUNT_LOCKED_WITHDRAWAL = new WithdrawalStrategy(){.......};
 public static final LIMIT_EXCEEDED_WITHDRAWAL = new WithdrawalStrategy (){......};
 public static final LIMIT_EXCEEDED_WITHDRAWAL = new WithdrawalStrategy (){......};

}



class BankAccount {

 public BankAccount(){

  this.withdrawalStrategy = .....;
 }

 public Money withdraw(Money amount){

  return withdrawalStrategy.withdraw(amount);
 }


}

Soon we we added a deposit operation to the BankAccount object. Again we ended up having strategies. Now we have


abstract class WithdrawalStrategy {

 abstract Money withdraw(Money money);

 public static final ACCOUNT_LOCKED_WITHDRAWAL = new WithdrawalStrategy(){.......};
 public static final LIMIT_EXCEEDED_WITHDRAWAL = new WithdrawalStrategy (){......};
 public static final EVERYTHING_OK_WITHDRAWAL = new WithdrawalStrategy (){......};

}

abstract class DepositStrategy {

 abstract Money deposit(Money money);

 public static final ACCOUNT_LOCKED_DEPOSIT = new DepositStrategy(){.......};
 public static final LIMIT_EXCEEDED_DEPOSIT = new DepositStrategy (){......};
 public static final EVERYTHING_OK_DEPOSIT = new DepositStrategy (){......};

}



class BankAccount {

 public BankAccount(){
  ...........
  this.withdrawalStrategy = .....;
  this.depositStrategy = .....;
 }

 public Money withdraw(Money amount){

  return withdrawalStrategy.withdraw(amount);
 }

 public Money deposit(Money amount){

    return depositStrategy.deposit(amount);
 }


}

Here both deposit and withdrwal strategies are decided by ACCOUNT_LOCKED,LIMIT_EXCEEDED or EVERYTHING_OK state. So lets try to unify deposit and withdraw.


abstract class WithdrawalStrategy_Plus_DepositStrategy {

 abstract Money withdraw(Money money);
 abstract Money deposit(Money money);

 public static final ACCOUNT_LOCKED = new WithdrawalStrategy_Plus_DepositStrategy(){.......};
 public static final LIMIT_EXCEEDED = new WithdrawalStrategy_Plus_DepositStrategy (){......};
 public static final EVERYTHING = new WithdrawalStrategy_Plus_DepositStrategy (){......};


}

Here WithdrawalStrategy_Plus_DepositStrategy can be renamed as

AccountState



abstract class AccountState {

 abstract Money withdraw(Money money);
 abstract Money deposit(Money money);

 public static final ACCOUNT_LOCKED = new AccountState(){.......};
 public static final LIMIT_EXCEEDED = new AccountState (){......};
 public static final EVERYTHING_OK = new AccountState (){......};


}

The idea here is to explain how the problem of explosion of strategies can be solved by unifying the strategies. ( No I never intend to discuss State vs Strategy here ;))

Object Relations:my friends car can run on my car's tyre....!

2007-12-31T04:40:00.000-08:00

See how my friends car can run on my car's tyre!

Car myFerrai = new Car();

Car myFriendsFerrari = new Car();

Tyre tyre = myFerrari.removeTyre();

Tyre flatTyre = myFriendsFerrari.replaceTyre(tyre);

myFriendsFerrari.drive();

And with the Building and Floor, No you cannot exchange the Floor(s)

The beauty of return this;

2007-12-18T23:21:00.000-08:00

As a beginner I was fascinated by the repeated append calls on the StringBuffer (Java) object. Especially because of the saving in the typing and no more string concatenation.

new StringBuffer("start").append("more").append("more")

Obviously the return statement of the append method should look like

return this;


Later I came across more interesting examples of this in the mock libraries like below.

Expect.Call(someObj.someMethod()).Return(anotherObject).Repeat().Once();

This time more than typing benefit what I liked about it is the readability of thecode. This is very close to the natural language translation of the above.
"Expect a method call someMethod on someObj. someMethod returns anotherObject. someMethod call is expected only once." Isn't that very close to how the code reads itself?

Look at this now.

"Create a new bug on build 45576 with description "this is really bugging ....".

new Bug("new one").onBuild(45576)

   .withDescription("this is really bugging")

   .WithPriority("medium").reportedBy("QA")

and this

 bug = new Bug("new one");

 bug.setDescription("....");

 bug.setBuild(45576)......

We can improve the readability by adding 'And', 'With', 'To' etc.

Below I have added a creational method and used 'and' method to improve the readability a bit more.

Bug.CreateWithTitle("new one").onBuild(45576)

  .withDescription("this is really bugging")

  .WithPriority("medium").reportedBy("QA").and().assignTo("a dev")...

Singleton Method Ruby vs Java

2007-12-14T04:16:00.000-08:00

I thought this was cool

// This was the closest i could get in java.

// still confused about the terminology 'SingletonMethod'
public class SingletonMethodJava {

    void theOnlyMethod(){
        System.out.println("theOnlyMethod");
    }

    public static void main(String[] args){

         new SingletonMethodJava(){
              void addedOneMoreMethod(){
                System.out.println("addedOneMoreMethod");
              }
         }.addedOneMoreMethod();
    }
}

But isn't this cooler ?


class SingletonMethodRuby

    def theOnlyMethod
        puts "theOnlyMethod";
    end
end

singleton_method = SingletonMethodRuby.new

def singleton_method.addedOneMoreMethod
 puts "addedOneMoreMethod";
end

singleton_method.addedOneMoreMethod

Redundancy of Language

2007-12-10T06:57:00.000-08:00

"Couple of boys are riding their bikes!"

How many words in the above sentence tell you the presence of more than one person?

Excel POI Wrapper in JRuby

2007-12-07T06:25:00.000-08:00

Disclaimer:This is one of my very first JRuby/Ruby programs.
Dont be surprised if I am writing Java/C# in JRuby.



require '../../poi-3.0.1-FINAL-20070705.jar'
include Java

include_class java.io.FileInputStream
include_class Java::org.apache.poi.hssf.usermodel.HSSFWorkbook
include_class Java::org.apache.poi.hssf.usermodel.HSSFSheet
include_class Java::org.apache.poi.hssf.usermodel.HSSFRow
include_class Java::org.apache.poi.hssf.usermodel.HSSFCell

class ExcelWorkBook
 
 def initialize(xlsFile)
  input = FileInputStream.new(xlsFile)
  @hssfworkbook = HSSFWorkbook.new(input)
 end
 
 def worksheet(sheet_position)
  ExcelWorkSheet.new(@hssfworkbook.getSheetAt(sheet_position),sheet_position)
 end

 class ExcelWorkSheet

  def initialize(hssfworksheet, sheet_position)
   @index = sheet_position
   @hssfworksheet = hssfworksheet
  end
  
  def row_at(rownumber)
   return Row.new(@hssfworksheet.getRow(rownumber))
  end
  
  def rows
   rows = []
   for row in @hssfworksheet.rowIterator
    rows << Row.new(row)
   end
   rows
  end

  class Row
   
   def initialize(hssfrow)
    @hssfrow = hssfrow
   end
   
   def value_at(columnindex)
   
    cell = @hssfrow.getCell(columnindex)
    
    if(cell == nil)
     ''
    elsif(HSSFCell::CELL_TYPE_NUMERIC == cell.getCellType())
     cell.getNumericCellValue()
     
    elsif(HSSFCell::CELL_TYPE_STRING == cell.getCellType())     
     cell.getRichStringCellValue()
    end
   
   end
  
  end

 end
end

Object Relations:Composition

2007-12-05T07:16:00.000-08:00

It took me a while before I could find a convincing real world example of composition. Thanks to civil engineering and Christopher Alexander; I got the enlightenment ;).

Yes it’s a Building and the Floors. The life time of a Floor is totally dependent on the Building. The Floor is constructed, used and demolished through the Building!

After finding the right example the next interesting challenge was, how to model the relation? Clearly Building and Floor are the two key objects in the problem and I designed them as separate public classes as follows.

public class Building {
private List floors;
……….
}

public class Floor {
private int level;
}

Functionally this model was fine and I was about to convince myself that the both Composition and Aggregation are same in the design and the difference is conceptual and existed only in the real world. However the lack of conceptual integrity in the model was bugging me for quite sometime before I realized that inner classes is the right way to go.

The following code (trivial) demonstrates how the lifetime of the Floor is tied to the building unlike in the previous model. Please excuse my coding conventions.

public class BuildingTest extends TestCase {
private static final int NO_OF_FLOORS = 5;

public void testFloorOrder(){
Building building = new Building(NO_OF_FLOORS);

Building.Floor previousFloor = null;

for(Building.Floor floor : building.Floors()){
if(null == previousFloor) {
previousFloor = floor;
continue;
}
Assert.assertEquals(true, previousFloor.isAtLowerLevelThan(floor));
previousFloor = floor;
}
}
}

public class Building {

private List<Floor> floors;

public Building(int numFloors) {
floors = new ArrayList<Floor>();

for (int level = 0; level < numFloors; level++)
floors.add(new Floor(level));
}

public int numberOfFloors() {
return floors.size();
}

public List<Floor> Floors() {
return floors;
}

public class Floor {
private int level;

private Floor(int level) {
this.level = level;
}

public boolean IsAtLowerLevelThan(Floor floor) {
return this.level <floor.level;
}
}
}