Java Programming

i++

}

Message to method binding

A question of whether a message should bind to

• a method in the class to which the reference variable pointing to the receiver was declared to be an instance of (static binding), or
• a method in the class to which the receiver is an instance of at run-time (dynamic binding).

• in the context of OOP typically refers to the binding of methods to messages
• methods varying dynamically entails much of the power of the OO approach
• main source of power in an OO language
• search for method (code body) to bind to a message starts from the class to which the receiver currently (i.e., at run-time) is an instance of, and and proceeds up the class inheritance hierarchy from there (static binding initiates the search from the class to which the reference variable pointing to the receiver was declared to be an instance of)
• if no method found anywhere, a run-time error (method not found) is reported and this is typically the only error in a Smalltalk program ever detected and reported
• example: Mammal m; Cow c; if (user input) m = new Cow; // if static binding used, run method in class Mammal bound to run message here // if dynamic binding used, run method in class Cow bound to run message here m.run else c = new Cow; c.run

• `to allow software systems to be more easily extended during both development and maintenance' [COPL] p. 461
• allows dynamic polymorphism, consider sorting (written in a general way)
• obviates need for abstract classes (e.g., Fruit class, peel method)
• while other forms of dynamism in languages tend to be compromise efficiency in the run-time system, dynamic binding involves little overhead

• advantages of each?
• disadvantages of each?

• Smalltalk
  • dynamic by default
  • by sending a message to super we can initiate the search (for the method to bind to the message) in the parent class of the class to which the sender belongs (i.e., like sending a message to self with a different entry point for the search (not quite static binding))
• Java and Eiffel
  • dynamic by default
  • in Java, preface method with final qualifier to prevent any subclass from overriding it
  • in Eiffel, preface method with frozen qualifier to prevent any subclass from overriding it
• C++
  • static by default (why?)
  • preface method with virtual qualifier for dynamic binding; the search for the method to bind to the message starts in the class which defines the method prefaced with the virtual qualifier and proceeds down the inheritance hierarchy from there to the class to which the receiver object belongs
• Objective-C, Modula-3, Python, and Ruby use dynamic binding for all methods
• Simula, C# and Ada 95 use static binding by default and support dynamic binding as an option

Do not confuse dynamic binding of messages to methods with dynamic allocation and deallocations of objects.

• Smalltalk: manual dynamic allocation, automatic deallocation
• Java: manual dynamic allocation, automatic deallocation
• C++: manual dynamic allocation, manual deallocation

It returns memory to the memory pool by destroying objects that no longer have a reference to them.

Memory management is a crucial element in many types of applications. Consider a program that reads in large amounts of data, say from somewhere else on a network, and then writes that data into a database on a hard drive. A typical design would be to read the data into some sort of collection in memory, perform some operations on the data, and then write the data into the database. After the data is written into the database, the collection that stored the data temporarily must be emptied of old data or deleted and recreated before processing the next batch. This operation might be performed thousands of times, and in languages like C or C++ that do not offer automatic garbage collection, a small flaw in the logic that manually empties or deletes the collection data structures can allow small amounts of memory to be improperly reclaimed or lost forever. These small losses are called memory leaks, and over many thousands of iterations they can make enough memory inaccessible that programs will eventually crash. Creating code that performs manual memory management cleanly and thoroughly is a complex task.

Java's garbage collector provides an automatic solution to memory management. In most cases it frees you from having to add any memory management logic to your application. The downside to automatic garbage collection is that you can't completely control when it runs and when it doesn't.

Overview of Java's Garbage Collector

Garbage collection is the phrase used to describe automatic memory management in Java. Whenever a software program executes (in any programming language for that matter), it uses memory in several different ways. We're not going to get into Computer Science 101 here, but it's typical for memory to be used to create a stack, a heap, in Java's case constant pools, and method areas. The heap is that part of memory where Java objects live, and it's the one and only part of memory that is in any way involved in the garbage collection process.

So, all of garbage collection revolves around making sure that the heap has as much free space as possible. For the purpose of the exam, what this boils down to is deleting any objects that are no longer reachable by the Java program running. When the garbage collector runs, its purpose is to find and delete objects that cannot be reached. If you think of a Java program as being in a constant cycle of creating the objects it needs (which occupy space on the heap), and then discarding them when they're no longer needed, creating new objects, discarding them, and so on, the missing piece of the puzzle is the garbage collector. When it runs, it looks for those discarded objects and deletes them from memory so that the cycle of using memory and releasing it can continue.

We overload constructors to give options on how to initialize an object.

Public Person()

{

name=""

age=""

gender=""

}

...if you override

Public Person(String name, int age, String gender)

{

this.name=name

this.age=age

this.gender=gender

}

Now upon coding time, if you need to initialize it with parameters you have two choices:

1. When an object will be initialized and you don't have to pass values to the parameter, use the constructor without parameters,
2. and if you need to pass parameters, then use the one with parameters.

Now if you ask me what's the use?

well, since you are creating a class, you are encapsulating. you want as much to limit the use of your internal properties.

e.g.

private name

private birthyear

public Person(String name, Int age)

{

this.name=name

this.birthyear= yearNow-age

}

public Person(String name, Int birthdate)

{

this.name=name

this.birthdate=birthdate

}

You make sure that everytime a Person() is initialized, birthday property has a value either from age or birthdate.

I know the example is absurd but there are lots of complex example for this, I do overloading of constructors most of the time. from creating connection objects, to creating business process objects, since they differ in their needs.

Problem that often occur is code duplication. It's up to you to make a way to minimize/avoid duplication of code. usually I do this

public Person(String name, Int age)

{

Person(name, yearNow-age)

}

public Person(String name, Int birthyear)

{

this.name=name

this.birthyear=birthyear

Person();

}

Hope this gives an idea.

Abstraction

Abstraction is simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.

For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy's pets.

Abstraction is also achieved through Composition. For example, a class Car would be made up of an Engine, Gearbox, Steering objects, and many more components. To build the Car class, one does not need to know how the different components work internally, but only how to interface with them, i.e., send messages to them, receive messages from them, and perhaps make the different objects composing the class interact with each other.

Encapsulation

Encapsulation conceals the functional details of a class from objects that send messages to it.

For example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface - those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in future, thereby allowing those changes to be made more easily, that is, without changes to clients. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected or private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the default access modifier to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allow one to specify which classes may access any member.

In Windows:

• Copy the lib path of the java jdk from where it is installed.
• Open command promt.
• Type the following command.

set CLASSPATH=

Example:

C:\>set classpath=C:\Java\jdk1.6.0_03\lib