Object Oriented Programming (OOP) - Revision history

Rasimsen at 21:55, 21 July 2018

2018-07-21T21:55:31Z

Rasimsen: /* Inheritance */

2018-07-21T13:46:05Z

‎Inheritance

Rasimsen: /* Inheritance */

2018-07-21T13:39:03Z

‎Inheritance

Rasimsen: /* Polymorphism */

2018-07-21T13:32:15Z

‎Polymorphism

Rasimsen: /* Polymorphism */

2018-07-21T13:28:53Z

‎Polymorphism

Rasimsen: /* Is Java a pure object-oriented programming language? */

2018-07-21T12:12:52Z

‎Is Java a pure object-oriented programming language?

Rasimsen at 12:12, 21 July 2018

2018-07-21T12:12:07Z

Rasimsen: /* Immutable Class in Java */

2018-07-06T15:42:46Z

‎Immutable Class in Java

Rasimsen at 15:19, 6 July 2018

2018-07-06T15:19:33Z

Rasimsen: /* SOLID principles */

2018-07-04T08:39:04Z

‎SOLID principles

← Older revision		Revision as of 21:55, 21 July 2018
Line 607:		Line 607:
	*All operations are performed by sending messages to objects		*All operations are performed by sending messages to objects
	*All user defined types are objects		*All user defined types are objects
		+
		+
		+	==Coupling==
		+	'''The degree of dependency between two modules'''. We always want low coupling.
		+
		+	==Cohesion==
		+	The measure of '''how strongly-related''' is the set of functions performed by a module. We always want high cohesion.
		+
		+	All methodologies try to reduce coupling and increase cohesion. Information Hiding reduces coupling by isolating the details of the implementation of state.
		+
		+	*OOP adds another step in the reduction of coupling with the enforcement of encapsulation and the introduction of dynamic binding and polymorphism.
		+	*Inheritance allows us to increase cohesion by defining hierarchies based on generalization and specialization, in which we can separate the functionality that belongs to the superclass from its subclasses.
		+	*AOP provides a solution for the problem of cross-cutting concerns, so that both the aspects and the affected methods may become more cohesive.
		+
		+	==Separation of concerns (SoC)==
		+	Separation of concerns is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors.
		+
		+	http://en.wikipedia.org/wiki/Separation_of_concerns
		+
		+	The separation allows:
		+
		+	*To allow people to work on individual pieces of the system in isolation;
		+	*To facilitate reusability;
		+	*To ensure the maintainability of a system;
		+	*To add new features easily;
		+	*To enable everyone to better understand the system;
		+
		+	==Single Responsibility Principle (SRP)==
		+	Single Responsibility Principle – every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. On some level Cohesion is considered as synonym for SRP.
		+
		+	http://en.wikipedia.org/wiki/Single_responsibility_principle

@@ Line 139: / Line 139: @@
 <source>
 Compiler Error
 </source>

@@ Line 102: / Line 102: @@
 Inheritance provides an object with '''the ability to acquire the fields and methods of another class''', called base class. Inheritance provides '''re-usability of code and can be used to add additional features to an existing class, without modifying it'''.
-more on [[Inheritance]]
+note: Java doesn’t support '''Multiple Inheritance'''
 == Abstraction ==

← Older revision		Revision as of 13:32, 21 July 2018
Line 42:		Line 42:

	If you '''overload static method''' in java, it is the example of '''compile time polymorphism'''.		If you '''overload static method''' in java, it is the example of '''compile time polymorphism'''.
		+
		+	Example
		+	<syntaxhighlight lang="java">
		+	public interface Vegetarian{}
		+	public class Animal{}
		+	public class Deer extends Animal implements Vegetarian{}
		+	</syntaxhighlight>
		+
		+	Now, the Deer class is considered to be polymorphic since this has multiple inheritance. Following are true for the above examples
		+
		+	*A Deer IS-A Animal
		+	*A Deer IS-A Vegetarian
		+	*A Deer IS-A Deer
		+	*A Deer IS-A Object
		+
		+	When we apply the reference variable facts to a Deer object reference, the following declarations are legal
		+	<syntaxhighlight lang="java">
		+	Deer d = new Deer();
		+	Animal a = d;
		+	Vegetarian v = d;
		+	Object o = d;
		+	</syntaxhighlight>
		+

	===Runtime polymorphism===		===Runtime polymorphism===

@@ Line 33: / Line 33: @@
 == Polymorphism ==
-Polymorphism is the ability of programming languages to '''present the same interface for differing underlying data types'''. A polymorphic type is a type whose operations can also be applied to values of some other type.
+we can perform a single action by different ways.
-more on [[Polymorphism]]..
+There are two types of polymorphism in java:
 == Inheritance ==

@@ Line 404: / Line 404: @@
 ==Is Java a pure object-oriented programming language?==
-Java is not because it supports Primitive datatype such as int, byte, long... etc, to be used, which are not objects. Contrast with a pure OOP language like Smalltalk, where there are no primitive types, and boolean, int and methods are all objects.
+'''Java is not because it supports Primitive datatype such as int, byte, long... etc, to be used, which are not objects'''. Contrast with a pure OOP language like Smalltalk, where there are no primitive types, and boolean, int and methods are all objects.
-A Pure Object-Oriented Programming Language should be true for all the 7 conditions mentioned below:
+A Pure Object-Oriented Programming Language '''should be true''' for all the 7 conditions mentioned below:
 *Inheritance
 *Encapsulation/Data Hiding

← Older revision		Revision as of 12:12, 21 July 2018
Line 399:		Line 399:

	https://qph.fs.quoracdn.net/main-qimg-1c8eb714ca00e19167803a5e52b67c4f		https://qph.fs.quoracdn.net/main-qimg-1c8eb714ca00e19167803a5e52b67c4f
		+
		+
		+
		+	==Is Java a pure object-oriented programming language?==
		+
		+	Java is not because it supports Primitive datatype such as int, byte, long... etc, to be used, which are not objects. Contrast with a pure OOP language like Smalltalk, where there are no primitive types, and boolean, int and methods are all objects.
		+
		+	A Pure Object-Oriented Programming Language should be true for all the 7 conditions mentioned below:
		+	*Inheritance
		+	*Encapsulation/Data Hiding
		+	*Polymorphism
		+	*Abstraction
		+	*All predefined types are objects
		+	*All operations are performed by sending messages to objects
		+	*All user defined types are objects

@@ Line 242: / Line 242: @@
-To create immutable class in java, you have to do following steps.
+'''To create immutable class in java, you have to do following steps.'''
 *Declare the class as final so it can’t be extended.
@@ Line 395: / Line 395: @@
 As you can see from the output, HashMap values got changed because of shallow copy in the constructor and providing direct reference to the original object in the getter function.
 ==Stack and Heap==
 https://qph.fs.quoracdn.net/main-qimg-1c8eb714ca00e19167803a5e52b67c4f

← Older revision		Revision as of 15:19, 6 July 2018
Line 236:		Line 236:

	'''That’s all for composition vs inheritance. You have got enough reasons to choose composition over inheritance. Use inheritance only when you are sure that superclass will not be changed, otherwise go for composition.'''		'''That’s all for composition vs inheritance. You have got enough reasons to choose composition over inheritance. Use inheritance only when you are sure that superclass will not be changed, otherwise go for composition.'''
		+
		+	==Immutable Class in Java==
		+
		+	Immutable class is good for '''caching purpose''' because you don’t need to worry about the value changes. Other benefit of immutable class is that it is '''inherently thread-safe''', so you don’t need to worry about thread safety in case of multi-threaded environment.
		+
		+
		+	To create immutable class in java, you have to do following steps.
		+
		+	*Declare the class as final so it can’t be extended.
		+	*Make all fields private so that direct access is not allowed.
		+	*Don’t provide setter methods for variables
		+	*Make all '''mutable fields''' final so that it’s value can be assigned only once.
		+	*Initialize all the fields via a constructor performing deep copy.
		+	*Perform cloning of objects in the getter methods to return a copy rather than returning the actual object reference.
		+
		+	To understand points 4 and 5, let’s run the sample Final class that works well and values doesn’t get altered after instantiation.
		+
		+	FinalClassExample.java
		+
		+	<syntaxhighlight lang="java">
		+	package com.journaldev.java;
		+
		+	import java.util.HashMap;
		+	import java.util.Iterator;
		+
		+	public final class FinalClassExample {
		+
		+	private final int id;
		+
		+	private final String name;
		+
		+	private final HashMap<String,String> testMap;
		+
		+	public int getId() {
		+	return id;
		+	}
		+
		+
		+	public String getName() {
		+	return name;
		+	}
		+
		+	/**
		+	* Accessor function for mutable objects
		+	*/
		+	public HashMap<String, String> getTestMap() {
		+	//return testMap;
		+	return (HashMap<String, String>) testMap.clone();
		+	}
		+
		+	/**
		+	* Constructor performing Deep Copy
		+	* @param i
		+	* @param n
		+	* @param hm
		+	*/
		+
		+	public FinalClassExample(int i, String n, HashMap<String,String> hm){
		+	System.out.println("Performing Deep Copy for Object initialization");
		+	this.id=i;
		+	this.name=n;
		+	HashMap<String,String> tempMap=new HashMap<String,String>();
		+	String key;
		+	Iterator<String> it = hm.keySet().iterator();
		+	while(it.hasNext()){
		+	key=it.next();
		+	tempMap.put(key, hm.get(key));
		+	}
		+	this.testMap=tempMap;
		+	}
		+
		+
		+	/**
		+	* Constructor performing Shallow Copy
		+	* @param i
		+	* @param n
		+	* @param hm
		+	*/
		+	/**
		+	public FinalClassExample(int i, String n, HashMap<String,String> hm){
		+	System.out.println("Performing Shallow Copy for Object initialization");
		+	this.id=i;
		+	this.name=n;
		+	this.testMap=hm;
		+	}
		+	*/
		+
		+	/**
		+	* To test the consequences of Shallow Copy and how to avoid it with Deep Copy for creating immutable classes
		+	* @param args
		+	*/
		+	public static void main(String[] args) {
		+	HashMap<String, String> h1 = new HashMap<String,String>();
		+	h1.put("1", "first");
		+	h1.put("2", "second");
		+
		+	String s = "original";
		+
		+	int i=10;
		+
		+	FinalClassExample ce = new FinalClassExample(i,s,h1);
		+
		+	//Lets see whether its copy by field or reference
		+	System.out.println(s==ce.getName());
		+	System.out.println(h1 == ce.getTestMap());
		+	//print the ce values
		+	System.out.println("ce id:"+ce.getId());
		+	System.out.println("ce name:"+ce.getName());
		+	System.out.println("ce testMap:"+ce.getTestMap());
		+	//change the local variable values
		+	i=20;
		+	s="modified";
		+	h1.put("3", "third");
		+	//print the values again
		+	System.out.println("ce id after local variable change:"+ce.getId());
		+	System.out.println("ce name after local variable change:"+ce.getName());
		+	System.out.println("ce testMap after local variable change:"+ce.getTestMap());
		+
		+	HashMap<String, String> hmTest = ce.getTestMap();
		+	hmTest.put("4", "new");
		+
		+	System.out.println("ce testMap after changing variable from accessor methods:"+ce.getTestMap());
		+
		+	}
		+
		+	}
		+	</syntaxhighlight>
		+
		+	Output of the above immutable class in java example program is:
		+
		+	<source>
		+	Performing Deep Copy for Object initialization
		+	true
		+	false
		+	ce id:10
		+	ce name:original
		+	ce testMap:{2=second, 1=first}
		+	ce id after local variable change:10
		+	ce name after local variable change:original
		+	ce testMap after local variable change:{2=second, 1=first}
		+	ce testMap after changing variable from accessor methods:{2=second, 1=first}
		+	</source>
		+
		+	Now let’s comment the constructor providing deep copy and uncomment the constructor providing shallow copy. Also uncomment the return statement in getTestMap() method that returns the actual object reference and then execute the program once again.
		+
		+	<source>
		+	Performing Shallow Copy for Object initialization
		+	true
		+	true
		+	ce id:10
		+	ce name:original
		+	ce testMap:{2=second, 1=first}
		+	ce id after local variable change:10
		+	ce name after local variable change:original
		+	ce testMap after local variable change:{3=third, 2=second, 1=first}
		+	ce testMap after changing variable from accessor methods:{3=third, 2=second, 1=first, 4=new}
		+	</source>
		+
		+	As you can see from the output, HashMap values got changed because of shallow copy in the constructor and providing direct reference to the original object in the getter function.
		+

@@ Line 13: / Line 13: @@
 SOLID is one of the most popular sets of design principles in object-oriented software development. It’s a mnemonic acronym for the following five design principles:
-S – Single-Responsibility Principle. ---- “There should be never more than one reason for a class to change.”
+S – Single-Responsibility Principle. ---- '''“There should be never more than one reason for a class to change.”'''
-O – Open-Closed Principle.           ---- “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
+O – Open-Closed Principle.           ---- '''“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”'''
-L – Liskov Substitution Principle.   ---- “Subtypes must be substitutable for their base types.”
+L – Liskov Substitution Principle.   ---- '''“Subtypes must be substitutable for their base types.”'''
-I – Interface Segregation Principle. ---- “Classes that implement interfaces, should not be forced to implement methods they do not use.”
+I – Interface Segregation Principle. ---- '''“Classes that implement interfaces, should not be forced to implement methods they do not use.”'''
-D – Dependency Inversion Principle.  ---- “High-level modules should not depend on low level modules, rather both should depend on abstraction. Abstraction should not depend on details; rather detail should depend on abstraction.”
+D – Dependency Inversion Principle.  ---- '''“High-level modules should not depend on low level modules, rather both should depend on abstraction. Abstraction should not depend on details; rather detail should depend on abstraction.”'''
 == Encapsulation ==