I happened to stumble across this and I thought I would post it here for my blog readers.
Spring Getting into Groovy
Happy Reading!!
Tuesday, December 9, 2008
Friday, December 5, 2008
Checked Exception Vs Unchecked Exception
How do you decide what type of Exception to throw? Should you throw a Checked Exception or Unchecked Exception? Well here are a few questions to consider whenever you come across such a situation which will help you make a better decision
1) Does your code have to handle the errors or report the error according to a specific custom error defined by your application?
2) Is the error recoverable ? Do you have an alternate way of recovering from the error?
3) Are you designing an API ?
If your answer to the above questions is "YES" then you definitely need to work with checked exceptions.Simply put Unchecked exceptions are generally used to determine programming errors or situations where it simply makes no sense to recover from an error situtation. Unchecked exceptions are also used when you are working with third party API's where you really have no control over them.
One more thing there are situations which will justify both scenarios in that case I generally follow this rule "When in doubt go with Unchecked Exceptions".
1) Does your code have to handle the errors or report the error according to a specific custom error defined by your application?
2) Is the error recoverable ? Do you have an alternate way of recovering from the error?
3) Are you designing an API ?
If your answer to the above questions is "YES" then you definitely need to work with checked exceptions.Simply put Unchecked exceptions are generally used to determine programming errors or situations where it simply makes no sense to recover from an error situtation. Unchecked exceptions are also used when you are working with third party API's where you really have no control over them.
One more thing there are situations which will justify both scenarios in that case I generally follow this rule "When in doubt go with Unchecked Exceptions".
Thursday, December 4, 2008
Guice - A Lightweight IOC Container from Google
Guice is pronounced "Juice" and yea its a lightweight dependency injection framework for Java 5 and above brought to you by Google. Now why would anyone ever think of coming up with another IOC container when an awesome IOC container like Spring is around ? Hmm.. Good question aint it :) This time I want my readers to post their thoughts and opinions on this before I give away my thoughts on "Why Guice".
You can download Guice from Guice
Will share my thoughts in my next post until then I will looking forward for some responses.
You can download Guice from Guice
Will share my thoughts in my next post until then I will looking forward for some responses.
Wednesday, December 3, 2008
Learning a new programming language
Hmm... Frankly I believe that there is no ONE way to learn a new programming language in fact it differs from person to person according to their programming styles and intellect. Some like to get hands on right away and some like to read a book before they get hands on and there are some who read and write code parallely.
Personally I believe in learning by example via Unit Tests. So if I decide to learn Ruby then I would go ahead and start writing programs in Ruby by writing unit tests.
After working with JUnit and being a Java developer I have understood the importance and value of Unit testing. Unit testing is a neat way of knowing that your programs work and also it is the best form of feedback one can get about their code.
When you are learning a new language by writing unit tests you are actually building a knowledge base that you can always look back to refresh your knowledge and understanding at any given point of time. So cool aint it :)
Simply put get hold of a Pragmatic Book on a programming language of your choice and start learning by writing tests and you will find yourself at ease very soon with the new programming language.
Personally I believe in learning by example via Unit Tests. So if I decide to learn Ruby then I would go ahead and start writing programs in Ruby by writing unit tests.
After working with JUnit and being a Java developer I have understood the importance and value of Unit testing. Unit testing is a neat way of knowing that your programs work and also it is the best form of feedback one can get about their code.
When you are learning a new language by writing unit tests you are actually building a knowledge base that you can always look back to refresh your knowledge and understanding at any given point of time. So cool aint it :)
Simply put get hold of a Pragmatic Book on a programming language of your choice and start learning by writing tests and you will find yourself at ease very soon with the new programming language.
OO Recipes
Here are my OO Recipes that I think would really cook up some good OO applications in the software world
1) Composition Vs Inheritance - Hmmm... oh well I guess every comes across this one so often so I will try my best to explain it in the simplest way possible. Inheritance breaks encapsulation by tightly coupling the subclasses with the base class so the changes in the base class must be in tandem with subclasses or else it may break the system. Composition on the other hand does not suffer from this limitation as it encourages delegation of work. Composition also promotes encapsulation.
2) Helper Classes - In my opinion if you have lots of Helper or Utility classes then you have not got your abstraction right and it indicates a poor design. Lets take a look at Collections Framework in Java.
For eg:- The AbstractCollection class that implements the Collection interface has implemented a few methods that are generic in nature to all the Collections that implement the Collection interface hence there is no need for any kind of utilty methods or classes.
3) Static methods - The use of static methods are justifed when you are using them to create factory methods or singletons or utility methods that help in remove duplication of code. Anything beyond this usage indicates a procedural mindset.
4) Singleton Good or Bad - Singletons are a good excuse for global variables. Moreover Singletons are supposed to guarantee a single instance and this is true only if you are using a unified class loader. Having said all this they are useful in maintaining the state throughout the application.
5) Encapsulation - This encourages tight coupling within the class and only exposes the stuff that needs to be exposed to the client classes. Without good encapsulation its impossible to design an application that is flexible and simple. Encapsulation encourages the principle of least knowledge.
6) Single Responsibility Principle - Every object in your application should have one single responsibility of doing something if its doing more than one thing then obviously it needs refactoring or perhaps maybe decomposing it into simpler objects.
7) Dont Repeat Yourself - If you find yourself repeating a block of code or a block of logic very often consider refactoring them by moving them to another domain object or in the worst case a utility method.
8) Polymorphism - Whenever you come across code that does conditional type checking that is a strong indication that it definitely needs refactoring. All those if else, switch statements look ugly.
9) Abstraction - If you get your abstraction right then there will be very few helper class and utilty methods around your application and there will also be high reuse of code.
10) Immutability - Immutable objects help keep your application simple and thread safe, think about it if your objects are immutable you dont have to every worry about thread safety. However some may argue that this will create unnecessary objects on the heap and yes it does but performance is something that we always look at the end. The trick here is if your application is simple and flexible then its easy to tweak it to perform well.
11) Programming to Interfaces - I have a dedicated post on this topic. Click here to read more Programming to Iinterfaces
1) Composition Vs Inheritance - Hmmm... oh well I guess every comes across this one so often so I will try my best to explain it in the simplest way possible. Inheritance breaks encapsulation by tightly coupling the subclasses with the base class so the changes in the base class must be in tandem with subclasses or else it may break the system. Composition on the other hand does not suffer from this limitation as it encourages delegation of work. Composition also promotes encapsulation.
2) Helper Classes - In my opinion if you have lots of Helper or Utility classes then you have not got your abstraction right and it indicates a poor design. Lets take a look at Collections Framework in Java.
For eg:- The AbstractCollection class that implements the Collection interface has implemented a few methods that are generic in nature to all the Collections that implement the Collection interface hence there is no need for any kind of utilty methods or classes.
3) Static methods - The use of static methods are justifed when you are using them to create factory methods or singletons or utility methods that help in remove duplication of code. Anything beyond this usage indicates a procedural mindset.
4) Singleton Good or Bad - Singletons are a good excuse for global variables. Moreover Singletons are supposed to guarantee a single instance and this is true only if you are using a unified class loader. Having said all this they are useful in maintaining the state throughout the application.
5) Encapsulation - This encourages tight coupling within the class and only exposes the stuff that needs to be exposed to the client classes. Without good encapsulation its impossible to design an application that is flexible and simple. Encapsulation encourages the principle of least knowledge.
6) Single Responsibility Principle - Every object in your application should have one single responsibility of doing something if its doing more than one thing then obviously it needs refactoring or perhaps maybe decomposing it into simpler objects.
7) Dont Repeat Yourself - If you find yourself repeating a block of code or a block of logic very often consider refactoring them by moving them to another domain object or in the worst case a utility method.
8) Polymorphism - Whenever you come across code that does conditional type checking that is a strong indication that it definitely needs refactoring. All those if else, switch statements look ugly.
9) Abstraction - If you get your abstraction right then there will be very few helper class and utilty methods around your application and there will also be high reuse of code.
10) Immutability - Immutable objects help keep your application simple and thread safe, think about it if your objects are immutable you dont have to every worry about thread safety. However some may argue that this will create unnecessary objects on the heap and yes it does but performance is something that we always look at the end. The trick here is if your application is simple and flexible then its easy to tweak it to perform well.
11) Programming to Interfaces - I have a dedicated post on this topic. Click here to read more Programming to Iinterfaces
Tuesday, December 2, 2008
New Programming Language (NPL)
In order to write an interpreter for a new programing language I figured out that it might be best that I learn some new programming languages from where I can absorb the best and bring those into this new language, For now I will call this new programming language NPL (New Programming Language).
For NPL to stand any chance of getting popular in the developers community and at least being noticed it needs to be powerful, flexible, simple and dynamic in nature along with these there are many other things that needs to be looked into to make this noticed at the least.
I am a Java/J2EE developer whose current programming language interests are Ruby, Groovy and Erlang. The idea that I have in my mind is to build NPL on the Java Platform where the interpreter will be written in Java which will interpret the NPL into machine code and execute them in the JVM. I think the Java Platform is an awesome mature platform hence the choice of JVM platform. Watch out my next post for the justification of my choice for the Java Platform.
Again the intention of NPL is not to replace any programming language nor boast its supremacy over other languages however in my opinion I think it will be good enough to get noticed at the very least.
For NPL to stand any chance of getting popular in the developers community and at least being noticed it needs to be powerful, flexible, simple and dynamic in nature along with these there are many other things that needs to be looked into to make this noticed at the least.
I am a Java/J2EE developer whose current programming language interests are Ruby, Groovy and Erlang. The idea that I have in my mind is to build NPL on the Java Platform where the interpreter will be written in Java which will interpret the NPL into machine code and execute them in the JVM. I think the Java Platform is an awesome mature platform hence the choice of JVM platform. Watch out my next post for the justification of my choice for the Java Platform.
Again the intention of NPL is not to replace any programming language nor boast its supremacy over other languages however in my opinion I think it will be good enough to get noticed at the very least.
Ambitious Programming Projects
Ever since my engineering days in univeristy the thought of building my own operating system had always crossed my mind and the intention behind it was not to replace any existing operating systems around in the software world but simply to challenge myself that I can do it.
In my opinion a student with a computer science background should be able to write an operating system and/or even a compiler/interpreter which is also another project that I always had in my mind. Somehow for many other reasons I never got around doing them, However I have finally got myself to go ahead and implement them and translate those thoughts into code. Its going to be fun and challenging too but I will keep you guys posted on the same.
Oh by the way they are going to be open source projects so you guys can look at my stuff and give me feedback on the same or even contribute to the project. Will share the details of the project as soon I commit a very basic working model of the projects.
In my opinion a student with a computer science background should be able to write an operating system and/or even a compiler/interpreter which is also another project that I always had in my mind. Somehow for many other reasons I never got around doing them, However I have finally got myself to go ahead and implement them and translate those thoughts into code. Its going to be fun and challenging too but I will keep you guys posted on the same.
Oh by the way they are going to be open source projects so you guys can look at my stuff and give me feedback on the same or even contribute to the project. Will share the details of the project as soon I commit a very basic working model of the projects.
Subscribe to:
Posts (Atom)
Posts
