Sunday, July 15, 2007

Procedural or Object-Oriented?

The title might be misleading to some people, certainly, when you are writing Java code you are breaking things into objects. So, please let me define what they are about:
  • Procedural -- Code written in procedural and sequential style. Uses primitive types and common data structures. Multiple steps and conditions are defined in a single or few massive methods to reach program to a happy state.
  • Object-Oriented -- Code written in object-oriented style. Uses beans, DAOs, manager objects, etc. Code is constantly refactored, such as decomposing and using "extract method".
Recently, I have been working on some pieces of code and I came to a point to discuss with a friend this afternoon. He talked about the advantages of procedural style over overly-designed and object-oriented style, esp. when you are writing integration code and business process.

For example, in a procedural manner,


public MyActionClass{

public void doAction(){

Map vars = new HashMap();

if(condition1){
SomeClass.doSomething(vars);
SomeClass.doTransaction(vars.get("var1"));
}
else{
// .. Something similar
}

SomeClass.finalizeSomething(vars.get("var2"));
}
}

In an object-oriented manner,

public MyActionClass{

public void doAction(){

MyActionContext context = MyActionThreadLocal.getContext(); // Or a bean, or something similar

if(condition1){
doTransactionForCondition1(context);
}
else{
// .. Something similar
}

SomeClass.finalizeSomething(context.getVar2());
}

protected void doTransactionForCondition1(MyActionContext context){
SomeClass.doSomething(context);
SomeClass.doTransaction(context.getVar1());
}
}

Whatever above is just a very small piece of code, imagine in a class with complex business logic, how much they both can grow.

Maintainability is something subjective which I have to say. In a business world, code is subject to change as new requirements come in every day (expectedly). Procedural style coding might seem lengthy but it does not hide too much (object-oriented is a black-box). Object-oriented style coding is not unnecessary but not overly-designed and should be discouraged when you are working on something that is established or recognized by a group which you might handover stuffs to.

Your say?

- yc, fowler-ed then rob-ed

Sunday, July 8, 2007

Bloggers Buff 2007

Oh.. hi? So, I went to the Bloggers Buff 2007 held at Dewan Dato' Haji Sidek in Sunday arvo and I turned up pretty late for the forum/conference. I managed to join the session about "Responsible blogging and self censorship" by Dato Ahmad Talib, Ahirudin, and Li Tsin from MalaysiaKini.

I'm glad to be able to share a little bit about internal blogging (in a corporate), wiki and some Web 2.0 features.

Anyway, I'm sorry that I am bad in remembering names but I have to thank Rames as it was because of his blog that I discovered this event and some people who I had a chance to chit-chat with. I'd like to highlight the Think Rich Enterprise as well, although I am not a fan of blogging for $, it is interesting to see such company which helps driving the local people into the trend.

So, you might be interested with what I'm actually doing. I am employed by a Sydney based company CustomWare Asia Pacific as a developer and support engineer. Part of my job is to provide support to various Atlassian products. I love technology and technology makes our today.

There's one thing that I care much about is the growth of Web 2.0 in Malaysia. It does seem like a lot of its features haven't yet become widely spread and integrated into our daily practice.

It's time to back to Silverstone anyway ;-) (Massa is doing a good overtaking job). I'd love to see each other again soon.

- yc, silverstoned

Monday, July 2, 2007

Son oh son.. JSON

Learning a new techy stuff every weekend of mine seems to have turned into a real habit. JSON (or you can call it Jason ;-)), not something entirely new but it has been really hot these days. It stands for "JavaScript Object Notation" and it exists today is to make the AJAX programmers life easier.

I will briefly show you how you can get a hang of it using a simple JSP file and a small piece of JavaScript (YUI). If you do not have an idea about AJAX yet, you'd probably want to read about it first before going beyond this paragraph.

An AJAX response in XML format requires writing client code to parse it into DOM model, for instance:


<bean>
<name>foo</name>
<description>foobar</description>
<id>10000</id>
</bean>


Then some annoying JSDom bits to extract the data, which I'm not going to write. As I could recall, my last time of writing AJAX and DOM stuffs was a year ago for a Java webapp which requires validating the form fields by sending synchronous request to webMethods endpoints.

This might just be another article about JSON which you have read before from other sites, yes, it is. Anyway, a response can also be sent in JSON (which is basically string then be evaluated using JavaScript eval() method), e.g.

{"name": "foo",
"description": "foobar",
"id": "10000"}



Data can then be extracted easily unlike DOM, e.g.

var jsonObj = eval("(" + responseText + ")");
var name = jsonObj.name;


Before I end this blog so that you can find out more by yourself ;-), this is the JSP used to generate the response:

<%@ page
language="java" contentType="text/json; charset=utf-8"
import="org.json.simple.JSONObject"
%>
<% response.setContentType("text/json; charset=utf-8"); %>
<%
JSONObject jsonObj = new JSONObject();
jsonObj.put("name", request.getParameter("name"));
jsonObj.put("description", request.getParameter("description"));
jsonObj.put("id", new Long(request.getParameter("id")));
out.print(jsonObj);
out.flush();
%>
And this is the HTML used to send the request and receive the response:

<html>
<head>
<title>Test AJAX</title>
<script type="text/javascript" src="js/yui-2.2.2/yahoo/yahoo-min.js"></script>
<script type="text/javascript" src="js/yui-2.2.2/connection/connection-min.js"></script>
<script type="text/javascript">
function getAjaxRequest(url, callback){
return YAHOO.util.Connect.asyncRequest('POST', url, callback, "name=foo&description=foobar&amp;amp;id=10000");
}
</script>
</head>
<body>
<script type="text/javascript">
var callback = {

success: function(o){ alert("Successful: \n" + o.responseText + "\n" + o.getAllResponseHeaders)

var jsonObj = eval("(" + o.responseText + ")");

// Some reflection here
var jsonDump = "";
for(key in jsonObj){
jsonDump += key + ": " + jsonObj[key] + "\n";
}
alert(jsonDump);

},
failure: function(o){ alert("Failed: \n" + o) },
argument: []

}

getAjaxRequest("testJsonResponse.jsp", callback);
</script>
</body>
</html>

One final and common note though, if you ever come across designing a webapp with AJAX functionality, do keep the response format consistent, i.e. use application/xml OR text/json NOT both, so that you will not confuse the developers at another end of which they should expect.

- yc, raining