My friend bruno started a thread about interfaces and abstract classes and I wanna continue here. I totally agree with his points and I’m adding other ones here. About interfaces:
- define a communication “protocol” between classes.
It is, a class which has an interface as a colaborator knows which operations it can send messages for this interface;
- isolate the clients from the implementation.
So, you are free to change the internal structure of your implementation and the clients don’t have to concern with this. So, we are applying the hiding mechanism here, known as encapsulation;
- clients don’t have to concern with implementation details, because they only work with the interface. The real type doesn’t care for the client;
- define the form for a class. More precisely, is what the classes look like while the implementation says how the classes work.
About abstract classes:
- describe an incomplete abstraction definition, as interfaces do;
- define a common interface for all the subtypes;
- establish a basic form, so it’s easy to say what’s in common between the subtypes;
- express only a interface, not a particular implementation
Interfaces and abstract classes are ways of managing the internal coupling of your code. You create them when you want to manipulate classes through this common interface. If you only want to factor behavior, interfaces are a good choice, but if you want to factor structure too, choose abstract classes.
Have you ever been told about GRASP patterns? Those kind of patterns are part of the design discipline of the unified process. Their goal is to assign classes responsabilities around the system. We can say GRASP patterns help objects and theirs collaborators to apply the correct behavior as well. I think the most important GRASP patterns are:
- Specialist: put the responsability in the class with the specific knowledge. For instance, in a monetary system, as the account has the information of the balance value, the withdraw() method has to be put in this class.
- Creator: helps deciding who creates the object. If there is an association, aggregation or composition relationships, put in the composed object the responsability to create the other object.
- High Cohesion: classes have only and exact one responsability around the system. Presentation classes don’t have to know persistence classes. It’s a measure of affinity and overloading responsabilities within classes. For instance, in the same monetary system, the Account class only withdraw() money and not saves this information in a persistence mechanism, a collaborator can do this for the account object.
- Low coupling: measures classes dependencies within its context. Classes don’t have to be very dependent on its context. For example, if I have to change my database design, I have to change my business objects also.
- Controller: objects responsible to handle assynchronous event messages originated from GUI. Those can be the use case representation, a system or a subsystem, etcetera… They have the responsability to coordinate tasks and interactions between business objects.
Do you apply GRASP patterns on your software designs? To know more GRASP patterns, checkout this.
“It’s not enough to write tests for an API you develop, you have to write unit tests for code that uses your API.”
Some months ago I was wondering what was the benefit of using thread groups, which is a container of threads in Java. Reading Bruce Eckel’s Thinking in Java, I discovered this quote from Joshua Block, the one who improved the Collections framework in JDK 1.2:
“Thread groups are best viewed as an unsuccessful experiment, and you may simply ignore their existence.”
I haven’t been told about any Sun’s official statement about this topic before reading the book. So, why do they let us spend our effort trying to figure out the value of thread groups? 🙂
What do java programmers version control? is a good question to ask ourselves in the corporate world of software development. I think we should version control all the stuff regarding to the project knowledge, such as documents, wireframes, prototypes, notes, requeriments and obvious, source code :-). If you have a wiki available, documents about the project can be put and edited there. I think the build process has to take care of creation and manipulation of other dependent libraries, they should not be versioned. At my company we use Ivy, a java based dependency manager for this purpose. I haven’t been told about this tool before but I found it quite interesting to work with dependencies. You can even specify which version of a specific jar you need, Ivy finds the correct version and applies it as a dependency to your project. It seems to be very useful to manage the dependencies of software projects. And in your company, what’s your team allowed to version control?
James Bach has a interesting opinion about testing software systems. I think it’s a different opinion from any team project manager or developer. He not only emphasizes the importance of testers but says developers are trying to test software themselves, andfix every bug, before testers even got their first look at it. His software test heuristic is if it exists, I want to test it, even if the product is completely inoperable, with a lot of buggy code. A different opinion, even from mine. As a software developer, I would think to test it before delivering to testers 🙂 . And in your company, are there software testers? What do they think about it?
From Bruce Eckel’s Thinking in Java book, about threads:
- If you need to synchronize one method in a class, synchronize all of them. It’s often difficult to tell for sure if a method will be negativelyaffected if you leave synchronization out.
- Be extremely careful when removing synchronization from methods. The typical reason to do this is for performance, but in JDK 1.3 and 1.4 the overhead of synchronized has been greatly reduced. In addition, you should only do this after using a profiler to determine that synchronized is indeed the bottleneck.
Eclipse Callisto is available! You can download it here. Eclipse 3.2 build has been released too. Check out the New and Noteworthy.
Wikinews has reported a new web search engine called Jatalla, which uses only user generated submissions as results, is coming soon. It’s a different approach from the search engine leader Google, which rank relevance based in sites that link to a given web page, according to the PageRank alghoritm. Let’s wait for the beta version of the search engine, expected to go out in July. One interesting comment is in Jatalla’s FAQ, which says “If you believe (as do we!) that humans are still smarter than computers, you have come to the right place.”
My friend Marcel Ferreira sent me this article which says Google is building two brand new data centers, as big as two football fields, on The Dalles, Ore. Google’s increasing power is reflected in the location of the data centers, near to a hidroeletric dam, in the Columbia river. Nice is “The cooling plants are essential because of the searing heat produced by so much computing power” :-).