Friday, February 25, 2005

Delta Classes and my thoughts

Just read Avishek's post on delta classes. This got me thinking. Delta classes as defined by Avishek are basically Deltas in the classic sense of the work. They denote differences. So if we had such classes we might be able to get away with one start class and many delta classes being applied in various orders or number of times to generate all sorts of classes and code. We might even be able to get to the holy grail of mathematically proven code using lambda calculus.

Let us now assume for the sake of discussion that we have a framework which accepts and understands an initial class and many delta classes and a set of mathematically correct rules (ok...ok..there will many of them) to apply on these delta classes to acquire a set of useful classes and operations. Now whenever a transition is applied it can be proved that the transition is mathematically correct as the general set of rules to be applied are proven to be mathematically correct (including the order and number of times they are being applied). For this maybe one just needs to prove that all the rules are derivatives of alpha,beta or gamma reduction/deductions. This is non-trivial but not too though. If we keep out things like dynamic typing maybe we will get mathematically proven correct programs.

Monday, February 21, 2005

Dining Philosophers and XP : Part 2: The first Iteration

hey, the title seems like a Star Wars movies' one.

So I went ahead and implemented all the features to be implemented in Iteration 1. I also did the factory implementation as I wanted to use it as the framework for holding the relationship between philosophers. Is this done normally?

I basically have a Factory for making Philosophers, a Philosopher class which extends the Thread method and a Chopstick class and corresponding Test classes. I am planning to use the new utils.concurrent package (J2SE 1.5 aka 'Tiger') to implement threading in the 4th Iteration. As expected Deadlock happends. This will be removed in the next round. I think the code 'smells' with methods like:

public boolean setRightChopstick() {
int id = (Math.abs(getPhilosopherId() + 1) % 5);

if (PhilosopherFactory.getPhilosopherById(id).hasLeftChopstick() == true
&& PhilosopherFactory.getPhilosopherById(id).getLeftChopstick()
.isInUse() == false) {

PhilosopherFactory.getPhilosopherById(getPhilosopherId()).hasRightChopstick = true;
csRight = PhilosopherFactory.getPhilosopherById(id)
return true;
return false;
What do you guys think about this?

I collaborated for the most part with my bro' Krishnan (aka 'kannan') on this round and he also plans to come with me for the Agile India conference. I want to release the whole code through a public URL of a .zip file. What is the best way to do this? The most I could come up with was as .zip file hosted in site.

Code is here

Tuesday, February 15, 2005

Dining Philosophers and XP : Part 1

For my latest XP/Agile project I along with Partha chose the Dining Philosopher's (DP from now on) problem. After choosing it I saw the Dining Philosophers Challenge. We decided this is the perfect thing to do. Debunk the doubts against Test Driven development through a real life solving of a non-trivial problem. We also plan to use this opportunity to use the various design patterns we hear about. We will be doing pair programming together for the first time and I think we will get to spend only about an hour everyday on this project. So the Velocity is going to be pretty low.

In the first iteration we plan to do the following:
  • set up junit with eclipse
  • set up build structure and ant files
  • get basic functionality of DP with deadlock acceptable
  • a good commenting format
2nd iteration:
  • Factories of philosophers and getting the reference of philosopher by ID.
  • refactor code to remove all setters and getters
  • do setup and cleanup methods in junit classes and remove constructors for classes from all test classes
  • state pattern implementation for Chopstick and Philosopher
  • resolve deadlock
3rd iteration:
  • Implement Observer pattern for notification of lock capture and release
  • Implement fair-scheduler of threads
4th iteration:
  • minimising waiting time for chopsticks
  • maximing thinking time of philosophers
Any suggestions?

Monday, February 14, 2005

Fresher Recruitment in my Organization

Before we start this post let me make something clear here. I am Sundar, an ex-colleague, ex-roomate and close friend of Suresh. Suresh works in ThoughWorks. I still work in Suresh's ex-company and this post is about the fresher recruitment process in my company.

Another disclaimer: Since we don't want another Mark Jen episode here, I want to say that if anybody feels I am writing something which hurts them or my company please tell me about it and after a reasonable conversation we can do something about it. All the information expressed here about this recruitment process is in public domain so I don't expect any problems to occur.

Last weekend I was invited by my company to be on the interview panel for freshers recruitment. The candidates have all given an written aptitude test and a computer-language specific multi-option written test. Then they were given a 24-hour notice that the next round of interview will be on design patterns in general and a particular design pattern whose information is supplied to them. They are also given a couple of pages info on that particular DP. The idea here was to check how a candidate is able to absord information and learn about an abstract topic in a short period of time, apply it to a problem and express his thoughts on the subject. In the interview they are asked to apply the design pattern they have learnt to real world non-software related topic. For example: Singleton patterm == Office of the President of US.

Initially I had hesitations regarding this methodology as I thought asking about DP to freshers would be futile as I didnt expect them to know much about it. But I was pleasantly surprised. There were lots of candidates who understood the procedure very well and came up with some real world examples which we had not thought of (like Osama Bin Laden being a subject and the world being observers in the Observer Pattern). They expressed the thoughts very well and we ended up selecting so many of them that we set a record for maximum number of selections in a session till now. All though the DPs were elementary ones it does indicate that sincerity, effort and ability make good candidates. Also this proves that exprience level is not necessary to get started on Design Patterns.

Monday, February 07, 2005

PatternShare and a request for help.

Today I came across the new MS initiative called PatternShare which basically is a repository of patterns. This is an extremely useful resource for newbies to pattern world like me. I have read some parts of the GOF book a year ago but didnt take home much from it as i barely understood many many things. I hope to make a renewed attempt to educate myself over the next few months in this topic.

Readers please suggest the best way(s?) to to learn the usage and application of various paterns.

Tuesday, February 01, 2005

thoughts on setters and getters

Yesterday me and a few of my colleagues had a discussion on the sanctity of getters and setters. I am I.;) I mean when its written I say thats my take on the discussion. Identities are preserved.

P Says:
Some time back I was going through an article where the gist of the topic was

“Not to provide getter and setter methods for manipulating the member variables”.

# The main reason for not doing that is, it’s not following the “Encapsulation” term.
When we are passing the member variable to another invoking object, the data is no longer
Encapsulated as the member variable can be manipulated by the other object, which they feel
Is not the real encapsulation.
What they are proposing is any manipulation of member variable can be done in the same class and
Any methods related to those variables needs to be provided in the same class.

After going through those lines, thoughts started bubbling out, which I can’t keep to my self.
So some doubts and approaches from my side.
# Generally we follow the get and set methods very often.
If we will not do in that way, then what should be the class structure will be.
Incase we need some functionality depending upon some other class variable then how we will do that.


D Says:
I am not quite sure of your scenario.

What I have seen…

Getters/Setters are used in Java bean or value objects sort of environment.

Ideally, these value objects should only be populated in the constructor for preventing data corruption. But in some scenarios, the value objects gets constructed at one place, gets partly populated at the same place and the rest of the data is set at some part of the code. What to do in this sort of cases?

In case you need some functionality based on some other classes’ variable, you can use a getter….. In this case also, u are not corrupting the data. The problem arises only when you use a setter. I don’t think using a setter outside a bean environment is good.

Any other scenario that you remember???
N Says:
Encapsulation doesn’t mean hiding data, it means encapsulating the related methods and data. So by putting getter and setter methods Encapsulation is still there. You should write this comment for that article, person who wrote this article must not knowing actual meaning of Encapsulation. But its right that if you provide unnecessarily getter and setter it can be mis-utilized but that is design level consideration. At the time of design one must be careful about what data require getter and setter, these methods can be provided with validation check before actually changing the actual data.

Regarding getting data from one class to other I think there has to be proper interface (can be getter or setter) or some data transfer objects which doesn’t carry full data but the part of data that is required.

I Say:
If you need to get some data from some other class one should use a pattern (maybe state pattern or something like that. I am not knowledgeable in this). Maybe this is a better method than getter.
D Says:
Why do we need to encapsulate related methods and data?
Is it because we need the data to be manipulated only by those method?
If this is the case, I don’t see why should we expose a setter method as public?
What say?
N Says:
We don’t have setter method always or for all member variables. Like before rendering you can set rendered object and then perform rendering, so user has flexibility to change the renderer before performing rendering but still logic for rendering is with actual class and it can’t be changed.
I Say:
Encapsulation can lead to data hiding which is a good thing as each class should have a secret (logic for rendering). An logical extension would be to make setters inaccessible from other classes or to say setters are sin (and make them non-public). What say people? Am I confusing issues here?

D Says:
I am not able to get the meaning of logic for setter methods? Setter methods are supposed to take in a parameter and set the instance data to the passed parameter.

So, if a setter is public, anyone can access that and set its value later on????/
D Says:
One of the advantages of using setter what I found is ….

We can put our logic in setters which we cannot do in constructors….Example, set the variable’s value only if its positive…..

So, even if we use a constructor we should call the setter from there…. Should the constructor be only private then????

Then some of us met over tea and discussed this phenomenon further.
The conclusions we came to were:
ideally getters should not be there. if data is contained in a class it should be used within a class. a private getter method can be used as an extreme case (to avoid code duplication compared to the case of getter method not being there).
ideally setting of values should be done in constructer. Else it should be done via a private method so that dubplication of code is avoided (same reason as for getters).

What do you all think?