AmeyDhoke's blog

Rails best practices

2010-07-15T05:08:00.000-07:00

I am from Java/C# background and working on my first rails project. I heard in the beginning that rails has a specific style. Now, after spending few months with rails, I see that rails, like other MVC frameworks, has the same gotchas and similar best practices to address them.
I have observed few best practices that we follow on our project. Here is my attempt to consolidate them..

Fat Models and skinny controllers is one of the most talked about best practice in the rails world. It's aligned with the MVC philosophy of having minimum code in the controllers. Putting business logic in model makes the code easily testable and reusable. Apart from the render block, actions in the controllers should get, create or update the models and then invoke at most one method from the models. All other business logic should be pushed in models.

That being said, we should be careful that our models should not put on too much of fat. The User the model in my current project is 450 lines, and its spec is 1100 lines long ! This clearly indicates that the model is doing too many things. What can we do with such over fatty models ? There are multiple ways to handle this -
- First thing is to try to identify if it is possible to extract another model. However,it makes sense to do so only if some code clearly belongs to another model. Otherwise, we would be creating an extra model object which does not exists in the domain and we will end up confusing other devs.
- Extract out the a group of related functionality into mixins. This will make models little more maintainable and will also segregate the specs.
- User ActiveRecord::Observer to perform certain actions when model object is created or deleted. This is a great way to separate the code that isn't model's core responsibility.
  In my project, we want to send an email when new model is created. Sending email is not the model's responsibility so the code should not be in the model class. In such situations, its better to use Observers. Also, Observers can observe more than one models. One problem with this approach is that model class does not holds any reference of the Observer. So, by looking at the code in models, its not evident that an observer is observing this class.
- Make sure that the model does have the presentation logic. If the model has code which modifies/combines the model property for view, move that code to view helpers.
- Use concerned_with plugin which helps to move code into separate files. It allows to segregate the concerns in different files by opening the model class multiple times. Personally, I don't see it to be much different from extracting the code in modules.
Keep your views lightweight. Views should have only HTMLs and minimum rendering code. Move code from views to controllers if the code accesses the database, to model if the code has some business logic which belongs to a specific model and to view helpers if code is about modifying data to show it in specific format on UI. Make sure that views are not unknowing making database calls by accessing associations. Try to avoid putting css and javascript in erbs. They should go in separate files.
Use view helpers effectively. Views, models and controllers should not have presentation logic. Moving the presentation logic to view helpers makes it easily testable.
In modules, avoid accessing instance variables of including class. If the module is included in controller, avoid reference to params hash. Instead of using the instance variables or methods from the class, pass the required data to methods. This reduced coupling between the class and included modules, makes module code reusable and easy to test.
If you are using activerecord finder with same condition in multiple places, move them to model and use named_scope. Named scopes allows you to give a descriptive name to the finder. You can also chain multiple named_scopes together. Move all the activerecord finders from controller to models.
Understand available callbacks on ActiveRecord controller. Consider using activerecord observers.
If you have a common code across multiple actions in a controller, extract out that code in filters. Use before_filter, around_filter and after_filter to keep your controllers DRY.
Ideally, Controller should have only action methods. If you have any method in controller, which is not an action, see if you can move this method to model or to view helper.
Instead of creating the model and then building it from params in controller, pass the hash to the initialize in models. Instead of having any conditional logic in controllers, move it downstream in models or services.
Understand REST principles. Create controller for identifiable resource/domain entity. Do not do update database in index/show action of controller. Use right HTTP methods.
Consider creating service classes to represent operation which does not have state. e.g. The code which talks to some external service can go in a service class.
And most importantly, write tests for all your code !

Loading a readonly ActiveRecord object

2010-06-21T08:54:00.000-07:00

I am working on a story, with my pair Jaju, which generates reports from database. The database has questions and answers. We want to generate report with all questions and answers in specific range. All we wanted to do is to load some data in readonly mode and had no intentions of updating the database. It turned out to be not that straightforward though.

The Question model has :has_many answers and Answer model :belongs_to question.

To begin with, the simplest thing to do is -

questions = Question.all(:include => :answers , :conditions => ["answer.created_date > ?", Date.today.to_formatted_s(:db)])

All well and good. One query which joins question and answer table is fired and we get questions with answers created after yesterday. But now, there is a new problem - our BA (Business Analyst) says - "Hey, This is not what I want. I want all the questions in the report, only the answers should get filtered if they are not created after given date. So even if question doesn't have answer in the given time range, I need the question in the report without the answer."

Ohh..the code that we have written, filters the questions if they do not have answers created after given date, but we can change it. Here is the next version of the code.

1| results = Question.all(:include => :answers)
2| results.each { |question|
3|   question.answers = question.answers.select { |answer|
4|       answer.created_date > Time.parse(Date.today.to_formatted_s(:db))
5|   }
6| }

Alright ! This is exactly what we want. We get all the questions, with answers created after Date.today. But wait, the test log has following query -

UPDATE `answer` SET question_id = NULL WHERE (question_id = 1747 AND answer_id IN (1099))

Damn !! Active record is setting question_id to null in answer table. This is dangerous !

We realised that this is happening because we are filtering the answers in the question object and reassigning it to question.answers (line 3 in the above code). question.answer is an object of AssociationProxy and when we reassign question.answer on line 3, it updates that in database.

We tried to find out whether we can load the complete active record object in the readonly mode. This can be done by -

results = Question.all(:include => :answers, :readonly => true)

But this doesn't fix the issue. It still updates the answer table. The :readonly flag is only applicable to the parent object. So any changes on the question object will not be persisted. However, changes in question.answers are still reflected in database.

The root of the problem is that we are assigning something to an association proxy object. So we need to avoid that part.
While looking at the activerecord code, we realised that activerecord maintains a hash of all the attributes and it is possible to add a new attribute to the hash (thanks to my pair). So we changed the code like below.

1| results = Question.all(:include => :answers)
2| results.each { |question|
3|   question["filtered_answers"] = question.answers.select { |answer|
4|       answer.created_date > Time.parse(Date.today.to_formatted_s(:db))
5|   }
6| }

So rather than changing the association proxy object, we are adding a new entry in the hash. Obviously now it does not update the database as well. Once I use the above code, I can refer to filtered questions as 'question.filtered_answers'

This is the work around that we used because we couldn't figure out a way to load the complete activerecord object hierarchy in readonly mode or 'detach' the activerecord object from session. But anyway, our code works and we got want we want without unnecessary database updates.

Public defender methods - yet another Java 7 proposal

2010-06-17T07:41:00.000-07:00

Support of lambdas and closures is the most important language feature that is proposed to ship with Java 7. With lambdas, it will be possible to implement some interesting methods into the old collection classes. Methods like find, select, reject, forEach, include can take a lambda and perform relevant operations on the collection object. However, adding these methods into existing collection interfaces would be a problem as it will break the existing implementations. To address this issue, the proposal of defender method is suggested.

Inherently static nature of Java restricts the developer from extending the functionality without affecting the existing usages. The current implementation of interfaces doesn't allow us to add a new method to interface without breaking all its implementation. Sometimes, there is a strong case for adding new behaviour in the interface so that its applicable to all the implementations. Currently the only way to do this is to change interface into an abstract class and change the code to extend this abstract class. However, we need to change at all the places where this interface is implemented and anyway, this change is not always possible because a class might already have a superclass. The proposal of public defender method suggests a solution.

This proposal allows to provide a default implementation for interface methods. This default implementation will be a static method on helper class and it will be invoked if the class implementing this interface does not provide any custom implementation.

The proposed syntax is -

public interface List {
extension public List select(#boolean(Object)) default ListHelper.select
// other list methods
}

Here, select method from the List interface takes a lambda (which is again a proposal) as argument. The 'extension' keyword signifies an extension method. It must have a default implementation which is provided by static select method from ListHelper class. This method has the same signature as the extension method and it will receive the the extended interface object (list) as the first argument. If the class implementing this List interface does not provide implementation, the select method from the ListHelper class will be used. This method from the helper class which provides the default implementation is called as public defender method, as it defends the classes that does not implement extension method.

Obviously, the specific implementations of the interface class can provide an optimised implementation for extension method.

As mentioned in the Baptiste Wicht's blog, with this approach, it is possible to include the static methods in Collections class to the List interface. This will allow us to invoke methods like reverse() on the list object itself, rather than passing the object to the static method in Collections class. Also, it will allow us to override these methods.

In general, this proposal will allow us to add the relevant methods to interfaces and be dependant on the classes with static utility methods.
so we will be able to do -

list.select(..)

instead of

ListHelper.select(list, ..)

The helper class will still hold the implementation, but objects need not be aware of them.

Along with the ability to extend the already existing interfaces, this proposal will have more profound effect on the programming style. It will be possible to create a interface in which, all the methods are extension methods with default implementation. Then, it will be possible to use this interface as 'mixin' and use it to achieve the effect of multiple inheritence. Also, abstract classes may not be required as the same functionality can be achieved by interfaces with few defender methods.

We can compare this proposal with the extension methods introduced in C# 3.0. Although not exactly same, conceptually both are same. C# extension methods allows us to add methods in the existing classes by defining the static methods in another static class. However, The visibility of C# extension methods is much more controller as the these methods are available only in the classes that import the static class with extension method. This is different from defender methods where extension methods will be available to all the implementations of the interface.

At the moment, defender methods is only a proposal for Java 7 and just like other proposals, we are not whether it will come up with Java 7. but nevertheless, this interesting language feature will improve the extendibility of dying Java language and will allow us to extend the existing library.

Spring AOP : Avoide JDK proxies for struts application

2009-09-24T06:23:00.000-07:00

Spring AOP uses both JDK proxies and cglib for creating dynamic proxies. The main purpose of proxy classes is to intercept method invocation on the target object and the execute the code from applicable advice. If the class implements an interface, then spring uses JDK proxies by default, and for all other classes it uses cglib to generate proxies.

Proxy classes generated by JDK proxy provides implementation for all methods in all the interfaces that are implemented by target class. So, generated class will not have methods that are defined by target class but are not part of any interface. All the implementations of the interface can use the same generated class which results in less number of dynamically generated proxy classes.
On the other hand, proxies generated by cglib extends the target class. So the generated proxy has all the methods defined by the class. This results in more number of proxy classes as every class, even different implementation of the same interface, will have their own dynamically generated proxy. However, the generated proxy classes are cached, so new classes are not created on every invocation.

In a web application which uses Struts, its not possible to use JDK proxies for Spring AOP. Consider the following scenario.

I have an action class -

package com.amey.labs.web.action;
//imports

public class HomeAction implements ModelDriven {

private String name;
private PersonService personService;
private HomePage homePage = new HomePage();

public HomeAction() {
}

public HomeAction(PersonService personService) {
this.personService = personService;
}

@Action(value = "/home", results = {@Result(name = SUCCESS, location="home.jsp")})
public String execute() {
homePage.setPerson(personService.getDetails(name));
return SUCCESS;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public HomePage getModel() {
return homePage;
}
}

I have configured an around advice for this action to log the entry and exit of the execute method.

<aop:config>
<aop:aspect ref="loggerAspect">
<aop:around method="doLogging" pointcut="execution(public * com.amey.labs.web.action..*.execute(..))">
</aop:around>
</aop:aspect>

HomeAction implements ModelDriven interface. So Spring will use JDK proxies to create a proxy class. The created proxy class will implement all the methods from ModelDriven interface. However, it won't have execute() method as it is not defined in ModelDriven interface. If I try to execute this action, I get NoSuchMethodException exception in AnnotationValidationInterceptor. This interceptor gets the method name which has @action annotation and then get the method object with the same name from action's Class object. However, the Class object is a object of proxy class generated by JDK proxy instead of the actual action class. So it does not have execute() method.

To fix this issue, I have to implement the com.opensymphony.xwork2.Action interface (or extend the ActionSupport). Once i do this, the created proxy class implements Action interface and has the execute() method.

Now, when I invoke the action from the UI, it can execute the execute() in the action. However, the generated proxy class doesn't have the methods for setting individual attributes in the action class (name in HomePageAction). So there is no way that the ParameterInterceptor finds out that this name-value passed in the request (either GET or POST) is actually a attribute on action and it just ignores that. CompoundRootAccessor class, which is invoked from ParameterInterceptor generates the warning message that the setter for "name" is not present in Action class or the model class and it is logged if the struts is running in dev mode, otherwise the parameters is considered as junk and it is ignored.

So the action class can not have any attribute which should be set from the UI. I need to move the name attribute from action to the Model class. If attribute is part of model, then it gets populated properly and I can use it in my action. However, attribute can not always be a logical part of the model object.

To force Spring to use cglib proxies, we just have to set proxy-target-class attribute to true.

<aop:config class="true">
// aop aspects
</aop:config>

In the struts actions where we have a property that we want to set from the UI, JDK proxies can not be used. So we have to use proxies generated by cglib. Even in other cases, cglib proxies performs better than JDK proxies. With JDK proxies, proxy class intercepts all the method invocations on the target object. All methods on target object are invoked by reflection, even if they are not advised. With cglib, proxy classes extends the target class and intercepts only advised methods. All other methods are invoked directly. So, using cglib proxies is considerably faster. Obviously, cglib has its own set of problems, but its a better alternative than JDK proxies.

Do you really want moist test ?

2009-05-05T06:38:00.000-07:00

Moist tests are the test cases that do not follow DRY(Don't repeat yourself) principle. According to this philosophy, the setup and any other private method in the test class is a smell. It advocates that having all the test code in test method itself, improves readability and makes it easy to maintain. I recently joined a project team which follows this concept, and it was pretty surprising for me.

The test acts as a documentation for the object it tests. If i have to understand the job of a class, I will go to the test and read test methods. And thanks to the concept of moist test, I end up reading 5 lines of code duplicated in all the tests which creates object of system under test, creates mock objects, set expectations, inject dependency and do other setup stuff. So reader has to skip a chunk of code to get to the crux of the test. This is definitely not improving the readability of test.

The readability and maintainability of the test is more important than deciding whether to be moist or DRY in your tests. I agree that we should not be obsessive about strictly adhering to DRY in the test code, but in the same way, we should not be intentionally 'wet' and duplicate the code everywhere.

Lets look at the reasons people gives to write 'Moist' tests. I have taken most of the reasons from the Jay field's and Shane Harvie's post.

- When a test fails, I want to fix it quickly
How will duplicating the code in all test methods will allow you to fix the code quickly ? Suppose you add one more parameter to the constructor of your object, changing it in at one place in setup method will be much quicker than changing it in every test method.

Obviously, if you want to initialize your object differently, you have to instantiate it in your test method. But that's a special case, may be one of the ten test methods will need a different object and that method will instantiate it. Other methods in the test class will continue using the object that is instantiated in the setup method. If all the test methods needs different objects, then you don't need instance variable at all and all the test will have their own local variable. By doing so, you are breaking DRY principle, but it is necessary to make sure that your test is not forced to execute unnecessary code from setup method.

- I have to search around a large test class for extracted methods, or instance variables that may be modified throughout the class, this costs me time
Why would you have a large test class ? You will have a large test class only if the object your testing has multiple jobs and you have to test all that behavior. If you follow the Single responsibility principle and write classes that has only one job, you will have only one behavior to test (with alternate flows) and you will end up with small test classes.
So, if you have large class, its a smell that your object is doing too many things. You need to fix that first by segregate the responsibility into separate classes. Once you move the responsibilities to the different classes, you have to move the tests to separate test classes as well and you will end up with small test class.If doing so is impossible for some reason, you could extract test cases into separate files each testing a part of object's behavior.

Still even if your test class is large, I do not understand how searching for a method will take much time.(In most of the IDEs, you just have to do Ctrl+B(or other similar shortcut) to go to the method definition). The purpose of extracting methods is not only to group a block of code together, the more important purpose is to create abstraction. By giving descriptive method name to the extracted method and using that method in your test, you are creating an abstraction over a block of code and thereby increasing the readability of the test.

In few test, instance variable that is initialized in setup method will be modified by the test. However, this should not affect other tests. Ideally, you will create the instance of system-under-test (the object which you are testing) in the setup method and then use it in your test. The changes made by other objects to the instance variable will not affect your test as object is getting initialized in setup method for every test.

- Some developers don't know that setup method is getting executed/ they may not notice that setup method exists in test
This is probably the most lame excuse. Even a developer who learned JUnit today will know that the setup method gets executed before every test. And if your developer don't have this basic understanding, you should stop writing any code and educate them first. Their ignorance can't be the reason why you don't want to have setup methods in test class.

- Separating the test code in setup and test method decreases readability
Writing the code in setup method will reduce the readability only if you are not using the setup method properly. i.e. if we have any test specific code in setup method. However, if we have test environment setup code in setup and test and assertion code in test method, then it follows the natural flow of the test and should increase the readability. Though it depends on the reader as well. If the person is used to reading the code with small modular methods,reading the tests with setup methods should come naturally for him.

- Tests should be independent, so why should all of them use common setup (or any other common) method ?
When we say that tests should be independent, it doesn't mean that they should be lexically separate. It means that we should be able to run tests individually and the outcome of one test should not impact other tests. The setup method is executed before every test, so the objects are initialized freshly for every test. If setup method is too big and it contains some code that is not required for all the tests, then you have to extract the test specific code in your test method or write private methods.

- If you have to write large code to setup your test, you have to rethink about your object model instead of putting all the code in setup method
This is definitely true. Big setup code is a smell that your class has too many dependencies. In this case, we should definitely try to minimize it by breaking the class into different classes. But duplicating the chunk of code in all the tests is not the solution.

The ultimate core aim is the readability of test. Readability of the test is more important than applying DRY(this holds almost true for production code as well). We should not apply DRY principle stringently for test code. But it doesn't mean that we should go entirely other way round, write duplicate code and make our test moist purposefully.

IMHO, test method should have the code to invoke the method to test and do the state/behavior verification. It may also have code to set the expectations on the mock objects. The code for initializing the system-under-test (probably by injecting some mock objects) should go in the setup, which is the right place for it. Obviously, if all the test methods needs different setup, then the common setup method doesn't make sense and we have to duplicate some code in test methods. If you notice that changes are required in the common extracted methods and the changes are affecting other test, its time to get rid of extracted method and copy the code in all tests. So, you may end up with a test method which has all the code for setup, test and assertion. Its OK to violate DRY principle in your test code if it is required but this should be an exception. Naturally, we should try to keep our tests DRY and introduce 'moistness' only if required. We shouldn't intentionally make it 'wet' by duplicating the code everywhere.

Using field level access for hibernate entities

2009-04-22T06:35:00.000-07:00

Hibernate allows you to configure the access mechanism for attributes in the entity object. It can access the attributes directly or through the accessors. The field or property access type is decided by hibernate based on the location of @Id or @EmbeddedId.

@Entity
public class Item {
@Id
public String id;
public long itemNumber;
}

@Entity
public class FoodItem {
private String id;
private long foodId;

@Id
public String getId(){
return id;
}
public long getFoodId(){
return foodId;
}
}

In the above code, Item class uses field access and FoodItem class uses property access.

Using property access mechanism allows classes to hide the internal data structure from the external world and it enables class to perform validations while setting the value or while accessing it. It is useful when we want to perform some calculation before returning the result or setting the value.

However, mostly we end up directly accessing the variable from the getter and setter methods. In that case, property access is overkill. It makes us write lot of getter - setters which are not used anywhere else in the code. It also exposes setters if when we don't want anyone to set the value of fields like 'id'. We can mark the accessors private or protected and avoid this problem, but we will still have the code.

IMHO, while creating the entity, we should start with field level access. Doing so will reduce the unnecessary code which is used only by hibernate. We should keep the fields private and provide accessor methods only when required. So our entity object will be modeled by the needs of the application and not by the hibernate. In future, if we need to validate or manipulate the values set on the object (which mostly won't happen), we can then switch to property access, but we shouldn't start with it.

Adding static @BeforeClass method in the test class

2009-04-22T03:54:00.000-07:00

I was looking at a integration test in project that takes 10 seconds to execute. Its a integration test in a for a class that connects to the FTP server and performs some operations. The test uses a in-memory mock ftp server. The issue is that it starts, initializes the mock file system for every test and then stops the server after each test. The initialization code is written as a part of @Before method and server is stopped in @After method. The fact that the server was getting started and closed for every test was the reason why test was so slow. I want to start and initialize it only once for the all the tests my my class. The way to achieve this is to use @BeforeClass annotation. The method marked with @BeforeClass runs only once for all the test. The corresponding tear down method is @AfterClass. By using @BeforeClass instead of @Before and with some other changes, I was able to reduce the time required to run the test to 3 seconds.

However, using @BeforeClass instead of @Before may make tests dependent on each other and on the order of execution. As all the tests will use the same objects, changes made by one test will be affecting others. So @BeforeClass method should be used to initialize objects which are not modified by the tests. The methods should be used to setup the environment for the test and not for creating the objects that will be directly consumed by the tests.

@BeforeClass (and @AfterClass) method has to be static, which means all the variables that are accessed in this method has to be maked as static. This puts up restrictions on the ways in which @BeforeClass can be used, but this makes it explicit that the @BeforeClass method should be used to set only the environment for the test and objects under test itself.

Improved modularity with Superpackages in Java7

2009-04-07T07:30:00.000-07:00

JSR 294 talks about introducing improved modularity support with Superpackages.
Right now modularity is supported at various levels in Java language. Modularity provides encapsulation and information hiding at various levels. Method encapsulates certain program logic and local variables. Class encapsulates instance variables and methods and a package provides a module to group related classes. All these modules helps us to understand and change the system locally, within the module space without worrying about its effect outside the module.

However, the modularity supported by packages is inefficient in some cases. The problem is that packages supports hierarchy, file system also stores classes in the hierarchy, but the accessing member of the package is not hierarchical. There is no special relationship between packages and their children or parents. We create packages like com.domain and com.domain.validators. Clearly, there is some kind of hierarchical relationship between the classes in two packages. You may want to access some classes or methods of com.domain from com.domain.validators package, but you don't want to expose them to the whole world by making them public. The scenario is very well explained by Neal Grafter at http://www.infoq.com/interviews/gafter-closures-language-features-optional-typing. Currently, there is no way to achieve this directly.

We can use default member access so that it becomes public within the same package, but stays inaccessible to the outside world. Classes in the subpackages also can not access it. So we end up putting classes in the same package as we want to access members with the default access. This leads to packages with large number of classes, the classes which should ideally go in the sub packages.

The other option is to make the members public. Doing this may expose unwanted API. We will end up relying on the official documentation of the API and prays that no one comes to know about the class and invoke its 'public' method. The issue is public is too public.

We need a module entity that is bigger than a package but narrower than public. The solution is to introduce one more level of modularity called Superpackages. Superpackages contains classes from one or more packages or superpackages. Its a new construct which is put into super-package.java file and compiled by the Java compiler. The types can be exposed to the outside world by exporting them. Only the exported types are visible outside the superpackage. Public types that are not exported can not be accessed outside of superpackage.
e.g. A superpackage which encapsulates types in com.domain and com.domain.validators is defined as -

superpackage domain {
// member packages
member package com.domain;
member package com.domain.validators;

// exported types
export com.domain.*;
}

Here, only classes from com.domain package is visible outside superpackage, classes from com.domain.validators are not.Note that Java classes doesn't specify the superpackage they belongs to. It is specified in the super-package.java file only.
Superpackages can encapsulate other superpackages as well. Only the public types in exported superpackage will be accessible from outside.

Superpackages is coming up with Java 7 and going to be an effective mechanism for information hiding in Java.

Java 7:Multiple exception catch block

2009-03-25T10:25:00.000-07:00

Java 7 proposes a new syntax for catching multiple exceptions in a single catch block (http://www.javac.info/Multicatch.html). It looks like a neat feature to have and the new syntax is definately better than having multiple catch blocks with the same exception handling code.
So instead of -

try{
// Some code that throws ServiceException and WebsiteException
}
catch(ServiceException exception) {
Logger.Log(exception);
throw ApplicationException(exception);
}
catch(WebsiteException exception){
Logger.Log(exception);
throw ApplicationException(exception);
}

we will be able to write -

try{
// Some code that throws ServiceException and WebsiteException
}
catch(WebsiteException | ServiceException exception) {
Logger.Log(exception);
throw ApplicationException(exception);
}

So, we will be able to get rid of duplicate exception handling code and will make our code little simpler. Its a pretty obvious change and ideally it should have been identified and fixed before.

This new feature is useful, but how much ? I think this is trying to solve the problem that should not exist. In most of the cases, you should not be throwing more than one checked exception.It will happen if we are exposing the implementation of method and rethrowing the exceptions from called methods.
Even if we have more than one exceptions, we may want to handle them in different ways. So we can not combine multiple catch blocks.
Apart from that, whole lot people in java devs community, including me, believes that checked exceptions should not be used at all. Checked exceptions forces developer to write the exception handling code even when it is not required. Exception handling code gets mixed up with the business logic. This leads to cluttered and unreadable code. Worst part is that checked exceptions create dependency between a method that throws exception and all other methods that directly or indirectly calls that. It makes caller of the method depends on the implementation details of the method. And after coding in C# (which doesn't have checked exceptions) for 2 years, i doubt whether checked exceptions are required in language at all.
Looks like this is nice to have but not so useful (lame?) features in Java 7.

Following SRP on grounds

2009-03-24T05:01:00.000-07:00

Single responsibility principle is probably the simplest OO coding principle. It says "A class should have only one responsibility and thereby, only one reason to change." Isn't it very straightforward ?
But when I look at the code of my application, I see that very few classes in my app follows this principles. Why is that ? The principle is very simple and so it should be simple to implement as well. Its relatively easy to make sure that our class doesn't have any method that doesn't belong to the job of class. I think the difficult part is to know when we are adding additional responsibilities to the class. We do incremental development, start with only what is required and then add up behavior in methods and methods to class as required by the failing test. During this process, we somehow manage to sneak in the logic that is not the part of class's responsibility.
For example, we have mapper classes in our code which maps domain object to data contracts. The job of mapper classes is just to copy the fields from domain objects to contact. The mapper should only do this job of mapping. Consider the following example. In this, Booking object is loaded from the database. This class will map Booking to BookingData object.

public class BookingMapper{

public BookingData Map(Booking booking)
{
BookingData bookingData = new BookingData();
bookingData. Id = booking.Id;
// Other fields
bookingData.BookingFee = CalculateBookingFee (booking.StationCode, booking.TotalCost);

return bookingData;
}

private decimal CalculateBookingFee (StationCode stationCode, decimal totalCost){
// some complex logic to calculate booking fee based on station code and total cost,
// may be, the method will read some values from database.
}
}

The class BookingMapper has only one Map() method. From outside the class, it looks like the class has only one responsibility. However, apart from mapping the data, the class is also calculating the booking fee. It has 2 jobs - to map the data and to calculate the value of booking fee.

The mapper class should do only mapping and we have to move the responsibility of calculating booking fee to other class. If the fee calculation depends only on data present in booking object (like station code and total cost), then the obvious place for CalculateBookingFee method is Booking class itself. We can have a read-only property on Booking class called BookingFee which will calculate the fee.If the calculation of fee involves reading the values from database and/or from some other service, then we don't want our domain object to access services or database. In this case, we can calculate the booking fee (and any other required values) before invoking the mapper and pass it to Map() method. Either way, the fee calculation logic will move out of BookingMapper.

Using extension methods

2009-03-22T10:35:00.000-07:00

How many times you have seen your project having a StringUtils or a similar Helper class ? Most of the helper and util classes has pure procedural code. e.g StringUtils may contain a method IsNumaricString() or ToTitleCase( ) which takes a string as parameter.
Ideally all these methods should go in String class itself but we cann't extend String class as it is sealed. However, with the extension methods in C# 3.0, we can 'open' the classes and add methods to it.

So, instead of
string name = StringUtil.ToTitleCase("foo bar");
we can say -
"foo bar".ToTitleCase()

The extension method is defined as -

public static class StringX {
public static string ToTitleCase(this string str)
{
return string.IsNullOrEmpty(str) ? string.Empty : Thread.CurrentThread.CurrentCulture.TextInfo.ToTitleCase(str.ToLower());
}
}

The extension method is defined as a static method, in a static class. The first argument to the method is the type which we went to extend, preceded with 'this' modifier. When we call the extension method, we don't need to specify this first argument.
Isn't it neat ? The example I have used is the simplest one. There are many other cases when you can extend the functionality of the .Net system classes. Like, we can add Serialize() as the extension method in the Object class.

When I first came across this feature, I thought its the way to open classes in Ruby style. But well, its not exactly the same.
In extension method, we cann't access the private (or protected) members of the class that the method extends. We cann't use extension methods to override a method in the class.
The method defined in the actual type has precedence over the extension methods.So there is no way you can change the behavior of existing method with extension method.

One more good thing with extension methods is that they are available only on classes which refers to them. We need to import the classes that contains the extension methods.

The compiler translates the extension method call to the call on static method. So, its just a syntactic sugar to make your code look better. You cann't do 'effective' monkey patching with it as you cann't shadow a method defined in the actual type, neither you can access (and change the value of) any private member of the object.

However, we shouldn't use the extension methods haphazardly for extending the class behavior. Its definitely not the alternative for subclassing.

The MSDN says to use extension methods seriously and only when we have to. Well, my take is to use extension methods when its appropriate.
We can use it when its not possible or not appropriate to extend the class .e.g if we are using some class from the third party code.
Another best place to use extension methods is when you want to add a functionality to your data contract. Consider a scenario where you are getting a Booking object from some service. You want to check if the booking is valid based on some properties of the object. So your code will be something like this...

if(booking.BookingDate > DateTime.Now && booking.NumberofPassengers > 0 && booking.BookingCost > 1)
// then booking is valid

Here, we are accessing properties from the booking object to decide if the booking is valid. This is clear violation of "Tell, Don't Ask" principle (http://c2.com/cgi/wiki?TellDontAsk). The
best place for this logic is Booking class itself. But Booking is a data contract and we cann't add methods to it.So we can add an extension method IsValid() in a static class called
BookingX.

public static bool IsValid(this Booking booking){
return booking.BookingDate > DateTime.Now && booking.NumberofPassengers > 0 && booking.BookingCost > 1;
}

Now, by importing the BookingX class, instead of all the above code, we can say -
booking.IsValid()

So, extension methods helps you to keep the behavior in the correct class.

Delegates in C#

2008-06-05T01:32:00.000-07:00

Delegate is a type in C# that references a block of code. This block of code can be named or anonymous method or lambdas (in C# 3.0). They are like function pointers in C++. Though they are not purely function pointers as they are 'type safe'. Return value and parameters of code block are defined in the delegate declaration.

e.g. public delegate void Print(string message);

This delegate is named as execute which can refer to any method (or code block) which will take one string argument and returns void.

Delegates allows us to use a block of code as data object. As delegate is just a data type like others, it can be passed around to methods and called whenever required. They be default extends System.MulticastDelegate, which means a delegate can refer to more than one methods or code blocks.

Delegate objects can refer to both static and instance methods. Also, Delegates can refer to anonymous methods as follows.

public delegate void Print(string message);

Print print = delegate(string message){
Console.writeline("Message : " + message);
}

In C# 3.0, the same can be written much cleanly using lambdas as -

public delegate void Print(string message);
Print print = message => Console.writeline("Message : " + message);

C# Delegates which uses anonymous methods and lambdas are essentially closures. However, they are not exactly same as closures in pure functional languages like ML. Anonymous methods or lambdas do not capture the variable values when they are definied. The variables used in the anonymous methods are used in the moved to heap and shared between anonymous methods and outer scope. The value of outer variables are modified if they are changed by the delegate. So the changes made by the delegate in the lexical environment propogates back to parent scope.

Delegates with anonymous methods and lambdas are not 'true' closures if we consider the closures in pure functional languages like ML as the lexical environment of delegate is not closed and changes made by delegate are visible in the outer scope. But there are ways to get around this. In C#, we have a name-variable binding instead of name-value binding(which is used in pure functional languages where variables are immutable).

Behavior Driven Development

2008-01-15T08:21:00.000-08:00

I was looking at RSpec(http://rspec.info/) as I want to use it in a open source project. The definition of RSpec says that its a Behavior Driven Development framework for Ruby. As a TDD practitioner, I have been writing tests using xUnit frameworks. This will be my first experience with BDD frameworks. But how BDD differs from TDD ?

In test driven development we write tests before we code. However, testing the code and application is not the sole purpose of writing tests.TDD is not only about writing tests. Its about writing specifications for individual piece of code in form of tests, which should (ideally) lead to better design. So TDD is about specifying requirements and design and not only testing. BDD makes this fact explicit. It uses proper vocabulary and has emphasis on using the proper words (e.g. specification instead of tests). BDD gives more emphasis on coming up with the behaviour and specification rather than tests.

BDD is not a radically new way of thinking (like TDD is). Its just a improvement, a next step in TDD thinking. It combines the aspects of Domain Driven Design with TDD. It defers from TDD in a sense that we specify behaviour of the application rather than testing its implementation.However, just like TDD, we should do it in small steps, writing down the specification for small part of app before the part is implemented.

BDD uses Ubiquitous language - language which is equally understood by developers and users. Rspec, which a Behavior Driven Development framework for Ruby, allows us to define specifications in language such as "should add two numbers" or "should have score greater than 50". This kind of specification is more intuitive than unit tests.

So in short, BDD frameworks allows us to write executable specification and acceptance criteria. However, I still have some questions like - Can we do BDD with xUnit frameworks which are defined for TDD ? Do we still need unit tests to test the application at granular level or we should use BDD framework for that purpose? Hopefully, answers to these questions will be clear once I become more familiar to BDD style.

On the way of Learning RESTful way

2008-01-14T22:55:00.000-08:00

REST, which stands for Representational State Transfer is an architectural style of developing the web services. I first came across this term when I attended the Sriram Narayan's (a fellow thoughtworker) presentation. I was quite impressed with the concept and was planning to read about it in detail since long. When I started reading, I came across XML-RPC and SOAP which are other protocols used to communicate between two web services across network. As usual, I was not aware of them and searched to see exactly what they are. In short, this is what I found.

# XML-RPC : As it's name suggests, its a remote procedure call protocol which allows applications running on different machines (or different platforms) to communicate through remote procedure calls. It uses xml as message format and uses http as transport mechanism. The format of messages in XML_RPC is very simple and contains minimal data types. In fact, simplicity is the goal of XML-RPC.

# SOAP : SOAP stands for Simple Object access protocol which is a protocol for communicating across computer network using xml messages. It is successor of XML-RPC protocol.Its mostly used for communication between web services.
The advantage of SOAP is that it uses xml for communication which can communicate with different platforms and different applications.
However, as its uses xml, it can be slower as serialization, deserialization is required, which is a expensive operation. Also, the xml structure of message can be very complex and verbose. The other problem is that it uses http, which is a application protocol, as transport protocol.

Equipped with this basic knowledge, now I am in better position to read about REST..

Playing with svn delete and svn status

2008-01-10T05:08:00.000-08:00

I was playing around with svn recently while working on story related to svn delete. We are doing a physical delete of a folder in code and then svn delete from powershell script. But somehow svn delete doesn't work and the deleted folder comes back again on svn update.

I found out that if we delete the folder (or file) physically from the file system and then do a svn delete for that folder, it doesn't get deleted from the svn and comes back on svn update and this was the cause of my problem. However, if we do svn delete directly, the folder gets deleted properly and doesnt come back on next update. Obviously, the folder comes back on svn revert as we haven't committed yet.

I tried to figure out if I can do something else rather changing the code to do svn delete. I tried to do svn commit in the script after doing svn delete. However, commit also commits other changes apart from deletions. When I tried to do commit by specifing folder name like -

svn commit $matches["file"] -m $comment

then it gives error -

svn: Commit failed (details follow):
svn: Entry for 'C:/foo' has no URL

This is not unexpected. This happens because the folder is not present in the given path
as it is already deleted. So, I was not able to do commit just for the deletion.

Finally, we changed the code to do the svn delete at first place rather than doing physical delete. :-)

I noticed that svn status also behaves little strangly. svn stat (svn status) is supposed to give 'D' for the deleted files/folders and '!' for the files that are missing i.e. deleted without svn in the first column of status message. This works fine in most cases.

Consider this scenario- if you physically delete a folder with svn, status gives '!'. If you restore the folder and do svn delete on the same folder, it gives D in the status, which is exactly as expected.
Now, if you revert the folder and do the physical delete, you will expect that svn stat will give '!' as usual, but this time, svn status gives 'D' !

It seems that the svn remembers that delete was invoked on the folder and gives D even if it's a file system delete. And now onwards, the svn will keep on giving 'D' in the status for that folder even if you do physical delete or svn delete. This behaviour caused some confusion. Is it a svn bug ?

The Object Oriented way

2007-12-30T00:35:00.000-08:00

At Thoughtworks, anyone who apply for the position of developer, need to submit code for a problem. I don't take part much actively in recruitment, just because yet i am not good enough for it. But still, I sometime get a chance to look at code written by people who have significant years of experience. And surprisingly, I found that
most of the time, the code written by these techie and experienced guys is pathetic. I know I am not a very good OO programmer, but I think, most of the code I saw was not OO at all. It was just a procedural code written in language like Java, C++ that supports OO.

My present project has a legacy code written in C#, which is one of the prominent OO languages. But I can bet that the legacy code in my project can be an ideal example of how to write procedural code in a OO language. It has all the problems that a typical large procedural program will have. Is witting a good (or not so good) OO program difficult ?

Most important thing that is missing is Object oriented way of thinking about problem at hand. OOP needs a way of thinking that is entirely different from procedural way.

In simple words, procedural programming says that program or a software system is a set of instructions and procedures. In procedural programming, when we have a problem to solve, we think about the procedure to solve it and then write that procedure down in form of function/method. Now the data is provided to this function, it operates on it and provides result.
Here, data is put into separate structures and there is no binding between data and functions.

In Object oriented world, a program or system is made up of collection of interacting objects. Every object has its own attributes and certain behaviour and responsibility.In OO way, when we have problem to solve, we think about objects that plays role in problem and the responsibility of each object, rather than thinking about the procedure to solve problem. The objects interacts with each other by sending messages (calling methods) to each other. Then We write classes that has data and behaviour binded together and the objects of classes interacts to solve the problem. So the entire way of thinking in OOP is different than procedural programming.

The concepts of OOP resembles to real world. In our world, everything is object with attributes and certain behaviour. e.g. consider a dog. It has attributes like color, size, height etc. and it has behaviour like walk, eat, bark etc. These attributes and behaviour are not separate, they are the part of a Dog itself. When we perform any action, a set of objects interacts with each other.

The main features of OOP like encapsulation, polymorphism and abstraction can be easily seen in the real world also. Consider a break of car. The break has certain attributes and behaviour. It is encapsulated within the assembly of break. The internal details of how the break operates is not visible to the user. User just preform the action of pressing the breaks and break perform the action of stopping the car. How break achieves this is abstracted from user. The mechanism break applies to stop the car is private to the break and external world, including user need not know about it i.e. the internal implementation is abstracted from user.

Lets get back to the original question, Is OOP difficult ? I guess, its not difficult and certainly different than procedural way and we need a entirely different way of thinking. Just by using a language like C++, Java or C# that supports OOP doesn't makes our code OO. OO way of thinking is must for witting good OO programs !

Using cflow() and cflowbelow() in pointcuts

2007-12-29T04:28:00.001-08:00

Control flow is just the flow of execution of program within specific join point. cflow() and cflowbelow() constructs takes another join point as argument and allow us to define control flow based pointcuts - the pointcuts that captures all the join points in the control flow of specified join point.

cflow() captures all the join points e.g. call, execution, set and get field, error handlers in the control flow of join point specified as argument along with the specified join point itself.
cflowbelow() behaves same as cflow, however it doesnt captues the join point specified as argument, but captures all other join points that comes below that.

For example, Consider a class -

public class Test{
private int value;

private void method(){
value = 10;
}

public static void main(String[] args) {
new Test().method();
System.out.println("Exiting Test.main()");
}
}

And an aspect -

public aspect ControlTestAspect {

pointcut controlPointcut() : cflow(call(void Test.method())) && !within(ControlTestAspect);

before():controlPointcut(){
System.out.println("In Control pointcut : " + thisJoinPoint);
}
}

This aspect contains pointcut that captures all join points that are triggered during the control flow of method method() of class Test. The output of running the Test class is -

In Control pointcut : call(void Test.method())
In Control pointcut : execution(void Test.method())
In Control pointcut : set(int Test.value)
Exiting Test.main()

As we can see, the before advice is called for all the join points that comes in the control flow of method() execution.

If we use cflowbelow in the pointcut instead of cflow, the output will be -

In Control pointcut : execution(void Test.method())
In Control pointcut : set(int Test.value)
Exiting Test.main()

i.e. it captures all the join points that are below the specified join point.

When defining pointcut using cflow or cflowbelow, we need to ensure that the pointcut does not capture the calls that are made from the same aspect, otherwise it will invoke recursive method calls and we will get StackOverflowError. This happens because cflow() will also capture the method calls from the aspect itself and try to apply the advice to it.
This can be avoided by using within() construct. within() takes a type(class or interface) name as argument and captures all join points the are defined in that type.

To capture all the join points in the control flow of method foo of class Test and excluding the calls from the TestAspect, we can define the pointcut as -

pointcut controlPointcut() : cflow(call(void Test.foo())) && !within(TestAspect);

This pointcut will exclude the join points that are triggered directly by TestAspect, however if the join points are invoked indirectly in the control flow of advice then those join points will still be captured. e.g. If the advice in TestAspect calls method shoo() of class Test2 and this method calls method foo of Test, then this join point will NOT be excluded by above pointcut and we will get StackOverflowError because of recursive advice invocation. This can be avoided by using adviceexecution() construct.

pointcut controlPointcut() : cflow(call(void Test.foo())) && !cflow(adviceexecution());

This pointcut will happily exclude all the join points that are triggered directly or indirectly by the aspect.

Lets look at the places where cflow and cflowbelow() can be used effectively.

# One obvious use of cflowbelow is to capture non-recursive call to method.
e.g. consider a class Foo -

public class Foo {

private void count(int value){
if(value==0) return;
System.out.println("Hi!");
count(--value);
}

public static void main(String[] args) {
new Foo().count(2);
new Foo().count(2);
}
}

If we want to capture only the non-recursive calls to the method count(), then we will need an aspect like this -

public aspect FooAspect {

pointcut countMethod() : call(void Foo.count(..));
pointcut nonRecursiveCountMethod() : countMethod() && !cflowbelow(countMethod()) ;

before() : nonRecursiveCountMethod() && !cflow(adviceexecution()) {
System.out.println("In nonRecursiveCountMethod pointcut : " + thisJoinPoint);
}
}

The output of running the Foo class is -

In nonRecursiveCountMethod pointcut : call(void Foo.count(int))
Hi!
Hi!
In nonRecursiveCountMethod pointcut : call(void Foo.count(int))
Hi!
Hi!

As we can see, only calls that are made outside of method count() are captured and recursive calls are ignored.

# cflow and cflowbelow are useful if want to perform operation only in specific part of your application (or if you want to restrict the operation in specific part). e.g. if you want to add security check on method call of some class, say Foo only if the method is called from methods in web tier classes (and their subclasses), then we can write pointcuts like -

pointcut methodCalls() : call(public void Foo.*(..)) ;
pointcut methodCallFromWebTier() : methodCalls() && cflow(call(* com.webtier.*+.*(..)));

Now, we can write advice for methodCallFromWebTier() pointcut to perform specific operation.

The pointcut can be easily modified using unary NOT (!) to do operation when method is called from anywhere other than the control flow of methods in web tier classes.

pointcut methodCallFromWebTier() : methodCalls() && !cflow(call(* com.webtier.*+.*(..)));

Static crosscutting with AspectJ

2007-12-18T06:15:00.000-08:00

Crosscutting concerns are the features of the system that are applicable across the system. They need to be applied in the system-wide manner in multiple modules. Examples of the typical crosscutting concerns in typical system are authentication, security, error handling, logging etc.
Crosscutting concerns can be addressed in two ways - Dynamic and static. Dynamic crosscutting modifies the runtime behaviour of system and static crosscutting helps to change the static stracture of program. Here, I will only discuss about static crosscutting, and will blog about dynamic crosscutting seperately.

Lets look at way in which static crosscutting can be applied.

## One of the feature of Ruby is that all the classes in Ruby are open. That means you can add new members to the existing class. Its a native feature of Ruby language. However, same feature can be achieved in Java with AspectJ. By using aspects, you can add new members to the existing class or interface. We can add new field, method, constructor into existing class. This is called as static member introduction.

e.g. To add new members in the class Foo, we will write as -

public aspect FooAspect {
public float Foo._newField = 9.0;

public void Foo.newMethod() {
System.out.println("Crosscutting - The static way !");
System.out.println("Value of field : " + _newField);
}
}

These new members will be available to use when we weave(compile) this aspect with Java class Foo.

New methods can be added in interface with implementation, you can not add just methods signature ending in semicolon. This implementation acts as default for all implementing classes. If we want to modified method for some class, we need to define that method either in aspect or directly in our class.

The following aspect adds a new method in FooInterface interface.

public aspect FooInterfaceAspect {

public void FooInterface.blue(){
System.out.println("In new method from Aspect");
}
}

## We can change the class hierarchy with declare parent clause. We can add new parent to the class or add an interface to the class or set of classes.

e.g. To implement FooInterface for Foo class -

public aspect FooInterfaceAspect {
declare parents : Foo implements FooInterface;
}

Following piece of code implements the interface to group of classes and implements the method in individual classes.

public aspect MyAspect {
declare parents : com.webservices.messages.* implements SomeInterface;
public Object ClassOne.method() {
// do something
}
public Object ClassTwo.method() {
// do something else
}
}

Instead of writing separate method for each class, We can also write a single method which will be used by all classes. This can be done by defining the method on interface rather than on class.

public aspect MyAspect {
declare parents : com.webservices.messages.* implements SomeInterface;
public Object SomeInterface.method() {
// do something
}
}

This feature along with member introduction can be used intelligently to achieve modular solutions when using with third party API. An excellant example of this is given in article AOP banishes the tight-coupling blues.

Similar to class, We can also extend an interface.

public aspect FooInterfaceAspect {
declare parents : FooInterface extends ShooInterface;
}

## We can give out compilation errors or warnings by using -

declare error : pointcut : message;
declare warning : pointcut : message;

For Example, following aspect gives compile error when method method() of Foo class is used and gives warning when anotherMethod() is used -

public aspect FooAspect {
declare error : call(void Foo.method()) : "No way man !";
declare warning : call(void Foo.anotherMethod()) : "You shouldn't do this !";
}

We can use this to give out compilation errors or warnings when some deprecated or unsupported methods are called in code. Or we can use this to recomment usage for methods.
This is useful when we have to use third party code or API and we want to regulate the usage pattern.

## We can use AspectJ to soften the checked exceptions.
There are two types of exceptions in Java. For Checked exceptions, the caller of the method which throws exception need to handle it explicitly by using try-catch or by re-throwing it. And other is Unchecked exceptions which need not be handled explicitly. They are subclasses of RuntimeException or Error.

This piece of code softens i.e. converts the checked exception into unchecked exception. So that the caller of the method do not need to handle it.

public aspect FooAspect {
declare soft : java.rmi.RemoteException : call(void Foo.method());
}

Now the caller of method method() do not need to handle the exception explicitly. This is achieved by adding try-catch block around the method call in code during weaving process. In the catch block, actual exception is wrapped in org.aspectj.lang.SoftException and throw again.SoftException is a subclass of RumtimeException.

## We can define the precedence of advice with the declare precedence clause.
e.g.
declare precedence : LoggingAspect, ErrorCheckAspect;

Only concrete aspects are meaningful in the list of aspects. Having abstract aspects in the list has no effect. However, we can use wildcard characters. e.g. If Logging and ErrorCheck are two abstract aspects, you can give precedence to aspects that extend logging over the aspects that extend Security as-
declare precedence : Logging+, ErrorCheck+;

The following declaration gives precedence to all the aspects that have 'Logging' in their name.
declare precedence : *Logging*, *Error*;

Having a same aspect more than once in the list,which makes cyclic precedence, is not allowed and it gives error. e.g.
declare precedence : LoggingAspect, ErrorAspect, LoggingAspect; // Error !

However,

declare precedence : LoggingAspect, ErrorAspect;
declare precedence : ErrorAspect, LoggingAspect;

is allowed as long as the pointcuts in two aspects are not matching or overlapping. If any pointcut in two aspects are same then we get an error saying "conflicting declare precedence orderings for aspects".

Finally, one last point. The pointcuts that are used in static crosscutting has a limitation. All the static crosscutting pointcuts should be such that they can de determined at compile time. So pointcuts can not be determined in terms of cflow, this, if, target, args.

What is Metaobject protocol ?

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

In traditional programming languages like C, C++, Java, programming language designer works at different level of abstraction than programming language users. Language designers writes programmers that decides how the elements of programming languages works and how the features in the languages such as method dispatch, inheritance are implemented. And the programming language users work on writing the primary application classes without having the flexibility of changing the way language itself works.

However, in some languages like Common Lisp Object System (CLOS), Groovy and Ruby, the programming language provide interface to alter and enhance the core features of programming language. This allows changing the way language throws certain exception or implementing multiple inheritance in language that does not allow it by default.

Metaobject protocol is a interface to programming language using which programmer can add and modify the features to programming language. Here, programming language users play with the Meta objects. These objects decides how features like inheritance, method invocation, scope resolution behaves. These objects are called as Meta Objects simply because they holds information about object like methods, fields, super class etc.These objects also controls run time behavior of program and how the primary objects in the actual system works. We can say that Metaobject protocol makes features of compiler/interpreter available to the programmers.

Metaobject protocol is an important feature for meta programming (However, some programming languages like smalltalk allows to do elegant metaprogramming without MOP). It also allows programmers to adjust language according to their needs.
For example, Common Lisp Object System (CLOS) adds object oriented and dynamic language features to LISP using Metaobject protocols. The implementation of language is done by implementing classes as objects of a metaclass and allowing programmer to change behavior of base class and also allow defining new metaclasses.

Groovy, a dynamic scripting language for JVM, implements Metaobject protocol. Metaobject protocol in Groovy decides how the core language functionality like method dispatch, scope resolution for attributes works. It gives more flexible control of language in programmer's hand. And Ruby has many features that allows programmer to do amazing things like changing the behavior of class on run time, defining methods dynamically etc. The AOP implementation for Java called AspectJ is also implemented with Metaobject protocol.

In short, Metaobject protocol gives some amazing power and flexibility to the programmer which can be used with little caution to create amazing programs !

AOP - Need to explore more..

2007-12-04T22:55:00.000-08:00

When I came across AspectJ first time, I was unsure how to use it effectively. And when I started exploring it, i was amazed by the enormous capability it has, power to create highly modular and clean design. AspectJ and in turn, Aspect Oriented programming (AOP) has lot of potential to solve our programming hurdles. Still I am exploring the field and checking the places where it can be used effectively.

In my last project, I used AOP mostly for logging and once for authentication (thanks to people who worked on it). But there are lot of much more serious things that can be done.

It depends on us how we can separate our code into aspects and have the "multidimensional" programming code rather than mixing all the aspects into single dimension. Obviously, AOP is not here to replace OOP. Both AOP and OOP need to collaborate to produce the most modular and maintainable code. In fact, AOP allows us to address the problems that are (to some extent) out of scope of OOP.

I think, the excellent OOP design can partially address some of the issues that AOP is solving. So, why to use AOP ? The most obvious answer is AOP is better way of doing it !! Its best suited for addressing the crosscutting concerns. And we always prefer better and cleaner way of doing things. Practically, there is no program that can not be written using machine language or even brainfuck (which is one of those Turing complete esoteric programming languages). But still we use Java and C++ because they are address the problems more effectively and easily !!

Dynamic typed languages rocks ?

2007-11-28T07:09:00.000-08:00

Throughout my programming career, I have been using Java and C# which are statically typed languages. But personally I have always been a fan of languages like LISP, Perl, Ruby. And my one of the most favorite feature of these languages is their Dynamic typing capability.

Lets first look at what are Static typed languages.

Static typing is when the the type of variable is known before running a program. In other words, in static typed languages, you have to declare the type of variable before it is used. In such languages, variable is bind to a specific type.
Most of the 'industry standard' languages like Java, C, C++, Pascal are statically typed languages.

There are some obvious advantage of using the static typing.

Statically typed languages are potentially more secure as they can catch the typing errors during compile type only, before actually running the program.

The performance of statically typed languages can be better. The compiler has the type information of a variable and it can potentially use it for improving performance. There are more opportunities for compiler optimization which can make it run effectively.

Code written in static typed languages is easier to understand. The type specification acts as a implicit code documentation in the program. And unlike code comments, this documentation don't have danger of getting outdated. So, in turn, this leads to self documented code.

Better IDE support is available. As the type of the variable is already determined, a intelligent IDE like Eclipse or IntelliJ can provide features such as auto completion.

In Dynamic typing, the type of the variable is determined at run time. In such languages, you don't need to declare a variable before it is used. Languages like Smalltalk, Lisp, Perl, Python, PHP, Javascript, Ruby are dynamic languages.

The advantages offered by dynamic typed languages are much attractive.

First and foremost (according to me), Programming is more fun in dynamically typed language. You don't need to keep on declaring although you know that there is no value in it and its only required by your programming language, just for the understanding of compiler.

A program can be written much concisely in dynamic programming languages. The decrease in the amount of code is not achieved only by omitting the variable declaration but the reusability and flexibility of the code increases greatly because of dynamic typing.

Lets look at the implementation of method that checks if the object is null or empty in Java

boolean isNullOrEmpty(String string) {
return ( string==null ) || (string.length() == 0 );
}

The problem with this method is that only objects of type String can access it. If you want to implement same method for any different object, you need to duplicate the method with different parameter.

And the same method in Ruby..

def isNullOrEmpty? object
object == nil or object.length == 0
end

As the type of the parameter is not specified, you can use this same method for any object that has length method, including any custom objects.
This feature is also called as Duck Typing in the ruby lingo. Duck typing suggests that Object type is determined by the behavior. That means, rather than checking for the type
of object, we just check if the object supports required operation.

However, advocates of static typing criticize of dynamic typing for some reason. Lets look the issues and see if we can resolve them.

Dynamic typing can make code difficult to understand. The type of variable or the return type of method is not declared in code. So, it can be difficult to imagine what will be in a variable during runtime.

This problem is mostly faced by newcomers or people who are coming from the static typed programming background. However, some real application code can be enough
complex to confuse most experienced programmers also. The problem can be partially solved by proper naming conventions and also by witting unit tests. Properly designed Units tests helps to revel the purpose of code.Informative coding convention (like suffixing the method names with ? when the return type is boolean) and unit tests can help in understanding the code without the using verbose nature of static typed languages.

Dynamic typed languages are more error prone as they dont perform the type checking before running the program. The program gives run time exception in case of typing errors which could be caught at compile time by static typed language compilers.

The frequency of run time errors due to typing issues is itself questionable. Although there is a possibility of such errors, the occourance of such events is rare even in complex system. And again, the practice of TDD or writting unit tests helps to capture the type errors.
In fact, statically typed languages are also not totally type safe. The type casts can fail at run time. Thats the reason we have ClassCastException in Java. The down casting - casting a object downwords in class hierarchy can be error prone.

Dynamic typed languages are not suited for enterprise products and applications. Because of the lack of type checking and (so called)slower performance as compared to static typed languages, dynamic typed languages are good for fun programming but not for developing serious applications.

The company where I work, ThoughtWorks, is one of the industry leader in developing Ruby apps. If anyone has doubt if Ruby, one of the newest dynamic typing language is
enterprise-ready, I will suggest them to check out Mingle (http://studios.thoughtworks.com/mingle-project-intelligence), a project management tool developed in Ruby using rails and Oracle mix (https://mix.oracle.com/) which is a first public JRuby on Rails site. The performance and stability of these products is really good.

My personal choice is dynamic typing cause the programming with them is more fun for me. The ability of these languages to produce concise, reusable code has really amazed me. Although the features of static typed languages like ability to run code faster and checking for type errors before run time are nice to have, but these features comes with cost. So for me, languages with dynamic typing rocks ! :-)