Too much abstraction is bad
I always felt annoyed casting ServletRequest object to HttpServletRequest whenever I am programming using java servlets. The servlet API is designed so that it abstract away Http protocol and looks at the big picture in which you may also have FtpServlet or PoP3Servlet. But, as every JSP developer knows, till date we have not seen any implementation of the servlet API for any other internet protocol so wasn't it much better that Sun Microsystems would have created the API specially for handling HTTP protocol based servlets allowing developers lot more hand-coding productivity?
In the above example I just wanted to show that casting the abstract object to specific type every time you want to use it is unnecessary.
In other cases, abstraction may adversely affect the performance and scalability of the overall/final application itself. Take the example of old EJB specification. A significant number of developers were using just jsp/servlet based client for connecting to EJB layer and so abstracting the whole business logic in EJB that too working on marshaling/unmarshaling using Remote objects was overkill!
I was facing the same issue when designing a framework for our web applications. I was faced with choice of creating it very abstractly, making it easy later to make it independent of Http protocol thereby making is suitable for non-web / desktop applications as well. But finally I realized that if there is no short term, there is no long term. So an ideal choice was to make it abstract as much as possible without losing the lightweightness, to-the-point and easy to understand naming conventions and overall developer productivity. In short I chose 'abstraction' but not 'too much of it'!
In the above example I just wanted to show that casting the abstract object to specific type every time you want to use it is unnecessary.
In other cases, abstraction may adversely affect the performance and scalability of the overall/final application itself. Take the example of old EJB specification. A significant number of developers were using just jsp/servlet based client for connecting to EJB layer and so abstracting the whole business logic in EJB that too working on marshaling/unmarshaling using Remote objects was overkill!
I was facing the same issue when designing a framework for our web applications. I was faced with choice of creating it very abstractly, making it easy later to make it independent of Http protocol thereby making is suitable for non-web / desktop applications as well. But finally I realized that if there is no short term, there is no long term. So an ideal choice was to make it abstract as much as possible without losing the lightweightness, to-the-point and easy to understand naming conventions and overall developer productivity. In short I chose 'abstraction' but not 'too much of it'!