IL's JAVA WORLD

Hi Swati and Archana!

Thank you for your inputs, I am planning to discuss OO concepts from next monday as I am planning to write SCJP? Is that okay for you ?

Here is the inputs for next topic: Singleton Pattern

A singleton is an object of which there may only ever be a single instance. (*)
You can make your own class act like a singleton, simply by only creating a single instance. But this relies on every programmer who uses your code knowing that there is only supposed to be one instance of the class, which is dangerous. A better solution is to write the class in a way which prevents a casual programmer from creating more than one instance. This is where the Singleton pattern and its associated Java idioms help you.The most obvious way for a programmer to try to create an instance of a class is to call its constructor, so we need to prevent this. If we just fail to provide a constructor, Java assumes that there is a "default constructor" taking no arguments which just creates an instance of the class; not what we need! The Java "trick" for this is to have a constructor, but make it private so no other classes may call it.

Example
public class Something
{
private static Something instance = null;

private String content;

private Something()
{
content = "empty";
}

public synchronized static Something getInstance()
{
if (instance == null)
{
instance = new Something();
}

return instance;
}

public void setContent(String content)
{
this.contemt = content;
}

public String getContent()
{
return content;
}
}
I hope this helps.
(*) The Singleton pattern actually allows for a specified number of instances, but singletons are harly ever used for any number other than one.


As it has it own disadvantages like memory leaking I think we can move to next pattern

 

Today's TIP is related to very basic stuff:


Procedural Approach
· Data Structures can be represented as a network of associated structures, referring to one another.
· Procedures can be represented as a network of routines which call one another, i.e., "call tree"
Object Oriented Approach
· Collection of discrete objects that incorporate data structures and behavior.
· Each data structure has, combined with it, the procedures which apply to that data structure.
· Contrasts with conventional programming in which data structures and behavior are only loosely connected
· These entities, called objects, can be associated to one another in one network, rather than two.
Before OOP, the programmer
was restricted to use the predefined data types such as integer, float and character. If any program required handling of the x-y coordinates of some point then it is quite a headache for the programmer. Where as, in OOP this can be handled very easily as the programmer can define his own data types and the corresponding functions.
One of the advantages of OOP over Functional programming is that the objects made in a program can be reused by any other program. This increases the reusability of the programs once written. Objects are treated as the real life objects. Just like real life objects these objects have their own identities, behaviors and states. Similarly, as we know that there are different versions of programs that come out. The programs written in an OOP can be easily updated by using the facilities of inheritance.

Advantages and Disadvantages of
Object-Oriented Development
There are many advantages for object-oriented development (in contrast with other development methods):
• Allows full exploitation of the power of object-based and object-oriented programming languages This may seem an odd advantage, but remember that
OOPLs had been around for many years (eg. Simula 67) before people started to think seriously about the whole object-oriented development approach
• Object-based models appeal to the workings of human
cognition, and hence the human input into the
development of a software system is likely to be more
natural and less error prone
• Encourages re-use, not only of modules but also of entire
designs (or at least large sections of designs)
In particular it allows the construction of a class hierarchy
(class library) from which classes required in a new
application can either be re-used, or constructed (by
inheritance and extension, or by composition)
This greater amount of re-use should lead to reduced
development and maintenance costs (but see later)
• Object-oriented systems tend to be based upon stable
forms (ie the objects and classes) which are more
resilient to change
This means that object-oriented systems are more likely
to be allowed to evolve over time, rather than have to be
abandoned or completely re-designed in response to
major changes in the customer(s) / user(s) requirements
• Delaying decisions about representation of objects and
!hiding" as much information as possible within an object
leads to strongly cohesive and weakly coupled software,
which is then easier to modify - can alter one class
without having to alter any other part of the system
However there are some disadvantages:
A study by Johnson (2000) of experienced 'real-world'
object-oriented software developers revealed the following
disadvantages:
• Unavailability of object-oriented database management
systems
• Unavailability of object-oriented CASE tools
• Confusion with too many different object-oriented
development methods
all of which should have become less important due to
changes in the last few years
Nevertheless, there are some disadvantages where less (or
even no) progress has been made:
• Decreased system / software performance
With many OOPLs (such as Java) being interpreted,
rather than compiled into native machine code, run-time
speeds are impaired
Problems with dynamic memory allocation (the method
used to create objects), means that either more memory
is used-up on garbage, or that the system run-time speed
is compromised by the need for garbage collection
• Increased initial development time
• Less than anticipated levels of reuse
With class libraries based on inheritance, the code of a
component is not collected together in one place, but
rather it is spread over the class hierarchy (class library),
and the re-user must examine a number of classes to
establish whether a component can be re-used (or they
need special tools to "view" a particular class definition)
Adaptation through inheritance tends to lead to extra
unwanted functionality which can make components
inefficient and bulky, so that object-oriented systems are
often not smaller in size than corresponding systems
developed using other design methods and imperative
PLs
As more and more classes are added to a class
hierarchy (class library), it becomes increasingly difficult
to manage. Functionality tends to be duplicated and
periodic re-organisations are necessary
Even in mature and widely used languages like Smalltalk
the class hierarchy (class library) is still being reorganised
after about 30 years of use

 

where are you my friends?

no one is intrested in the journey of this thread

 

Archana we will discuss SCJP ?s from tomorrow

Today I am sharing this example
WeakHashMap is a hashtable-based Map implementation with weak keys. An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use. More precisely, the presence of a mapping for a given key will not prevent the key from being discarded by the garbage collector, that is, made finalizable, finalized, and then reclaimed. When a key has been discarded its entry is effectively removed from the map, so this class behaves somewhat differently than other Map implementations.

WeakReference(Object referent)
Creates a new weak reference that refers to the given object

When a key is added to a map, the map will prevent the key from being garbage-collected. However, a weak map will automatically remove a key if the key is not being referenced by any other object. An example where this type of map might be useful is a registry where a registrant is automatically removed after it is garbage-collected.
// Create the weak map
Map weakMap = new WeakHashMap();

// Add a key to the weak map
weakMap.put(keyObject, valueObject);

// Get all keys that are still being referenced
Iterator it = weakMap.keySet().iterator();
while (it.hasNext()) {
// Get key
Object key = it.next();
}

The weak map does not automatically release the value if it is no longer used. To enable automatically release of the value, the value must be wrapped in a WeakReference object:
WeakReference weakValue = new WeakReference(valueObject);
weakMap.put(keyObject, weakValue);

// Get all keys that are still being referenced and check whether
// or not the value has been garbage-collected
it = weakMap.keySet().iterator();
while (it.hasNext()) {
// Get key
Object key = it.next();

weakValue = (WeakReference)weakMap.get(key);
if (weakValue == null) {
// Value has been garbage-collected
} else {
// Get value
valueObject = weakValue.get();
}
}