July 1, 2014

223 Views

The Art of ORGANIZING in different phases of project (Page I)

The one characteristic of ORGANIZING things can prove to be a very strong point in the programming domain and in fact to different areas of life. Organizing is an art and not everyone is equipped with it or uses it, but sharing knowledge pieces can stir the minds of people to pop out this art onto canvas. Here canvas indicates any area of your life, but we’ll specifically talk about the programming domain. Though this is a personality trait, but is a necessity in painless execution of project leading to a successful launch.

There are various in-places during different project phases where organizing helps. Let’s see those places.

The Namespace

The very first thing you need is a namespace.

Wikipedia Definition: A namespace is a container for a set of identifiers (also known as symbols, names). Namespaces provide a level of indirection to specific identifiers, thus making it possible to distinguish between identifiers with the same exact name. Read More.

Let’s understand this by an example of a bird’s nest: What would be the namespace of a bird in a nest, remembering that namespace should provide direction and identify it? If someone tells you that “I have seen a beautiful bird’s nest in the garden near Software Tower of HCL’s SEZ zone, the direction would be SEZ > Software Tower > Garden > Tree > Nest > Bird. So the Nest here defines namespace where the bird lives and can be identified.

In case there are multiple nests, more granularity can be added as SEZ >Software Tower > Garden > Tree > Trunk > Branch 2 > Nest > Bird to uniquely identify it. To a more universal level, it can be defined as Earth > Asia > India > UP > Noida > HCL SEZ-126 > Software Tower > Garden > Tree > Nest > Bird. To which level you want to cut down a namespace depends on the necessity.
Everything in the entire universe; physical, virtual or a concept has got a namespace for sure.  Namespace contains or owns objects. Namespace is one point before the actual object you want to locate. Namespace depends upon the context of use.

Let’s say your manager has asked you to create a sample project to showcase the audio playing capabilities in Java technology. You can name the project as AudioPlayer and a probable package structure can be like this com.hcl.uxd.ria.java.samples.audioplayer. This package structure defines a namespace for the AudioPlayer project. It provides complete information of organization, department, branches within the department and the technology. There is no need to universalize this namespace to find HCL under planet Earth as we don’t need that. This is one of the important places where you apply the art of organizing. Now, let’s see it on coding level.

Programming – When you code

Let’s continue with AudioPlayer project containing a set of requirements:

  • Audio Player shall provide a way to show multiple playlists.
  • Audio Player shall play a song from a playlist.
  • Audio Player shall provide controls to play/pause a song.
  • Audio Player shall provide controls to play next and previous song in the playlist.
  • Audio Player shall display song information like album, artist, year, rating, and lyrics.
  • And more...

Looking at the requirements, we have the following interim inferences

  • Audio Player having controls like Play/Pause, Next, and Previous buttons.
  • A number of playlists to choose from.
  • A number of songs in a particular playlist.
  • Information about song being played e.g. album, artist, year, rating, and lyrics.

This can be described as follows: Audio Player contains playlists. Playlist contains songs and Song contains information about the song. Here is a pictorial representation to show the major components and their hierarchy.

In every technology-language, there are design patterns which speak about view and data parts of core components. In different technological domains, this data part is referred to as a Data Object, Value Object, Domain Object, POJO, or the Model itself and creation of this data part is a common part in any project especially MVC or its derivative design patterns.

Seeing that we have the following data objects:

public class AudioPlayerDataObject() {
private ArrayList

 

 public class PlaylistDataObject () {
private ArrayList

 

 public class SongDataObject () {
private String album;
private String artist;
…

public SongDataObject (String album, String artist …) {
	this.album = album;
	this.artist = artist;
	…
}
// Getter and Setter for each individual property.
}

You may see how data objects use each other and encapsulate the information within. You'll be able to come up with these structures based on how you converted requirements to major components and organized them. Though it's a small set, but is an organized set of data objects and structures. The data objects here follow the same hierarchy that we used to identify components. This is like flowing down your organization to the data object parts. Similarly you can flow down to the view parts of the project, in code comments and even when explaining your project in a document.

Whenever a requirement is specified as “A number of…” it means that you should use array-like data structure to hold values.

The above classes uses Java’s Generics feature. Generic is what you see in angular brackets e.g.

Change in requirements

Now let’s see what happens when there is a change in requirement which disturbs our hierarchy of components. A new change in requirement comes up to extend our application to have video playing capabilities.

  • Video Player shall provide a way to show multiple playlists.
  • Video Player shall play a video from a playlist.
  • Video Player shall provide controls to play/pause a video.
  • Video Player shall provide controls to play next and previous video in the playlist.
  • Video Player shall display video information.
  • And more...

Converting these requirements into major components, we have almost same components and hierarchy as in Audio Player.

Now the exercise is how you organize two different set of requirements in a way that your application looks organized and finding components that are common.
In the Art of ORGANIZING, there are few important aspects, you may call them rules:

  1. Parenting – Always provide a parent to similar features to complete the hierarchy.
  2. Uniqueness – Find components which are unique and can be generalized in the hierarchy.

Let’s apply them on the change in requirements.

The Art of ORGANIZING Parenting: In order to have both the players having almost similar features sit in the same application, there should be a parent containing both of them, we call it as Player. In terms of namespace, the Player acts as a namespace to identify different players uniquely as different branches.

The Art of ORGANIZING – Uniqueness: We’ll continue organizing to find what all components are common and can be generalized in the hierarchy. How about Playlist? The role of playlist seems to be same in both the players and we should generalize it.

Here are the hierarchical changes:

Organizing similar components under a parent can indicate other components to also go under the art of organizing.

This should be clear by understanding the following code changes, Audio Player has got a play(SongDataObject song) method which when called would play the song. Video Player would also expect video data object in play(VideoDataObject video)method. At the level of action, both of them are doing the same and it should give you indication to organize it in a common class Player. When you move play() method to the Player class, you can now no more specify the parameter’s data type as SongDataObject or VideoDataObject and even name the parameter as a song or video because Player doesn’t specify what kind of player it is. This should give you another indication to continue parenting to data objects as well.

In the hierarchy, see that Song and Video components are at the same layer and without any parent, which makes their usage less generalized and less scalable. Let’s organize them under a parent and give it a generalized name, PlayItem. You may now safely use PlayItem class in the Player class for the above code change.

Such grouping would provide unmatched advantages by truly making your project scalable and more open to receive changes. This hierarchy looks conceivably complete and is generalized enough to accommodate more changes.

Please note we are not paying deep attention to design patterns, programming strategies and use of sophisticated tools to create hierarchical diagrams. We are trying to portray the building blocks that would come to your thoughts on seeing the requirements, which are not biased with the use of patterns, tools, and processes. We are using very simplest shapes to create a rough but realistic hierarchy and that ways it would fit nicely in object oriented world of programming.

This exercise also helps to find if the project can be divided into sub-projects or modules. For example, requirements to have Admin section to configure player options can be taken up as a different module. Decisions taken at this level will clear off many complex issues that would otherwise arise.

Mold into code using OOP concepts and design patterns

Later on, using OOP concepts along with design patterns, you can bring out the pictorial hierarchy to a concrete implementation in code.

You can apply Inheritance as is clear from the parent-child relation of the components. This inheritance can flow to their data and view parts.

You can apply the Factory design pattern at the Player layer so that it is easy to create any type of player.

In Factory pattern, as name suggest, is a place to create some different products which are somehow similar in features yet divided in categories. Read More.

Detailed information on which design pattern to use to implement a particular layer of hierarchy and how to wire OOP concepts like Inheritance from abstract classes along with Method Overriding to create a contract which similar components (here AudioPlayer, VideoPlayer) will adhere to is out of scope of this post.

Another change in requirement

Let’s change our requirement one more time. What if you need to add a slideshow which shows a run of images? See how easy it is to accommodate changes like that. These changes are now easy to accommodate because we re-organized our application to make it more scalable in our last change in requirement.

Sequencing – Maintain a consistent order throughout

Sequencing is another aspect of the Art of ORGANIZING which I later found it worth to include in this post. I’ll not write about sequencing much which may need another few pages, but would explain in simple terms.

Sequencing means to maintain a consistent order throughout the project. Let’s say a song have following properties: album, artist, year, rating, and lyrics. Sequencing here is that album comes first, artist comes second, year third, and so on. So when you consume this data from any data source e.g. database or XML or JSON, it should maintain the sequence. The properties of class to hold this data should be declared in the order, the code statements where you assign this data to properties, at the time of updating properties, while formatting them to XML or JSON to send them back to server, at the time of writing queries and any other code area. This brings more clarity to the thought process and reduces code clutter.

Continue to the next page of the blog...