User login

Home › Technology › Computer › Software

OOP's concepts

admin's picture
Thu, 02/12/2009 - 04:44 — admin

CONCEPTS  OF OOP

There are 4 principles of OOP. Abstraction, Ineheritance, Polymorhpism and Encapsulation.

  • ABSTRACTION

Abstraction in Java allows the user to hide non-essential details relevant to user.

  • INHERITANCE

Inheritance is oops concept by which one class gets the state and behavior of another class.Java uses the extends keyword to set the relationship between a parent class and a child class.

The new class which get the feature from existing class called derived class and other class is called base class.

Java does not allow multiple inheritance as one class cannot extend more than one class.But you can achieve multiple inheritance by implementing more than one interface

  • POLYMORPHISM

Polymorphism is the ability to exist in many forms. Polymorphism allows the programmer to treat derived class members just like their parent class' members

There are two types of polymorphism :

1. Compile-time polymorphism
2. Runtime Polymorphism

In compiletime Polymorphism, method to be invoked is determined at the compile time. Compile time polymorphism is supported through the method overloading concept in java.

Method overloading means having multiple methods with same name but with different signature (number, type and order of parameters).

In rumtime polymorphism, the method to be invoked is determined at the run time. The example of run time polymorphism is method overriding. When a subclass contains a method with the same name and signature as in the super class then it is called as method overriding

  • ENCAPSULATION

Encapsulation is the process of binding together the methods and data variables as a  single entity. This keeps both the  data and functionality code safe  from the outside world. It hides the data within the class and makes it available only through  the methods. Java provides different accessibility scopes (public, protected, private ,default) to hide the data from outside.

 

CLASS

A class defines the properties and behavior (variables and methods) that is shared by all its objects. It is a blue print for the creation of  objects.

 

OBJECT

Object is the basic entity of object oriented programming language. Object is instance of class. Each object will have its own state , and access to all of the behaviors defined by its class. In Java , Object is created when java virtual machine encounters the new keyword.Objects are created on the heap.

In procedural programming, an object may contain data or instructions, but not both. In object-oriented programming, an object may be associated with both the data and the instructions that operate on that data.

In a prototype-based language (e.g., JavaScript) an object can be created from nothing, or can be based on an existing object. In a class-based language (e.g., Java), an object is created as an instance (or instantiation) of a class

Three properties characterize objects:

  1. Identity: the property of an object that distinguishes it from other objects
  2. State: describes the data stored in the object

  3. Behavior: describes the methods in the object's interface by which the object can be used

BENEFITS OF OBJECT

Bundling code into individual software objects provides a number of benefits, including:

1. Modularity:
2. Information-hiding:
3. Code re-use:
4. Pluggability and debugging ease

TYPES OF OBJECT

* Singleton object: An object that is the only instance of its class during the lifetime of the program.
* Functor (function object): an object with a single method (in C++, this method would be the function operator, "operator()") that acts much like a function (like a C/C++ pointer to a function).
* Immutable object: an object set up with a fixed state at creation time and which does not vary afterward.
* First-class object: an object that can be used without restriction.
* Container: an object that can contain other objects.
* Factory object: an object whose purpose is to create other objects.
* Metaobject: an object from which other objects can be created (Compare with class, which is not necessarily an object)
* Prototype: a specialized metaobject from which other objects can be created by copying
* God object: an object that knows too much or does too much. The God object is an example of an anti-pattern.
* Antiobjects: a computational metaphor useful to conceptualize and solve hard problems often with massively parallel approaches by swapping computational foreground and background.....
* Filter object:is an object which receives a stream of data as its input and produces the stream of data as its output based on the data from input stream.

 

INTERFACE VS ABSTRACT CLASS

An interface allows somebody to start from scratch to implement your interface or implement your interface in some other code whose original or primary purpose was quite different from your interface. To them, your interface is only incidental, something that have to add on to the their code to be able to use your package.

An abstract class, in contrast, provides more structure. It usually defines some default implementations and provides some tools useful for a full implementation. The catch is, code using it must use your class as the base. That may be highly inconvenient if the other programmers wanting to use your package have already developed their own class hierarchy independently. In Java, a class can inherit from only one base class.

You can offer the best of both worlds, an interface and an abstract class. Implementors can ignore your abstract class if they choose. The only drawback of doing that is calling methods via their interface name is slightly slower than calling them via their abstract class name.

Summary Table

Interfaces vs Abstract Classes
feature interface abstract class
multiple inheritance A class may implement several interfaces. A class may extend only one abstract class.
default implementation An interface cannot provide any code at all, much less default code. An abstract class can provide complete code, default code, and/or just stubs that have to be overridden.
constants Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional. Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants.
third party convenience An interface implementation may be added to any existing third party class. A third party class must be rewritten to extend only from the abstract class.
is-a vs -able or can-do Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects. An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Dalmatian descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is.

In a Java context, users should typically implement the Runnable interface rather than extending Thread, because they’re not really interested in providing some new Thread functionality, they normally just want some code to have the capability of running independently. They want to create something that can be run in a thread, not a new kind of thread.The similar is-a vs has-a debate comes up when you decide to inherit or delegate.

multiple inheritance for further discussion of is-a vs has-a
plug-in You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design. You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad.
homogeneity If all the various implementations share is the method signatures, then an interface works best. If the various implementations are all of a kind and share a common status and behaviour, usually an abstract class works best. Another issue that’s important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homo-geneous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface.
maintenance If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method. Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.
speed Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty. Fast
terseness The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can’t call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so. You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract.
adding functionality

If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.

 If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.