Sun announced it will start open sourcing Java by the end of this year, according to eweek. Sun plans to open-source firts the Java C (Java Compiler) and the HotSpot virtual machine, with the bulk of the rest of the code likely to follow in early 2007, including JavaME. Sun hasn’t decided which licence to choose yet, maybe GNU GPL (General PublicLicense) or CDDL (Common Development and Distribution License). What are the benefits of open sourcing Java? What do you think about the compatibility, if we have a lot of distributions of the technology? Nowadays we have this kind of thing with Linux distros, some are incompatible with the others. What’s your opinion about that?
Archive for August, 2006
Look at these Java code snippet:
1:import java.util.Date; 2: 3:class Movie 4:{ 5: private Date exhibitionDate; 6: private Director director; 7: private Persister persister = new Persister(); 8: 9: public boolean isDirectedBy(String director) 10: { 11: // some code here; 12: } 13: 14: public void changeDateWithDirectorApproval(Date newDate) 15: { 16: // some code here; 17: } 18: 19: public void save() 20: { 21: persister.save(this); 22: } 23:}
At the save() method, persister takes care of the responsability to update the current movie, saving it at the persistent environment (a file, a DBMS, any data source, etc..) . Some may argue this class has two responsabilities: the Movie is responsible for its own behaviour AND its persistence. ButUncleBob has an interesting opinion about the Single Responsability Principle (SRP). It says Movie actually is not implementing persistence, the persister is a collaborator of the class. The persister is hidden from the client of the class, that is, is not part of the public interface. So, the lose coupling and the encapsulation is preserved. If the persister changes, the clients won’t be affected. It concludes SRP is about implementation, not interface. But imagine if you wanna find a movie, you can’t do movie.find() 🙂 . So, you have to deal with another collaborator who knows how to find a movie. Couldn’t be the Persister? No, because this one is hidden from the clients and if you become it public, you would fail with the information hiding principle. In this case, I think it’s better a Finder object. And you?
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.
- isolate the clients from the implementation.
- 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.
It is, a class which has an interface as a colaborator knows which operations it can send messages for this interface;
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;
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.
GRASP patterns
Aug 6
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.