Oops concepts in cpp

Answer 1

Object Oriented Programming (OOP) is the implementation (programming) of Object Oriented Design (OOD). The two usually go together, in in OOD/OOP. OOD is a concept where the design of a solution to a problem revolves around the objects it manipulates, specifically, standardizing the way we think about the attributes (data) and methods (operations) available in an object. While C++ is particularly well suited to OOP, the OOP paradigm can (and should) be extended to cover everything that a program manipulates, even to the extent of simple scalar variables such as an integer. This philosophy is based on some of the definitions of a "object", i.e. that is has storage, the contents of that storage has meaning, and that there are certain operations that can be performed on that storage using a defined interface. Using this concept, even an assembly programming language can be considered to be an Object Oriented Programming Language (OOPL)! What makes C++ and other OOPL's unique are the added concepts of inheritance, polymorphism, and data encapsulation, to name just three. Inheritance is the concept that an object can be declared/defined, and then a child object can inherit the parent object's design and extend it to include other, more specific, functionality. For example, you could design an object (we call them classes) that represents a person. The person class could describe a person's name, address, and social security number. The type of functions (we call them methods) that you could perform on a person could be to set or get their name, address, and social security number. You could then design a class that represents an employee. It could use class person as a base class, and then extend that implementation to include things such as work location, job title, and salary. Class employee has all of the capabilities of class person, but you do not have to write a single line of code for that implementation - you just write the code for the employee extension. Polymorphism is the concept that you can have pointers to various classes, and invoke a same named method, such as "print()", and the code selected will be the code for the type of object to which the pointer refers to. For example, person.print() would behave different than employee.print(). While this might seem trite, it becomes important when you have pointers that can refer to multiple types of related classes, and you want to virtualize the interface to classes pointed to by those pointers at run time, instead of at compile time. Data Encapsulation is, perhaps, one of the most important aspects of OOP/OOD. You design a class, such as person. Inside that class, lets say you define the person's name as an array of characters, say of length 25. You hide that attribute from any derived classes, such as employee, and force access to person.name though a method such as person::getName(). Everything is fine until one day, when you get a person with a 27 character name. You refactor the class person. You could make the array be 64 characters but, instead, you make it a pointer to a dynamically sized array. If you designed the interface person::getName() correctly, then the derived class employee does not need to change, you can relink everything and all is well. This capability can not be overestimated. Prior to OOD/OOP, there was a tendency for programmers to write code that used global variables, variables with scope throughout the program. As the program evolves, functions use those variables in ways that depend on the implementation. One day, you change the implementation, and now you need to go on a "hunt and destroy" mission to find all references to that variable. You might miss some. Bad. Worse, some function misunderstands the variable and uses it for something else, damaging it. Later, often much later, the program crashes, but not at a point that makes any sense. Data encapsulation is the concept of making variable (attributes) of a class be totally private to that class. The defined, or exposed, methods and (sometimes) attributes of a class is called the public interface. So long as that public interface does not change, then any user of that class does not need to be changed when the non-public part of the class changes.