Think about a problem that you have conceived an idea about and you want to develop a real product out of it. Object oriented paradigm provides us with a great set of thinking tools about how to implement ideas. According to this, you have to figure out the objects which make up your desired product or artifact to make your problem modular. You then get ways and techniques to develop an object-oriented design. Once you have done that, you have to implement that design into working software. The thing I am chanting the most these days is to highlight a roadmap from the conception of ideas to their object-oriented design and finally to working software. In this vein, the thing the idea I really like to shout about is to divide your implementation phase into two parts. The first is to derive skeleton code from the design. Once that’s done, the only thing remains is to implement the methods of objects. If that is done right, what you get is working software for the project you dreamed, provided that you also designed it well. The design is important than anything else, as everything depends on that.

There are other important things too. You have to gather requirements well. You have to conduct all sorts of tests. You have to prepare documentation. And implementing methods nicely and accurately is also required.

Implementation can be mind boggling if we don’t get a few things right in our heads. And this series of articles, that I am presenting as a journey through the labyrinth of Software engineering issues, is in its essence a reflection on issues pertaining to implementation.

In my previous article, I reasoned about the fact that all dynamic memory allocation is done on the heap. It would also be nice to know that all user-defined objects are normally allocated memory dynamically. If you read my last post, there are two things about object instantiation that must be understood. One is to instantiate the object itself, which is given a place to reside on the heap. The other is to assign the address of that object to a variable of the same type, that resides on the stack.

But what about an object lies on the heap? This is an important question, the answer of which should be understood. And if understood properly, this will make you an astute programmer. You may as well become a speed-programmer and go out to win so many programming championships.

In order to understand the answer to this question, we need to understand a few things about classes and objects. Well, but we all know a few things about classes and objects, don’t we? A class has a few fields and a bunch of methods. The fields determine the state the class is in at any moment in time. The methods influence the behavior of the class. This is the basic common knowledge that we acquire in the first chapter of almost every well-written text on object-oriented programming.

However, we don’t learn a few simple things readily due to one reason or the other. And our programming acumen suffers badly due to this lack of understanding. One among them is the question about object instantiation. How are objects instantiated? If you understand the answer to this question, you will develop a lot of clarity as a programmer.

So when we do something like ‘Data data= new Data();’, what really happens? I reflected on a few issues in my last post. You must read that first and continue from here. So in a statement like above, the runtime environment of Java (remember I said that I am talking about everything from the vantage point of Java) creates a new object of type Data using the class Data. What do I mean by that?

What that really means is that when we run a program that is creating an object of type ‘Data’, the program loads the bytecode of the class into the memory. That bytecode is present in a Data.class file that you created while creating Data.java. The region of memory where the program is exactly loaded is called method area. It has all the compiled code of all the classes.

The moment you create an object dynamically, it is created on the heap. For all of its fields’, their values are stored in the respective blocks on the heap. All of the field names, method names and their bodies are still located in the method area. I want to emphasize here that the heap only contains values for the fields. These values can be changed by changed or accessed by having a reference to this object and the field names, which are present in the method area. When you try to access a method of this object, it is loaded from the method area to an appropriate place on the stack. From there it starts executing.

You already know the rest of the stuff about execution. Especially, since you have been reading the previous article on how dynamic memory works, nothing should be a big deal for you.

Photo by Polyrus

The first thing that we need to understand is that how methods receive and return inputs and outputs (IO). This is very important. The working of a method can be broadly divided into two types of tasks. One is to handle IO. The other is to manipulate inputs to generate outputs. This article particularly reflects on the first part i.e. how a method deals with IO.

To understand this, it will be very nice to remind ourselves that in Java all arguments to a method are passed by value. What this literally means is that if we have a variable ‘x’ to which we have assigned a value of ‘6’, and if we pass this variable as an input argument to some method (e.g. insertX(x)), then its value (6) is passed to the method call insertX(x);.

This is true about all sorts of method calls in Java, and all sorts of data types including primitive and abstract. But we need to understand a few more things about abstract or user-defined data types.

Consider the following variable declaration in Java:

int x=5;

The above declaration creates a variable of type int and assigns it a value of 5. x goes on the stack.

Now consider the following variable declaration:

MyDataType data;

The above declaration creates a variable of type MyDataType, which is essentially a user-defined data type. What is ‘data’? Well, data is a variable. Where is it located? It is located on the stack. What is its value? It hasn’t been assigned any value yet. How to assign a value to it? Following is the procedure for that.

data= new MyDataType();

What we have done above essentially is that we have created an object of type MyDataType (on the right-hand side of the expression). This object is allocated memory on heap since this is dynamic memory allocation (all dynamic memory allocation is done on the heap). The object does not have any name as such. However, it does have an address. And its address gets assigned to ‘data’ (left-hand side of the expression).

So the value of ‘data’ now is the address of the newly created object of type MyDataType.

Now, consider a method that accepts an object of type ‘MyDataType’. Let us consider the following method, for instance.

public class Example{
//
//

public MyDataType insertData(MyDataType data){
//
//
return data;
}
}

The method ‘insertData’ accepts an argument of type ‘MyDataType’. It also returns an argument of type MyDataType.

Now consider the following method call.

MyDataType data2=insertData(data);

where data is the variable mentioned and explained two paras above. Since Java is pass-by-value,  when we pass ‘data’ to ‘insertData()’, essentially we are passing the value of ‘data’ to the latter. But what is the value of ‘data’? Its value is the address of the object of type ‘MyDataType’, to which it is referring.

So the crux of the story is that when you are passing arguments of user-defined data types to Java methods, you are not passing the objects as such. In stead of this, you are actually always passing references to those objects. The actual objects keep on lying on the heap. Their references, that are stored in variables of the same type that are on stack get passed to methods. Same is true about return values. Objects are never returned. Instead, their references are returned. Through the references, objects can be manipulated as they keep lying on the heap.

This idea and its understanding can have a profound impact on your programming skills. Once you have developed skeleton code, the next thing you have to deal with is IO in methods. Once this is understood, rest of the stuff becomes easier to comprehend and implement.

Photo by Plutor