http://javaimage.blogspot.com

Project Title: Student Registration System

Project Team Members:
Chanda Dutta --------------IT054008
Smriti Bhattacharya ------IT054026
Sugita Kumari -------------IT054027

What do I expect to learn from this Project:
As Student Registration System was the project topic for few of our class mates in last semester, it is well known what the system is meant for. Apart from it, the syllabus describes what exactly needs to be done.

Well, moving ahead with the Object Oriented Programming paradigm and the ‘Student Information System’, I expect the actual implementation of the OOPs in the code which would further lead to the quality product exhibiting code reuse, flexibility, maintainability in the final product.

As we have already started with the System, we got to know about how to choose appropriate classes, CRC (Class Responsibility Collaborative) Cards, Associative Diagram and relationship between classes and subclasses, and Sequence Diagram, which are a few fundamental steps in going ahead with a project in its preliminary stage. We have already gone through the appropriate naming conventions to be adhered to enhance the readability of the code.

Moving ahead, surely we are going to explore the unexplored area of JUnit, Javadocs for better testing and documentation of the project respectively. Writing test cases and following it will lead to removal of the error at the very inception of the project, which would avoid further greater complications. Overall what I can expect is the industry standard quality product as the final output of the "Student Registration System".

Exception Handling

Exceptions in Java extend the Throwable class from the java.lang package. Basically the idea to have exception in a program is to handle the error condition in which we provide a mechanism for separating the error handling routine from the rest of the code and initiate the control flow transfer whenever an error occurs.
Looking at the Throwable class, the hierarchy is explained using the figure below;

In Java, Throwable class is the superclass of all errors and exceptions. Moving ahead with error and exceptions, Error subclass of the Throwble superclass denotes the abnormal condition when a dynamic linking failure or “hard” failure in the Java Virtual Machine occurs.

The Exception class is the superclass of all exceptions. An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions. Exception class doesnot define any method of its own.
Exception handling includes try-catch-finally construct and compile-time checking.

Throw- Throw statement is used to throw exceptions in a program. It means that the particular function is exiting and the control is given to the first catch statement. Any method capable of throwing exception is mentioned in the method signature. Once mentioned in the method signature, a method has no restriction on the number of exceptions that can be thrown.

Finally Clause: Looking at the flow of execution of “try…catch…finally”, we can say that try block is exited via finally. The flow exactly looks like catch…finally…return (to take out of the method). Finally can also be viewed as an acting default catch statement when no catch clause is mentioned.

Propagating Exception: There are certain cases where exceptions can not be handled and in such situation the exception is not handled, it is being propagated to the higher classes and finally if the main class also fails to handle the exception, its upto the Java Virtual Machine to handle the exception.

Runtime Exception: Most of the places we find “RuntimeException Handling – A Controversy”, its because we need to check these during design itself. Basically "Runtime Exception” is not because the system can not handle it or it can not be viewed as system failure but exactly it is because of the program failure as it was required to be checked beforehand.

!!Overloading considered harmful(cont..)!!

(Overloading and the problems associated)

Overloading affects readability of code in a rather negative way and it further leads to the weak maintenance of the program. It is generally confusing to predict the behavior of the overloaded method as a result of the interpretations which might take over the non overloaded methods of the class.
Use of overloading weakens the expressive power of client code as the polymorphic equivalence property cannot be relied upon.

Overloading significantly complicates things. Without overloading, one just works the way bottom up through the target's class hierarchy. The code to be reviewed is in a single flow. With unknown code or code known to use overloading, this can be only the second step. First, one needs to examine the class of the reference and find the matching method and then check the class hierarchy for overriding methods as in the case where overloading is not used. Thus as a result we need to add up a additional step.

Integration of overloading and inheritance
The poor integration of overloading and inheritance in Java is very misleading. Reference type dependence means that overloading is simply not developed to conceptual consistency in the context of inheritance. During run time, Java does not produce any kind of "flat form" for the object's class with all overloaded methods, inherited or not, appearing side by side in a list in order to allow the runtime to choose the most appropriate, this leads to a different behavior of the program from our expectations.
The compiler takes the method symbol plus the parameter reference types of some method call and calculates a position in the method table of the target's reference type. So, choosing between overloaded methods is done compile-time, and it is restricted to the overloaded methods of one class: the class of the reference type. Overloaded methods defined in subclasses of the reference type are never called: Java ignores the exiled siblings although the whole thing looks so very similar to overriding. Overloaded methods defined in subtypes of the target reference will not be taken into consideration as candidates for execution by the runtime. With the table position given in the bytecode, the runtime will only check if there are overriding methods. So, the compiler cannot hunt them down, and the runtime does not want to.

Overloading is a static compile-time feature which does not integrate well with expectations shaped by dynamic method lookup coming along with inheritance.
The difference between late binding and overloading can be pinned to the observation that late binding lets one method name to be the pointer to one operation contract, whereas overloading lets one method name to be the pointer for several method specifications whose differences can be experienced in the client code. In the scope of the client, there is no difference between polymorphic calls bound to different methods.
The polymorphic call specification is all the client has to know about the call. Overloaded methods, on the other hand, need not share common semantics, to be more precise, a common contract, their pre- and postconditions potentially varying wildly.
Overloaded methods can not be used interchangeably, as different methods just under the same hood they have to be treated according to their specific contracts. These contracts, however, are hidden behind the same name which makes them hard to identify. The same method name does not point to a common denominator in this case.

!!Overloading considered harmful(cont..)!!

(Program and Illustration)

To get to know the concept well and illustrate further the limitations faced while using Overloading, a Simple Program is used. This program has two classes:Superclass Top and Subclass Sub which inherits Top.

public class OverloadingTest {
public abstract static class Top {
public String f(Object o) {
String whoAmI = "Top.f(Object)";
System.out.println(whoAmI);
return whoAmI;
}
}
public static class Sub extends Top {
public String f(String s) {
String whoAmI = "Middle.f(String)";
System.out.println(whoAmI);
return whoAmI;
}
}
public static void main(String[] args) {
Sub sub = new Sub();
Top top = sub;
String stringAsString = "someString";
Object stringAsObject = stringAsString;
if (top.f(stringAsObject) == sub.f(stringAsString)) {
System.out.println("Hi!");
}
else {
System.out.println("Bye!");
}
}
}
Interpretations from the code:
From the above program we can get to know about the difference when we get to access the object and the string.
1.] There are two overloaded methods spread across a class hierarchy (one class inheriting from another class). This is the server code to be called by the client.
The superclass defines: String f(Object o).
The subclass defines: String f(String s).
The signatures are chosen to make both methods eligible candidates to be executed in the context of calls on the subclass instance with a String argument.
2.] The client provides two objects, reused for all calls and chosen in a way that both ov erloaded methods are potentially eligible candidates for executing the client calls.
3.] Through polymorphic assignment, the client obtains references of different types for these two instances.
4.] The client makes method calls that differ only in the different references used for making the call. In the given setup, there are 4 different call forms possible: Overloading has the method name fixed, so only the target reference type and the parameter reference type are variable. Every reference type for the target can be combined with every reference type for the argument.

(Next: Overloading and Problems with late binding & Inheritance)

!!Overloading considered harmful!!

What is overloading?

Generally how we define it is as "the same method name for different methods."
Sure it's one of the first things Java programmers are confronted with when learning the language. Things like: Do not mix it up with overriding - remember, these things may look quite similar, but are altogether different concepts- are generally told.

Often confused with the term Overriding, Overloading is quite different from the term Overridding. In case of Overriding, a method in the subclass has the same name and signature as a method in its superclass. Confusion arises just because the methods signatures involved in overloading look so similar.

What is the value proposition of this seemingly simple feature Overloading?
Shorter interfaces not bogged down by artificial, tiresome discriminators, and a bit of lexical structuring of text: Overloading allows indicating the conceptual identity of different methods, letting one to stress common semantics across methods so that similarities become apparent at first sight. It's supposed to make the code more readable, and what regards server code - the code, where these method siblings are defined -, it really does.
There is tons of code using what overloading has to offer. And of course, one cannot even escape it in Java, where one is simply forced to use it when want to provide different initializers. It seems, overloading rules - a feature not only popular, but tightly integrated into some important programming languages, an open commitment of venereous language designers that surely does not fail to impress the masses.

Now, should overloading in code be fully embraced then? Should it be use wherever possible?
There is no reason to question that naming conventions to indicate conceptual interrelatedness of different methods will benefit the class text where these methods are defined. To adopt the convention of reusing the same method name, however, has unfortunate consequences on client code which can become quite unintuitive, to say the least.
Overloading with parameter lists of different length pose no problem for client code interpretation, as they openly disambiguate client calls at first sight. Things that could irritate just will not compile. However, when overloaded methods with the same method name have parameter lists of the same length, and when the actual call arguments conform to more than one signature of these overloaded methods, it somehow gets a little hard to tell which methods are actually executed just looking on the client calls.
A minimal modification allows us to focus on the ugly side of overloading: The program tells which method gets actually called, but on top of that also delivers rather strong comments when overloading is caught to harm ones ability to reason about the client code without knowing the server classes.
Basically, there are two fixed instances, which will play always the same roles: one serving as call target, the other serving as argument. Now while mixing and matching several calls always to be executed on these same instances (always the same target object, always the same argument object) the only difference being the reference types through which these objects are accessed.

(Note: To be continued in next blog)