DEV Community: Saurav Ghimire

OOP and it's use cases

Saurav Ghimire — Fri, 26 Nov 2021 18:46:45 +0000

OOP is an abbreviation for the word "Object oriented programming".
it is based on the concept of "objects", which basically contains data and code:
data :-> data is in the form of fields (such as attributes and properties)
code:-> in the form of procedures/processes also known as methods.

a feature of objects is object's own procedures which can access and often modify the data fields or itself(objects have a notion of "this" or "self").
The four basics of object oriented programming are:
1.Encapsulation
2.Abstraction
3.Inheritance
4.Polymorphism

1.Encapsulation
->The word 'encapsulate' means to enclose something. just like a pill "encapsulates" or contains the medication inside of its coating. In similar way, in OOP: by forming a protective barrier around information contained within a class from the rest of the code.
what is encapsulation used for?
->Object oriented programming uses this aspect for hiding sensitive data and displaying only that particular data that is necessary for the user at that particular time of work.
Encapsulation can work with a property known as "Access Modifiers". Access modifiers are there to modify one's access towards certain data or method within the class, outside the class, within derived the class etc.
These modifiers are mainly private, public and protected access modifiers and are specified along with class specification.

Eg. of Encapsulation
Class Car{
private: Engine E; //private data
public:
bool unlock: //public data
.
.
.
car(){ // public method
}
}
encapsulation is a good coding practice and it increases the security of your data.

2.Abstraction
->Abstraction is an extension of encapsulation. It is the process of selecting data from a larger pool to show only the relevant details to the object. Suppose you want to create a dating application and you are asked to collect all the information about your users. You might receive the following data from your user: Full name, address, phone number, favorite food, favorite movie, hobbies, tax information, social security number, credit score. This amount of data is great however not all of it is required to create a dating profile. You only need to select the information that is pertinent to your dating application from that pool. Data like Full name, favorite food, favorite movie, and hobbies make sense for a dating application. The process of fetching/removing/selecting the user information from a larger pool is referred to as Abstraction. One of the advantages of Abstraction is being able to apply the same information you used for the dating application to other applications with little or no modification.

Inheritance
Inheritance is the ability of one object to acquire some/all properties of another object. For example, a child inherits the traits of his/her parents. With inheritance, reusability is a major advantage. You can reuse the fields and methods of the existing class. In Java, there are various types of inheritances: single, multiple, multilevel, hierarchical, and hybrid. For example, Apple is a fruit so assume that we have a class Fruit and a subclass of it named Apple. Our Apple acquires the properties of the Fruit class. Other classifications could be grape, pear, and mango, etc. Fruit defines a class of foods that are mature ovaries of a plant, fleshy, contains a large seed within or numerous tiny seeds. Apple the sub-class acquires these properties from Fruit and has some unique properties, which are different from other sub-classes of Fruit such as red, round, depression at the top.
Polymorphism
Polymorphism gives us a way to use a class exactly like its parent so there is no confusion with mixing types. This being said, each child sub-class keeps its own functions/methods as they are. If we had a superclass called Mammal that has a method called mammalSound(). The sub-classes of Mammals could be Dogs, whales, elephants, and horses. Each of these would have their own iteration of a mammal sound (dog-barks, whale-clicks).

Use case of Object oriented Programming:

Client-Server Systems

Object-oriented client-server systems provide the IT infrastructure, creating Object-Oriented Client-Server Internet (OCSI) applications. Here, infrastructure refers to operating systems, networks, and hardware. OSCI consist of three major technologies:

The Client Server
Object-Oriented Programming
The Internet

Object-Oriented Databases

They are also called Object Database Management Systems (ODBMS). These databases store objects instead of data, such as real numbers and integers. Objects consist of the following:

Attributes: Attributes are data that define the traits of an object. This data can be as simple as integers and real numbers. It can also be a reference to a complex object.

Methods: They define the behavior and are also called functions or procedures.

Object-Oriented Databases

These databases try to maintain a direct correspondence between the real-world and database objects in order to let the object retain its identity and integrity. They can then be identified and operated upon.

Real-Time System Design

Real-time systems inherent complexities that make it difficult to build them. Object-oriented techniques make it easier to handle those complexities. These techniques present ways of dealing with these complexities by providing an integrated framework, which includes schedulability analysis and behavioral specifications.

Simulation and Modeling System

It’s difficult to model complex systems due to the varying specification of variables. These are prevalent in medicine and in other areas of natural science, such as ecology, zoology, and agronomic systems. Simulating complex systems requires modeling and understanding interactions explicitly. Object-oriented programming provides an alternative approach for simplifying these complex modeling systems.

Hypertext and Hypermedia

OOP also helps in laying out a framework for hypertext. Basically, hypertext is similar to regular text, as it can be stored, searched, and edited easily. The only difference is that hypertext is text with pointers to other text as well.

Hypermedia, on the other hand, is a superset of hypertext. Documents having hypermedia not only contain links to other pieces of text and information but also to numerous other forms of media, ranging from images to sound.

Neural Networking and Parallel Programming

It addresses the problem of prediction and approximation of complex time-varying systems. Firstly, the entire time-varying process is split into several time intervals or slots. Then, neural networks are developed in a particular time interval to disperse the load of various networks. OOP simplifies the entire process by simplifying the approximation and prediction ability of networks.

Office Automation Systems

These include formal as well as informal electronic systems primarily concerned with information sharing and communication to and from people inside and outside the organization. Some examples are:

Email
Word processing
Web calendars
Desktop publishing

CIM/CAD/CAM Systems

OOP can also be used in manufacturing and design applications, as it allows people to reduce the effort involved. For instance, it can be used while designing blueprints and flowcharts. OOP makes it possible for the designers and engineers to produce these flowcharts and blueprints accurately.

AI Expert Systems

These are computer applications that are developed to solve complex problems pertaining to a specific domain, which is at a level far beyond the reach of a human brain.

It has the following characteristics:

Reliable
Highly responsive
Understandable
High-performance

SOLID Principles

Saurav Ghimire — Fri, 26 Nov 2021 18:33:49 +0000

SOLID principles: Solid principles are the combination of 5 major principles. They are as follows:
1.Single responsibility principle
2.Liskov substitution principle
3.Open/closed principle
4.Interface segregation Principle
5.Dependency Inversion principle

Single responsibility principle -> Robert C. Martin expresses the principle as "A class should have only one reason to change" which means that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.

Code for single responsibility principle:
//this is a bad practice
class Usersettings{
constructor(user){
this.user= user;
}
} changesettings(settings){
if(this.verifycredentials()){
//.....
}
}
verifycredentials(){
}
}

//the good practice here would be

class UserAuth{
constructor(user){
this.user = user;
}
verifycredentials(){
//...
}
class Usersettings{
constructor(user){
this.user = user;
this.auth = new UserAuth(user);
}
changesettings(settings){
if(this.auth.verifycredential()){
//........
}
}
}
here a class has been assigned a single responsibility, that is one class is responsible for usersettings of adding new user, and the other class is responsible for verifying the user credentials.

Liskov substitution principle -> Introduced by Barbara liskov, the principle states that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. It means that if a program module is using a Base class, then the reference to the base class can be replaced with a derived class without affecting the functionality of the program module. We can also state that the derived types must be substitutable for their base types. Bad example where Liskov substitution is not used:

class Rectangle{
constructor(){
this.width = 0;
this.height = 0;
}
setColor(color){
//...
}
render(area){
///....
}
setWidth(width){
this.width = width;
}
setHeight(height){
this.height = height;
}
getarea(){
return this.width * this.height;
}
}
class square extends Rectangle{
setWidth(width){
this.width = width;
this.height= width;
}
setHeight(height){
this.width = height;
this.height = height;
}
}
function renderLargeRectangles(rectangles){
rectangles.ForEach((rectangle=>{
rectangle.setWidth(4);
rectangle.setHeight(5);
const area = rectangle.getArea(); //Bad , returns 25 for square, this returns 20
rectangle.render(area);
});
}
const rectangles = [new Rectangle(), new Rectangle(), new Square()];
renderLargeRectangles(rectangles);

//The good way to do this would be ,

class Shape{
setColor(color){
//......
}
render(area){
//....
}
}
class Rectangle extends Shape{
constructor(width, height){
super();
this.length = length;
}
getArea(){
return this.length * this.length;
}
}
function renderLargeShapes(shapes){
shapes.forEach((shape)=>{
const area = shape.getArea();
shape.render(area);
});
}
const shapes = [new Rectangle(4,5), new Rectangle(4, 5), new Square(5)];
renderLargeShapes(shapes);

3.Open/Closed principles:
->"Software Entities should be open for extension but closed for modification"
The design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code.
The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible the existing code unchanged.

The bad way of the code writing in this would be:
//Bad
var iceCreamFlavors = ["chocolate", "vanilla"];
var iceCreamMaker={
makeIceCream(flavor){
if(iceCreamFlavors.indexOf(flavor)>-1){
console.log("Great success, there is icecream for you")
}else{
console.log("there is no icecream for you, epic fail")
}
}
}
//good way
var iceCreamFlavors=["chocolate", "vanilla"];
var iceCreamMaker ={
makeIceCream(flavor){
if(iceCreamFlavors.indexOf(flavor)>-1){
console.log("Great Success, there is icecream for you")
}else{
console.log("There is no icecream for you , epic fail")
}
}
addFlavor(flavor){
iceCreamFlavors.push(flavor);
}
}
export default iceCreamMaker;
//if we see, then in the first version of the code, we dont have a place for adding an ice cream flavor, in order to add a flavor in the first code, we have to add an element in the array list, which means that the code gets modified, but our open/close principle doesn't allow that to happen, a code can be extended but not modified. So, in the second code, we added a function 'addFlavor(flavor)' with the parameter flavor inside the bracket which can push a different flavor of icecream inside the array,which resulted in the addition/extension of the code but not modification. So the good code, or the second follows the Open/closed principle.

4.Interface segregation principle
-> Many client specific interfaces are better than one general purpose interface.
We should not enforce clients to implement interfaces that they donot use. Instead of creating one big interface, we can break it down to smaller interfaces.

//BAD
class DOMTraverser{
constructor(settings){
this.settings = settings;
this.setup();
}
setup(){
this.rootNode = this.settings.rootNode;
this.animationModule.setup();
}
traverse(){
//....
}
}
const $= new DOMTraverser({
rootNode:document.getElementByTagName('body'),
animationModule(){} // Most of the time we don't need to animate while traversing
});

//GOOD way to do this

class DOMTraverser{
constructor(settings){
this.settings = settings;
this.options = options;
this.setup();
}
setup(){
this.rootNode = this.settings.rootNode;
this.saveOptions();
}
setupOptions(){
if(this.options.animationModule){
//.....
}
}
traverse(){
//.....
}
}
const $= newDOMTraverser{
rootNode: document.getElementByTagName('body'),
options:{
animationModule(){}
}
});

Dependency Inversion Principle ->One should depend upon abstractions and not concretions. Abstractions should not depend upon details whereas details should depend upon abstractions. High level modules should not depend upon low level modules.

//BAD code writing:
class InventoryRequester{
constructor(){
this.REQ_METHODS = ['HTTP'];
}
requestingItem(item){
//....
}
}
class InventoryTracker{
constructor(items){
this.items = items;

//BAD: we have created a dependency on a specific request implementation.
//we should have requestItems depend on a single request method:'request'
this.requester = newInventoryRequester();
}
requestItems(){
this.items.forEach((item)=>{
this.requester.requestItem(item);
});
}
}
cost InventoryTracker = new InventoryTracker(['apples', 'bananas']);
inventoryTracker.requestItems();

//GOOD
class InventoryRequester{
constructor(){
this.REQ_METHODS = ['HTTP'];
}
requestingItem(item){
//....
}
}
class InventoryRequesterv2{
constructor(){
this.REQ_METHODS = ['WS'];
}
requestItem(item){
//....
}
}

//By constructing our dependencies externally and injecting them, we can easily substitute our request module for a fancy new one that uses websockets.
const InventoryTracker(['apples', 'bananas'], new InventoryRequesterV2());
InventoryTracker.requestItems();

What happens if we do not follow solid principles?
-> Some of the cases may occur if we do not follow solid principles. They are:
a. We may end up with tight or strong coupling of code with many other modules/applications.
b.Tight coupling causes time to implement any new requirement features or any bug fixes and sometimes, it creates unknown issues.
c. We may end up with a code that is not testable in nature.
d. There would be a chance of duplication of code.

what are the advantages of following the solid principles ?
-> Following the solid principles helps us to:
a. Achieve reduction in the code complexity
b. Increase readability, extensibility and maintenance.
c. Reduces error and implementations and reusability
d. Achieves better testability
e. Reduces tight coupling.