The Franciscan Report

Messaging is the Right Way to Build a Distributed System

I couldn't agree more with this article. Messaging should also be considered in applications where there are many subsystems in order to prevent "point to point communications hell". For example, in a CRM system where it contains HR, Accounting, Sales, etc. they should be communicated with each other using messaging, and service oriented approach.

in software engineering fields, estimates are usually done in the beginning of a project/release cycle. some estimates are good others are usually
bad (see how to do good estimates?)
based on those estimates, sometimes it takes more or less for development team to complete the tasks. the importants of keeping the adjusted/actual
effort (in terms of hours preferably) to complete the tasks are as follows

- it makes good resources for future development estimation ( near or distance future )
- good for making cases for late project causes ( aggresive estimates number are most of the time the cause of late project )
- track the real costs of the project ( although this number can sometimes derive from timekeeping, but a lot of times time keeping numbers are not
well represented, ie. ppl don't usually separates their actual effort to this project with other daily activities)

Below is my code smells snippet of the day

public class RequestCycle implements IRequestCycle {

public void renderPage(...) {
page.renderPage(..., this);
}

public void commitPageChanges() { ... }
}

public class Page {
public void renderPage(..., IRequestCycle) {
....
this.commitPageChanges();
}
}

okay ... so we just b/c we introduce IRequestCycle doesn't mean that this code doesn't smell.

why would a class call other class and have that other class callback to another method in the originating class, especially at the end of the called method.

this is another sample of unnecessarily tight coupling introduce in a somewhat wellknown framework

There are a few criteria to identify a world class framework

1. don't expose the public interface unless you expect the user of the framework to overload it
2. force everything that should be overloaded to be an abstract method
3. Leverage template method pattern to support point #2
4. make classes and methods final if you don't want developers to overload it
5. document all of the extension points
6. document the execution flow of the framework if exists

any other thought?

i hate an overridable methods that force you to call its super method. OK beside the fact that inheritance is not encouragable, but to force the implementer of the subclass to know what's going on in the super class creates an even tighter coupling b/w subclass and its parent class

this problem is even more magnified when you're dealing with frameworks. Allowing the user of a framework to override method and calling its super method is going to be more problematic, since the implementer of the method couldn't modify the method at will due to unexpected side effects.

so what could good framework developers do .. see this
What makes a good framework

Josh Bloch on Design

A few things that I agree from Josh Bloch comments

- XP says "Do the simplest feature set that could possibly work, without overdesign, and extraneous bells and whistles" but do not "Do the quickest slop you can thrown down that could work possibly", which will suffer in the long run

A few things that I disagree

- API design is not the same as other non-API design, it requires much more effort and cost. Creating reusable components are much more expensive than especially if we're talking about community used API (ie. Java SDK, and so on) And to spend that much effort if we don't know for sure that the API's going to be use widely would be a waste. Afterall, components are not really reusable until it has been reuse multiple times. However, this doesn't mean that we would not have reusable objects within the System Under Development, constant refactoring by removing duplicates will promote it by itself, without the cost of trying to come up with a silver bullet API

Should one want to name a package based on a specific pattern name? For example, is it a good idea to collect all of the factories classes into one package. On the surface it looks like it's ok to group them by pattern, but if one of the rule of putting things in one package is to achieve high cohesiveness between classes in a package and to reduce coupling between other packages, then this idea is definitely not very sound.

Any other thought?

Should interfaces be separated into separate package than their concrete implementation?

I think a more important approach is the benefit of those separations. I believe that separating interface and its concrete implementation just by namespace/package but still deploying it into the same deployment package (jar or dll) then we lose a little bit of those benefits.

I would lean toward separating interface and implementation to two separate deployment package. They could have the same package/namespace name which doesn't really affect the intention of separating it.

For details on interface separation, please refer to "Interface Segregation Principle" pattern discussed in Robert Martin's book (Agile Software Development ...)