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.
Friday, November 28, 2008
Time to Market Vs Product Quality
As software becomes more and more part of revenue generation processes in all industrial domains, and as development cycles shorten significantly, the challenges of producing high reliability and quality as well as adhering to shorter time-to-market requirements have hit the software community. As unsuccessful cases demonstrate, the solution is neither to throw unreliable software on the market prematurely, nor to be late with high quality software. The key seems to be choosing the appropriate development model and using development processes in a goal-driven way. There is a big difference between product and process oriented development models. Which one is appropriate under what circumstances?
Another fascinating dimension to this issue is the effect of brand. If you launch a crappy product early, it harms your brand. But this percpetion can be mitigated by calling the product a "beta"! So instead of thinking of it as time-to-market, think of it as a public product test.
So when we think about all of this what strikes our mind is to come up with a process that takes care of both cases i.e quality and time to market.
Agile Methodologies like SCRUM and XP were formed to address these issues and moreover these processes focus more on the product than the process itself. SCRUM, XP have iterations where each iteration adds value to the product and at the end of every iteration you have working code. This is a product centric approach backed by a process that allows flexibilty.
Agile methodology should not be mistaken for Ad-hoc releases where the developers take last minute changes from the client or the customer in order to keep the customer happy and as a result of that ends up breaking the build somewhere else which in turn leads to long working hours and working on weekends. Simplicity is one of the principles of agile and do only what is required.
I would like to end this by stating that getting a product out in a short time frame is not a challenge but getting a product out in a short time frame which is of good quality and something you can be proud of is a challenge.
A product whose foundation is well built is more likely to succeed.
Another fascinating dimension to this issue is the effect of brand. If you launch a crappy product early, it harms your brand. But this percpetion can be mitigated by calling the product a "beta"! So instead of thinking of it as time-to-market, think of it as a public product test.
So when we think about all of this what strikes our mind is to come up with a process that takes care of both cases i.e quality and time to market.
Agile Methodologies like SCRUM and XP were formed to address these issues and moreover these processes focus more on the product than the process itself. SCRUM, XP have iterations where each iteration adds value to the product and at the end of every iteration you have working code. This is a product centric approach backed by a process that allows flexibilty.
Agile methodology should not be mistaken for Ad-hoc releases where the developers take last minute changes from the client or the customer in order to keep the customer happy and as a result of that ends up breaking the build somewhere else which in turn leads to long working hours and working on weekends. Simplicity is one of the principles of agile and do only what is required.
I would like to end this by stating that getting a product out in a short time frame is not a challenge but getting a product out in a short time frame which is of good quality and something you can be proud of is a challenge.
A product whose foundation is well built is more likely to succeed.
Building Products the Right Way
How many times has it occured to you when you are developing software that is going to be used by millions of people and that you need to deliver something that does cool stuff, looks good , very stable and 24/7 available especially when you are building a product for a company whose future revenues depend upon the product that you ship out!!
Developers sweat it out day and night, weekends and holidays to get the product out as soon as possible but the downside to this is that the quality of the product degrades everytime this approach is taken. Long hours and over working does not contribute in a positive way to anything let alone product development. A developer does not become a team player only if he contributes more hours to the project. Every developer has his or her own style of working and they know their limitations, beyond which any amount of work is unproductive and inefficient.
Product development is not just about developing the software but also understanding how to manage it properly in such a way that things dont go wrong and the goal is met. Long hours and overworking are not the answers in making a product successful.
Developers sweat it out day and night, weekends and holidays to get the product out as soon as possible but the downside to this is that the quality of the product degrades everytime this approach is taken. Long hours and over working does not contribute in a positive way to anything let alone product development. A developer does not become a team player only if he contributes more hours to the project. Every developer has his or her own style of working and they know their limitations, beyond which any amount of work is unproductive and inefficient.
Product development is not just about developing the software but also understanding how to manage it properly in such a way that things dont go wrong and the goal is met. Long hours and overworking are not the answers in making a product successful.
Thursday, September 25, 2008
Nice Read on Clean Code
Hello readers, I happened to find out a nice article on clean code.
Clean Code
check it out and let me know your thoughts and opnions!!
Clean Code
check it out and let me know your thoughts and opnions!!
Monday, June 16, 2008
Which is the hottest Web Framework?
Hello readers this is a question I always had on my mind and I found a post that addresses this question. Check it out!!
http://www.breakitdownblog.com/which-is-the-hottest-java-web-framework-or-maybe-not-java/
http://www.breakitdownblog.com/which-is-the-hottest-java-web-framework-or-maybe-not-java/
Wednesday, June 11, 2008
Do we need a Business Analyst?
Firstly lets understand the role and responsibilities of a business analyst. A business analyst understands the requirements and give possible solutions to a customer problem. They are critical in changing the way the client business is done. They dictate most of the solution. On the technical front they define the functional requirements for the application which allows the developers to follow these requirements. Testing and quality is sometimes done by these analyst. If they do not pass the software it is not delivered to the client.
They interact with the customer frequently and understand the business problems of the customer and sometimes are referred to as functional champions. Developers often get too technical whereas a business anaylst weighs the business side of things as well as the technical nature of the problem.
BA is definitely crucial and important for a project to make critical business decisions and functional changes. A developer may not have a complete and broad insight into the overall business problem of the customer. A developer in the long run can be groomed into a BA as it always good to have a technical background in order to make well informed decisions.
What do you guys think? Any suggestions or opinions are welcome
They interact with the customer frequently and understand the business problems of the customer and sometimes are referred to as functional champions. Developers often get too technical whereas a business anaylst weighs the business side of things as well as the technical nature of the problem.
BA is definitely crucial and important for a project to make critical business decisions and functional changes. A developer may not have a complete and broad insight into the overall business problem of the customer. A developer in the long run can be groomed into a BA as it always good to have a technical background in order to make well informed decisions.
What do you guys think? Any suggestions or opinions are welcome
Friday, May 30, 2008
How to hire the "right developers"?
A very good and tough question dont you think ? Different organizations have adopted different ways of hiring developers however none of their hiring strategies are foolproof. Somehow developers who are not very productive or effective manage to get in. That brings us to the question of how do we solve this issue? I believe that the key to this answer is to hire smart people who can get the job done.
So how would you define Smart? Well thats a tough question!!! But here is my shot at it. Smart in my definition is anyone who can think practically about a problem in hand and provide a practical solution. Smart and getting the job done go hand in hand in fact they complement each other.
Smart but not productive or effective.
You could have someone who is a Phd who is extremely brilliant but all his solutions are practically impossible. People who are smart but don't get things done often have PhDs and work in big companies where nobody listens to them because they are completely impractical.
Does the job but not in the smartest way
A developer who get things done but are not smart will do stupid things without thinking about them and somebody else will have to clean up their mess later. This is really a pain because not only do they not contribute, but they take up a lot of time of the good developers time. They are the kind of people who copy big chunks of code around rather than writing a subroutine, because it gets the job done, just not in the smartest way.
Sometimes its the guys who interview the candidate, they may not be smart enough to conduct the interview in the first place which ends up in bringing more unproductive developers to the organization. On the other hand the recruitment process itself may not be good enough to find out if the candidate is the right one for the job.
Of all the interviews that I have attended so far in my career I rate Thoughtworks recuritment process very highly. They are very thorough in their recruitment process for a developer and they take their hiring very seriously. Every round in their recruitment process for a developer is justified and thats probably why the guys over there are really smart. I know a couple of them and they really know their stuff and they do their stuff really well. This is the best example I can think of when you want to hire the right developers who are smart and gets things done. However I am not saying that their recruitment process is foolproof but its the best I have seen and experienced so far personally. They have a good hiring process in place which brings in smart people who know their stuff and do it really well to the company and they in turn bring more smart people into the company.
So how would you define Smart? Well thats a tough question!!! But here is my shot at it. Smart in my definition is anyone who can think practically about a problem in hand and provide a practical solution. Smart and getting the job done go hand in hand in fact they complement each other.
Smart but not productive or effective.
You could have someone who is a Phd who is extremely brilliant but all his solutions are practically impossible. People who are smart but don't get things done often have PhDs and work in big companies where nobody listens to them because they are completely impractical.
Does the job but not in the smartest way
A developer who get things done but are not smart will do stupid things without thinking about them and somebody else will have to clean up their mess later. This is really a pain because not only do they not contribute, but they take up a lot of time of the good developers time. They are the kind of people who copy big chunks of code around rather than writing a subroutine, because it gets the job done, just not in the smartest way.
Sometimes its the guys who interview the candidate, they may not be smart enough to conduct the interview in the first place which ends up in bringing more unproductive developers to the organization. On the other hand the recruitment process itself may not be good enough to find out if the candidate is the right one for the job.
Of all the interviews that I have attended so far in my career I rate Thoughtworks recuritment process very highly. They are very thorough in their recruitment process for a developer and they take their hiring very seriously. Every round in their recruitment process for a developer is justified and thats probably why the guys over there are really smart. I know a couple of them and they really know their stuff and they do their stuff really well. This is the best example I can think of when you want to hire the right developers who are smart and gets things done. However I am not saying that their recruitment process is foolproof but its the best I have seen and experienced so far personally. They have a good hiring process in place which brings in smart people who know their stuff and do it really well to the company and they in turn bring more smart people into the company.
Thursday, May 29, 2008
AppFuse - Kick start your webapps
AppFuse is an open-source Java EE web application framework founded by Matt Raible. The main objective behind the AppFuse framework was to allow developers to get started quickly and easily using popular Java open-source technologies like Spring framework, Hibernate and Struts to eliminate the initial "start up" time when building new web applications.
AppFuse in its simplest form is a project skeleton that is very generic which is ready to use as a web application with the most basic requirements of a web application. Developers can change the skeleton or use the same setup to add their business logic. AppFuse 1.x uses Ant to create projects, as well as build/test/deploy it. AppFuse projects contain a number of classes and files from the very beginning. These files are used to implement features, but are also examples when developing your application. By using AppFuse to start new projects, it is possible to eliminate the usual first week or two of development time and this is the USP of this framework.
Configuration of open source frameworks have already been done in the appropriate downloaded versions. The AppFuse project is pre-configured to connect to a database, to be deployed in an application server, and allows you to login. Security features that are a must of any web application today are already integrated and only requires configuration if necessary.
AppFuse supports Hibernate, iBATIS or JPA as persistence frameworks. For the web framework, you can use JSF, Spring MVC, Struts 2 or Tapestry. Some of the features that AppFuse comes out of the box with are the following that most application use today:
Authentication and Authorization
User Management
Remember Me (saving your login information so you don't have to login every time)
Password Reminder
Signup/Registration
SSL Switching
E-Mail
URL rewriting
Skinnability
Page Decoration
Templated Layout
File Upload
Check it out guys!!! AppFuse Rocks!! Cheers to Matt for giving us AppFuse.
For More Information on AppFuse project check out the AppFuse Project Website
AppFuse in its simplest form is a project skeleton that is very generic which is ready to use as a web application with the most basic requirements of a web application. Developers can change the skeleton or use the same setup to add their business logic. AppFuse 1.x uses Ant to create projects, as well as build/test/deploy it. AppFuse projects contain a number of classes and files from the very beginning. These files are used to implement features, but are also examples when developing your application. By using AppFuse to start new projects, it is possible to eliminate the usual first week or two of development time and this is the USP of this framework.
Configuration of open source frameworks have already been done in the appropriate downloaded versions. The AppFuse project is pre-configured to connect to a database, to be deployed in an application server, and allows you to login. Security features that are a must of any web application today are already integrated and only requires configuration if necessary.
AppFuse supports Hibernate, iBATIS or JPA as persistence frameworks. For the web framework, you can use JSF, Spring MVC, Struts 2 or Tapestry. Some of the features that AppFuse comes out of the box with are the following that most application use today:
Authentication and Authorization
User Management
Remember Me (saving your login information so you don't have to login every time)
Password Reminder
Signup/Registration
SSL Switching
URL rewriting
Skinnability
Page Decoration
Templated Layout
File Upload
Check it out guys!!! AppFuse Rocks!! Cheers to Matt for giving us AppFuse.
For More Information on AppFuse project check out the AppFuse Project Website
Thursday, March 27, 2008
Web Hosting plans and tips
Hey Guys!!!
Looking for website hosting plans and tips . Check this out
Web Hosting plans and tips
Hope you guys find it useful.
Looking for website hosting plans and tips . Check this out
Web Hosting plans and tips
Hope you guys find it useful.
Wednesday, January 9, 2008
Sharing Session Data Across Different Webapps
I recently had an interesting task where a chunk of data had to be shared across different webapps in order for the application to do its job appropriately. The first thing that came to my mind was to implement caching and use that as the in-memory storage for storing frequently used data. By doing this we can store all the shared data and fetch it from the cache. However I was not very sure and this prompted me to have a discussion as well with couple of my friends and they felt that caching was a good idea too. They also suggested that i could also merge the other webapps into one single webapp. This was not an option as the other webapps were third party tools and the requirement was to only work on a very small portion of the third party tools.
If you guys have done it differently or have a better idea do let me know!! Another way of sharing session data is to add crossContext="true" to the context.xml in Tomcat which would allow you to access another context from a given context. The ServletContext would then be used as the in-memory storage for frequently used data. However if this approach is taken one would need to implement thread safety properly. Also according to the Servlet Specification Session is scoped to a ServletContext and ServletContext is per webapp and it is an in-memory or an object container if you like for the owning webapp. Hence this is a bad practice and probably not the best approach.
If you guys have done it differently or have a better idea do let me know!! Another way of sharing session data is to add crossContext="true" to the context.xml in Tomcat which would allow you to access another context from a given context. The ServletContext would then be used as the in-memory storage for frequently used data. However if this approach is taken one would need to implement thread safety properly. Also according to the Servlet Specification Session is scoped to a ServletContext and ServletContext is per webapp and it is an in-memory or an object container if you like for the owning webapp. Hence this is a bad practice and probably not the best approach.
Swift Domain Name Search
Here is a link http://www.swiftdomainsearch.com I found on the web to quickly find out what domain names are available. It does a pretty neat job if it as well. Try it out in your spare time and let me know what you guys think of it as well.
Tuesday, January 8, 2008
Thoughtworks Geek Night Gaming Event
Thoughtworks has organized a gaming event for all you gamers out there. If you guys are interested in playing some really cool games then go ahead and register yourselves for this event. This event is being held in the pune office. For those of you who have not heard about Thoughtworks before here is the url to the company website. http://www.thoughtworks.com/
For more info click on the link below :-
http://groups.google.com/group/ThoughtWorks-Bangalore-Geek-Nights/browse_thread/thread/47c6d6db93c39cd4?hl=en
For more info click on the link below :-
http://groups.google.com/group/ThoughtWorks-Bangalore-Geek-Nights/browse_thread/thread/47c6d6db93c39cd4?hl=en
Thursday, January 3, 2008
Defining Interfaces Java
Below are the two variants of defining and declaring an identical interface. The interface is essentially the same but only differs in the way it is coded.
Snippet-1
------------
public interface UserManager {
public abstract void addUser(User user);
public abstract void removeUser(User user);
//blah blah
}
Snippet-2
------------
public interface UserManager {
void addUser(User user);
void removeUser(User user);
//blah blah
}
Snippet-1 is more detailed or explicit in terms of access specifiers whereas Snippet -2 is implicit in terms of access specifiers. Now the question to be asked here is how should we define interfaces in our code. I did look at the Java Coding standards and there was nothing much I could find over there.
Essentially even though they differ in the way it is coded the access specifiers are public and abstract implicitly even if you dont specify them explicitly according to the Java Language Specification. In my opinion I think its good practice and more clear if you define interfaces and its methods explicity the way its done in Snippet-1 as opposed to Snippet-2. What does the readers of my blog have to say about this? Please share your opinions about the same!!
Snippet-1
------------
public interface UserManager {
public abstract void addUser(User user);
public abstract void removeUser(User user);
//blah blah
}
Snippet-2
------------
public interface UserManager {
void addUser(User user);
void removeUser(User user);
//blah blah
}
Snippet-1 is more detailed or explicit in terms of access specifiers whereas Snippet -2 is implicit in terms of access specifiers. Now the question to be asked here is how should we define interfaces in our code. I did look at the Java Coding standards and there was nothing much I could find over there.
Essentially even though they differ in the way it is coded the access specifiers are public and abstract implicitly even if you dont specify them explicitly according to the Java Language Specification. In my opinion I think its good practice and more clear if you define interfaces and its methods explicity the way its done in Snippet-1 as opposed to Snippet-2. What does the readers of my blog have to say about this? Please share your opinions about the same!!
Subscribe to:
Posts (Atom)
Posts
