Steven Yong's Weblog

I believe most of the J2EE developers have heard of some typical J2EE design patterns, e.g. BusinessDelegate, Data Access Object, Composite Entity, Front Controller, Application Service and many many more. Obviously, there are pros and cons with those patterns, does it really good to apply them? I always heard from coworkers saying that "I can accomplish this pretty easily, why do I need to implement it in a relatively difficult way?". As a coworker, I wouldn't be able to give him the answer or convince him with those pratices. In other hand, as a Java developer, I think I should share something with him.

Design pattern is actually a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution

- from Sun website.

Why Use Patterns?

They have been proven. Patterns reflect the experience, knowledge and insights of developers who have successfully used these patterns in their own work.
They are reusable. Patterns provide a ready-made solution thatcan be adapted to different problems as necessary.
They are expressive. Patterns provide a common vocabulary of solutions that can express large solutions succinctly.

Again, from Sun website.

So, got me now? Of course, patterns do not guarantee success. A pattern description indicates when the pattern may be applicable, but only experience can provide understanding of when a particular pattern will improve a design.
As a conclusion, I suggest we atleast try it out.

As a software devloper, especially a Java application developer, I must get myself updated everyday (at least every week). The number of JSR are increasing incredibly, the experts out there are trying very hard to improve the way programmer codes. They want programmer write lesser code, in more efficient way. To some extends, they actually did their job pretty well. Today, I can easily find tons of core or third-party APIs, I won't ever need to write the low level method or solution by myself as what I did years ago.
While I was learning Servlet API, and just know how to implement a relatively easy to use Front Controller, Struts came out. It has much more better performance, more reliable, rich functionality. The built-in utility classes are pretty helpful, it is not only usable in web-tier (anyway, I don't suggest coworkers to use Struts in business tier).
When I involved in a project which was using EJB 1.0, I had to cater the implementation issues by myself. Now, the project is over, and surprisingly working quite well. But, I always find that the previous implementation was just relatively immature, unreliable and not maintainable after I read at EJB 2.0 specs.
So, what I can do now is, master the EJB2.0 specs in many ways, and, treat experience as lesson. Currently I am able to manipulate the CMP, CMR features and the deployment descriptors for various application servers. Unfortunately, I happened to know that DD will be eliminated in EJB3.0, my question is: "Is the original purpose for creating DD to reduce recompilation for changing deployment attributes?".
Above are just some little small examples saying that people can't apply their knowledge on their works.
Luckily, I'm having different thinking, what I think is, as a Java developer, I have to master the fundamental knowledge, and more importantly, master OO concepts. I'll be able to understand and apply those Open source libraries no matter how much there are, if my Java skill is strong. There is a famous proverb in China: "Learn till you get old". I must learn how to "Learn" in order to carry through this intention.
I find current software development environment attractive, and this is the reason which keeping me to have passion on work.

I'd like to say Hi to everyone here. This is my first blog on the web, and I'm gonna post many many posts from today onwards because I hope I can share my thinking and opinion to everyone.
Nice to meet you all, as you can guess, I'll be focusing more on software (generally OO and Java). Other than that, I'm more than willing to share as much experience as I can on any stuffs that I came across.

Update 17th Aug 2005, broken link's image removed.