Anyhow, I decomposed the implementation of methods into two parts. One is to provide inputs and gather outputs from the methods. We have to understand very vividly how method IO works. Once you understand that life becomes extremely easy for us. For, what remains after that is to implement the logic of a method.

What goes inside the body of methods? Well, some methods are simply one-liners. They simply print a message or return a value. In certain cases, they apply a mathematical operation to a variable and return it. Sometimes, you have to perform disk IO. When methods become a little more complex, they contain some loops and rules employing switch statements and structures containing if/else rules. All of this should be a trivial matter if you have been exposed to even a little bit of programming at some point in the past.

Where does the logic for implementing such kinds of method functionality arrive? Well, it really requires some thinking effort on part of the developer. You have to understand the functionality promised by a method by reading the requirements specification document or the design document. Depending on that, you implement your logic.

In computer science, we are taught all sorts of courses that involve some kind of problem-solving. A course on data structures and algorithms is a nice example of that. Sometimes we simply fail to appreciate the greater benefits such algorithms can yield. More dynamic students simply trash the contents of such courses as mere brainstorming. Such courses are nonetheless important as they provide us with valuable tools for thinking and implementing solutions to small problems. A propensity for such problem solving can help you a great deal in implementing your methods.

Some methods would require functionality that you cannot easily fathom. Consider a flyPlane method that takes in over a dozen inputs and outputs a handful outputs. The job of such a method is to fly a plane in adverse conditions. How would you implement the functionality of such a method?

Indeed, it may be impossible to conceive the code for such a method. It is for this kind of methods that machine learning plays a handy role. And we shall begin talking about that in due course.

Photo by shinya

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

You can use this jar file in many of your applications. You can even use it in different environments. For instance, both Matlab and octave maintain a java virtual machine when run. It means that you can run any executable program using either of these applications. Both of them also allow you to call java objects from third-party programs and applications. You can import your mathematical functions library we were talking about in the last paragraph and call its objects in Matlab and Octave. Eventually, you can utilize all of the publicly available functionality of its objects in these programs. Libraries are beneficial. For one thing, they save you from a lot of reinvention of the wheel.

What, then, are frameworks? This question has had me thinking intermittently during the past couple of days. I read in Timothy Budd’s lecture slides on object oriented programming that they are “shrinkwrapped” versions of code. What does this mean? An intuitive way to think about them for me was to imagine that frameworks enwrap huge programs that the programmer can use to get things done. This way of thinking about them has helped me, but I cannot explain this idea still very vividly. Another thing that was hinted at by Budd was that libraries address, and eventually allow you to access the objects from a very low level of abstraction. Frameworks, on the other hand, allow you to use programs and their objects from a very high level of abstraction. This further refines the thought process about frameworks and libraries. But I still have to find a better way to explain this. I shall keep on finding ways to sound more eloquent on this topic.

I read elsewhere on the web that you can use libraries and their objects and still keep control of the program that you are writing. Frameworks, on the other hand, take the control away from you. Similarly, another explanation was that the frameworks combine together a lot of applications and provide you a skeleton for a mammoth application. You fill in the code to connect the various parts of the skeleton together and get the code working.

In the interim, I would like to draw your attention to the following web resources to grasp a better understanding of these.

Library vs. Framework?

What is the difference between a Java Library and a framework? The two concepts are important but sometimes confusing for Java developers. 1. Key Difference

Photo by sk8geek