Why should programmer use object oriented language?

Answer 1

Object oriented programming allows programmers to classify data and methods by type. For instance, a shape is a type of object, a rectangle is a type of shape and a square is a type of rectangle. We can also say that a rectangle is a specialisation of a shape and that a square is a specialisation of a rectangle. Object oriented programming allows us to express relationships between types directly in code such that when we hold a reference to a square, we also hold a reference to a rectangle and a shape. As a result, we can pass a square or rectangle object to a function that knows nothing about squares or rectangles but knows everything about shapes.

All shapes can be drawn. Is it necessary for a function to know precisely how a shape is drawn? Of course not, it is only necessary to know that it can be drawn. Knowing this, the function can simply invoke the shape::draw() method regardless of the actual type of shape.

A rectangle inherits all the properties common to all shapes, thus a rectangle inherits the shape::draw() method. Moreover, a rectangle can specialise this method, overriding any default behaviour with its own specialised implementation in rectangle::draw(). Thus when we pass a rectangle object to a function that only knows about shapes and that function invokes the shape::draw() function, we actually invoke the rectangle::draw() function even though our function knows nothing about rectangles!

By the same token, a square inherits all the properties common to all rectangles, including all properties common to all shapes. Thus square::draw() inherits rectangle::draw() which overrides shape::draw(). However, a square does not actually need to override the draw method because the the implementation that applies to a rectangles also applies to a square. This is because rectangles and squares both have 4 vertices with internal angles of 90 degrees. The only thing that actually differentiates a square from a rectangle is that the adjacent vertices of a square are equidistant, but the actual vertices are defined by the rectangle so the rectangle has all the information required to draw a square. Again, the rectangle object does not need to know anything about squares in order to draw one!

Let's now look at how we can define all of these notions in an object-oriented programming language.

class shape {

public:

virtual void draw() = 0;

virtual ~shape() {}

};

class rectangle : public shape {

public:

rectangle (int top, int left, int width, int height): t {top}, l {left}, w {width}, h {height} {}

void draw() override;

void ~rectangle() override {}

private:

int t, l, w, h;

};

class square : public rectangle final {

public:

square (int top, int left, int size): rectangle {top, left, size, size} {}

};

Although this code is relatively short, it contains a lot of information. This is common in object oriented programming, we can glean a lot of information from very little code. A novice programmer might expect a few user-comments to explain everything in a bit more detail, but to a professional programmer this code tells us every we need to know.

For example, the shape::draw() method is declared a pure-virtual method (a virtual method with no implementation). This immediately tells is the shape class an abstract base class and thus prevents general users from instantiating objects of type shape. This reflects the real world where we can imagine a shape but we cannot draw one (we can only draw a specific type of shape). Being a base class (a class with at least one virtual method), the shape class also has to have a virtual destructor to ensure correct tear-down whenever a shape falls from scope. The shape class has no non-static data members thus we can take advantage of the empty class optimisation. That is, any class that inherits from shape will have zero overhead because there are no data members to inherit.

The rectangle class publicly inherits from shape. This means that all public methods of shape are public methods of rectangle. The rectangle specialises shape with the addition of 4 data members, t, l, w and h (top, left, width and height respectively). The constructor initialises these members at the point of instantiation. We also declare overrides for the inherited interfaces, shape::draw() and shape::~shape(). This is essential otherwise rectangle would also be an abstract base class and we wouldn't be able to instantiate rectangles.

The square class public inherits from rectangle and declares it final. This means we cannot inherit from square, it is not intended to be used as a base class. We automatically inherit both the rectangle::draw() and rectangle::~rectangle() interfaces and we do not need to override these. The only specialisation we need is the constructor which invokes the rectangle constructor to implement the invariant that a rectangle's width and height are always equal for squares. The square has no data members of its own, so there is zero overhead and while we do inherit the data members from rectangle, they are private so we cannot access them.

To complete the implementation, we also need to provide an implementation for the rectangle::draw() method. For this we'll assume that a line() function handles the low-level graphics facility. We do not need to know the implementation details of the line() function, we need only know that the function will draw a line between a pair of coordinates.

void rectangle::draw() {

line (t, l, t, l+w);

line (t, l+w, t+h, l+w);

line (t+h, l+w, t+h, l);

line (t+h, l, t, l);

}

Our definition is complete. We can now use these classes. Let's define a function that accepts a vector of shape pointers and invokes each of their draw methods. We'll use a type alias to reduce code verbosity:

using vec_shapes = std::vector<std::unique_ptr<shape>>;

void draw_shapes (vec_shapes& v) {

for (auto s : v) s->draw();

}

Note that this function only needs to "see" the shape definition. That is, the rectangle and square definitions could be defined in another translation unit entirely. We can even add triangles, circles, pentagons and all manner of other shapes into the mix at a later date and this code will still work without any further modification.

Now let's invoke this function:

void foo() {

vec_shapes v;

v.push_back (new square {10, 10 , 5});

v.push_back (new rectangle {20, 15 , 5, 7});

v.push_back (new square {30, 20 , 4});

v.push_back (new rectangle {40, 25 , 6, 8});

draw_shapes (&v);

}

Note that the vec_shapes alias is itself an object, one that encapsulates a vector of resource handles ("smart" pointers). Although we instantiated four new objects on the heap, we didn't actually delete them as we normally would have had to had they been "naked" pointers. That's because we don't have to delete them. When this function ends, the vector falls from scope and this automatically invokes its destructor which subsequently empties the vector. As each smart pointer within the vector is removed, it falls from scope thus invoking its destructor which explicitly invokes the destructor of the pointer it encapsulates (a pointer to shape). Since that destructor is declared virtual, the most-derived object is destroyed first before working back through the hierarchy, destroying each base class until the shape class itself is finally destroyed.

From this we begin to see the importance of object oriented programming. Resource management details can be fully encapsulated within the objects themselves, thus there is less chance of human error creating resource leaks which is a common problem with C-style coding using "naked" pointers. Objects can also encapsulate class invariants, such that only those methods that modify class member data need maintain those invariants, thus eliminating the need to constantly test those invariants at runtime and thus improving performance. Objects can also implement move semantics so that resources can be efficiently transferred from one object to another thus making it possible to perform (almost) perfect swaps without making any unnecessary temporary copies. This also makes it possible to efficiently return objects from functions by value, the default semantic in both C and C++. Our code becomes easier to write because there's much less of it and much easier to maintain because implementation details are easier to encapsulate.

Answer 2

Programmers need to use OOP because:

1. To reduce length of the programs.

2. To avoid reuses of codes.

3. Security of Data.

4. To decrease the strain of programmer.

5. It makes your programs more organized.

Answer by: Balu(NSB)

Answer 3

mainly code reusable .and we can hide the implementation of code