Software Engineering Journey: On The Heap

Conceiving ideas has never been a big deal. Especially in our times, with the advent of computers and the things that have been made possible with them, thinking about novel ideas has become commonplace. Moreover, we have valuable tools for thinking about ideas and their materialization. Nowadays we can develop for any idea

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