OO Development 6 – Design

View more presentations from randyconnolly.

OO Development 5 – Analysis

View more presentations from randyconnolly.

OO Development 4 – Object Concepts

View more presentations from randyconnolly.

OO Development 3 – Models And UML

View more presentations from randyconnolly.

OO Development 1 – Intro Object Oriented

View more presentations from randyconnolly.

Towards a smoother project transition

Disclaimer:

All the challenges and solutions presented in the article below have evolved out of my experience I have had till date working with a single customer project. Hence at times, you may feel that my thoughts are getting narrowed down and their applicability to a large number of projects, is fading out; don’t worry. Any such outcome is purely the result of my lack of experience of having worked on diversified projects.  Hence request you all to take them with a pinch of salt.

In my previous article [Things to watch out for during a development project] I had shared with you all the challenges we faced while executing a development project. This article however focuses on challenges I see in dealing with the transition phase a project.

• Overcoming the inertia and accepting  the changes more realistically

This is probably the first thing everyone in the team, right from the developer to the manager, should come to terms with. They ought to appreciate and then accept the fact that development phase of the project phase is over, and the project has now entered a new phase, the maintenance phase. It is very important to understand that a development project and a maintenance project are not the same. Maintenance projects are a different ball game altogether. Hence it calls for a change in approach to day to day tasks from everyone in the team.

Challenge:

How can the team ensure the time lag involved in adjusting to the new phase of the project is minimized?

Possible solution:

• A formal kick off meeting that involves all the stake holders to define the roles and responsibilities of each team member clearly, at the earliest, definitely helps.
• Bringing in awareness in each team member about various aspects of the project like the new reporting structure (changes if any), SLA, roles, escalation process, etc.

• Handle project exits gracefully

The transition phase of a project is also the phase of the project where people move in and out of projects. This is one aspect of project planning which has always seemed to be very mysterious to me. One question that always haunts me is, “Why can’t we handle project exists gracefully?”

Challenge:

How can frictions involved in handling project exits be handled with grace?

Possible solution:

• Why does a friction arise in the first place? One reason that comes to my mind quite immediately is expectation mismatch. I sincerely feel that if there are enough avenues and channels created in the project, for every team member to reach out to their manager for discussing their short term and long term career plans, we can definitely minimize the friction involved in project exits and have smoother transitions.
• Project transitions can also be looked at as an opportunity in disguise. What kind of an opportunity am I talking about here? A project transition offers a great opportunity for the organization in general and a project in specific, to show great levels of maturity in terms of their approach to handle the talent pool, respecting the career aspirations of its people and show highest levels of professionalism in handling project transitions. Think about it.

• Who says only developments projects are challenging?

It’s quite a common notion that a development project is usually more hectic and challenging when compared to a maintenance project. While I agree with the hectic part of it, I feel a maintenance project can be equally challenging and sometimes even more.

Challenge:

The most challenging aspect of a maintenance project (I am specifically referring to the one where the maintenance team has access to the code base) is the ability of its team members to dig through other people’s code, understand the system end to end, and also enhance it. All this expected, with a caveat that it must not break the existing system.

Possible solutions:

• I sincerely feel that efforts should be made to equip team members with more than just good coding skills to work effectively in a maintenance project. This may call for providing programs that would benefit the team members to understand the project life cycles better and cope with them effectively.
• A maintenance project puts to test, one’s ability to do impact analysis before carrying out enhancements. It also demands quick learning abilities since not all project have the luxury of time to ramp up for support. Hence team members should be able to ramp up really quick.
• You would also agree that very rarely would a project have the luxury of retaining the entire development team in the maintenance phase too. Hence ensuring that all arrangements are made to equip new joinees with the necessary knowledge transfer is quintessential. This is also one area where we can explore for innovative techniques to achieve it.

• Drawing a road map for every team member is as important as drawing one for the project

As most of you would agree, project interviews are one of the widely used techniques for recruiting new team members for a project. A project interview is often carried out against a requirement, and for a designated role.

Challenges:

• As the time progresses and project grows in size, how can the project ensure that it can cater to the changing needs of its team members and to an extent the project itself?
• What can be done to make sure people are clearly informed of where their career is heading towards?

Possible solution:

• As the project grows or starts to hint any growth, it is very important for the team to assess the availability of new opportunities within the scope of the project and communicate the same to the team members. By doing so on a periodic basis, each team member gets a chance to make informed decisions when it comes to continuing with a project or to move on to a newer one. It works in the favor of both the project as well as the team member(s) in question.
• Most of the times when the organization wins a client and spends considerable time in knowing the customer and their business, they utilize the opportunity to draw a road map for the client so that it helps the client know how the organization can help them grow. I am always amazed why the same cannot be applied to a project. Look at this way. If a project has team members and they have spent considerable time in the project, why shouldn’t a project to draw a road map for such team members? I am sure it would help the team members, the project as well as the client since everyone is aware of the kind of roles or responsibilities them team members would taking up, going ahead. The project can also carve out a suitable space for them.

You may ask. What about a team member who is recruited for a short term requirement? How can a project chalk a road map for such team members?

I think it can be addressed in the following ways:

• I understand that it is practically impossible for projects to draw a career road map for such a team member within the space of the project. But it would not be a bad idea to discuss and understand their career aspirations since any such matching opportunity found in future can always be offered to the team member.
• Another way to address this issue is to avoid short term recruits (I know I am deviating from reality here) for any project, purely in the interest of both the project and the team members. A project team must plan such recruits only if gets really inevitable.

 P.S. In the end I feel this phase provides a great learning opportunity to everyone associated with the transition phase. It’s just that we must be open to learning from such experiences and works towards smoother project transitions.

Ways to implement Singleton Design Patten in Java

Of late, I have been going through Effective Java by Joshua Bloch and I must say, it’s one book every java developer must read. Josh has collated 78 best practices of java in this wonderful book. What I really appreciate about this book is the succintness and no-nonsense way Josh puts forth each of his learning in front of the readers.

There is an item which discusses about techniques to enforce singleton design pattern in java. I have illustrated below a few techniques to achieve the same.

 Technique 1: The “Eager instantiation” approach

1. Declare a class with a public static final field and intialize with a new instance of the class which is intended to be made singleton.
2. Declare a private constructor to limit clients from direct instantiation of the class.
3. All clients of this class will get an instance of the class using the public static final field.

Here’s how the singleton implementation would look like:

package com.corejava.examples.singletonimpl;

/**
 * Implementation of singleton design pattern – Technique 1
 *
 */
public class SingleInstance {
// Expose the instance of the singleton class as a public static final field
// of the class.

public static final SingleInstance SINGLE_INSTANCE = new SingleInstance();

private SingleInstance() {
// To prevent direct instantiation by clients
}

public void methodA() {

}

public void methodB() {

}

// … Rest of the methods of the singleton class go here

}

Advantges of this approach:

• Fairly simple and straight forward to implement.

Disadvantages of this approach:

• Creates an instance irrespective of whether or not the clients need an instance of this class.
• Violates encapsulation since the clients would be aware of the internals of the class.
• It makes code less flexible to design changes if you decide to move away from the singleton restriction in future since it brings in code change both at client side as well as the singleton class.
• Susceptible to attacks by reflection.

 Technique 2: The “Lazy instantiation” approach

1. Declare a class with a private static field.
2. Expose a synchronized static factory method to return an instance of the class (instantiate only if requested by a client)

Here’s the implementation for the same:

package com.corejava.examples.singletonimpl;

/**
* Implementation of singleton design pattern – Technique 2
*
*/
public class SingleInstance {

private static SingleInstance SINGLE_INSTANCE;

private SingleInstance() {
// To prevent direct instantiation by clients
}

public static synchronized SingleInstance getInstance() {
// Instantiate on a need basis and return the same instance for all
// subsequent calls.

if (SINGLE_INSTANCE == null) {
    SINGLE_INSTANCE = new SingleInstance();
}
return SINGLE_INSTANCE;
} 

public void methodA() {

}

public void methodB() {

}

// … Rest of the methods of the singleton class go here

}

Advantages of this approach:

1. Lazy instantiation of the singleton class.
2. Promotes encapsulation by hiding the internals of the class from the clients.
3. Gives flexibililty to move to a non-singleton approach without any code change at the client end since all clients access the instance via a common public method.

Disadvantages of this approach:

1. Susceptible to attacks by reflection.
2. Additional code required. (Not much of a disadvantage)

Technique 3: The Enum approach

package com.corejava.examples.singletonimpl;

/**
 * Implementation of singleton design pattern – Technique 3
 *
 */
public enum SingleInstance {

//Declare the enum constant

SINGLETON_INSTANCE;

public void methodA() {

}

public void methodB() {

}

// … Rest of the methods of the ENUM go here

}

Advantages of this approach:

1. Enums are singleton by default.
2. Every enum impliciltly extends from java.lang.Enum which implements Serializable interface. Hence enums provide an implicit serialization mechanism. Thus any even after serialization and deserialization of an enum class, the enum instance obtained is same as the one before serialization.

Disadvantages of this approach:

1. Enums are not extensible. (They were not meant for extension. Refer the sun microsystem java docs for enums for more info. However you may emulate multiple inheritance with enums by implementing multiple interfaces).

Hope the techniques mentioned above help to understand the merits and de-merits of each approach while implmenting the singleton design pattern in java.

Swap 2 numbers in java without using a temporary variable

I had tried out a few approaches while programming in C. A friend of mine happened to ask me the same. So thought of posting possible approaches here..

/**
 *  Program to swap 2 numbers in java without using a temporary variable
 */
package com.corejava.examples.pkg2;

public class SwapValues {

 public static void main(String[] args) {
  swapValByAddSub(2, -3);
  swapValByMulDiv(2, 5);// Fails when one or both the value(s) is 0
  swapValByXor(7, 8);
 }

 private static void swapValByAddSub(int a, int b) {
  System.out.println(“[swapValByAddSub] Before swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
  // Use the add subtract operations to swap values
  a = a + b;
  b = a – b;
  a = a – b;
  System.out.println(“[swapValByAddSub] After swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
 }

 private static void swapValByXor(int a, int b) {
  System.out.println(“[swapValByXor] Before swapping: Value of A: [ " + a
    + " ] and Value of B: [ " + b + " ]“);
  // Use the bitwise EX-OR operations
  a = a ^ b;
  b = b ^ a;
  a = a ^ b;
  System.out.println(“[swapValByXor] After swapping: Value of A: [ " + a
    + " ] and Value of B: [ " + b + " ]“);
 }

 private static void swapValByMulDiv(int a, int b) {
  System.out.println(“[swapValByMulDiv] Before swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
  // Use the multiply divide operations to swap values
  a = a * b;
  b = a / b;
  a = a / b;
  System.out.println(“[swapValByMulDiv] After swapping: Value of A: [ "
    + a + " ] and Value of B: [ " + b + " ]“);
 }

}

The 2Cs of OO world – Cohesion and Coupling

Cohesion and Coupling – Look for the definition here and here …

Now that you have gone through a bit about Cohesion and Coupling in OO programming, I would like to share with you my own experience of identfying cohesiveness and coupling while you are actually out there implementing a java appplication. These will provide you pointers to figure out if you have violated either or both of the design principles.

Here’s a checklist for you of figure out if you have violated Cohesion:

1. Are you finding it hard to come out with a meaningful name for an interface or a class, that describes it completely and correctly?
2. Are you having problems coming out with a meaningful documentation of what each method in a class is doing or even worst, a class in question is intended to do? In others words, is the responsibility of a class well defined?
3. Is any method of your class doing more than what it is supposed to do?
4. Are the methods in a class functioning together as units to serve the overall purpose of the class in which they are declared?

 Here’s a checklist for you of figure out if you have violated Coupling:

1. Does one class of your application know more than it should about another class?
2. Are you passing data as parameters into the methods of your classes, which is more than what they require?
3. Are you finding it difficult to unit test methods of your classes?
4. Is a small change to one of the methods of your classes, impacting a lot of its clients?
5. Are the clients using the service rendered by a class through direct invocation of a service implementation or through an interface?

If you have found yourself answering in affirmitive most of the times, you have undoubtedly broken either  both of the above mentioned design principle in you application and should certainly revisit them to correct the same. I hope this checklist helps to make your code more maintainable.

I feel that the most simplest of all the ways to be sure whether or not you have broken a design principle or not, is to revisit the java docs of your APIs. Does it convey in clearest possible terms the intent behind your classes and its methods? If not, you must re-think your design.

As far as possible it is advisable to keep your classes “highly cohesive” and “loosely coupled”. In my view interface based programming is an excellent way of promoting ”cohesiveness” and ”loose coupling” (if defined diligently) between service provider(s) and  client(s).

P.S. Let me know if you have some more points to share.