OOPs in Java
Ranjith Sekar
Jun 2015
Agenda
 Class
 SOLID Principles
 Object
 OOPs Concepts
 Access Modifiers
 Variables
Class
 Blueprint/template/contract
 Properties/Characteristics/Attributes & Actions
 Creation of a class
 Only one public class per source file
 Can contain multiple non-public classes (inner-classes)
 Example: Mobile
 Attributes (model, manufacturer, cost, operating system etc.,)
 Actions (call, file transfer, etc.,)
SOLID Principles
How to identify and design a Class?
 SRP (Single Responsibility Principle)
 OCP (Open Closed Principle)
 LSP (Liskov Substitution Principle)
 ISP (Interface Segregation Principle)
 DIP (Dependency Inversion Principle)
Single Responsibility Principle (SRP)
 A class should have only one reason to change (responsibility)
 Separation of responsibilities
 How to Recognize a Break of the SRP?
 Class Has Too Many Dependencies
 Method Has Too Many Parameters
 The Test Class Becomes Too Complicated
 Class / Method is Long (200-250 LOC)
 Descriptive Naming
 Change In One Place Breaks Another
 How to make the design compliant with the Single Responsibility Principle
 TDD
 Code Coverage Metrics
 Refactoring and Design Patterns
 Clear Modularization of the System
Open Closed Principle (OCP)
 Minimal changes on existing code (tested already)
 Open for extension but closed for modifications
 Inheritance using Interface/class
 Decorator Design Pattern
Liskov Substitution Principle (LSP)
 Derived types must be completely substitutable for their base types.
 Subtypes must be replaceable for the super type references without affecting the program
execution.
 Program to Interface, not the Implementation
Interface Segregation Principle (ISP)
 Clients should not be forced to implement interfaces they don't use
 Create different interfaces based on the method groups
 it produce a flexible design
Dependency Inversion Principle (DIP)
 High-level modules should not depend on low-level modules. Both should depend on
abstractions.
 Abstractions should not depend on details. Details should depend on abstractions.
 High Level Classes --> Abstraction Layer --> Low Level Classes
Object
 Any Real world entity
 Instance of class
 Stores States in Variables & Behaviors in methods
 Constructors – initialize during object creation
 Static blocks
How to Create an Object?
 Using ‘new’ keyword
List<String> obj1 = new ArrayList<String>();
 Using Class.forName() method
MyClass obj2 = Class.forName(“com.mycompany.MyClass”);
 Cloning
Person p1 = new Person();
Person p2 =(Person) p1.clone();
 Deserialization
ObjectInputStream inStream = new ObjectInputStream(null);
MyClass object = (MyClass) inStream.readObject();
 Class Loader
MyClass classLoader = (MyClass ) this.getClass().getClassLoader().loadClass("com.mycompany.MyClass ")
.newInstance();
OOPs Concepts
 Abstraction
 Inheritance
 Encapsulation
 Polymorphism
 Association
 Aggregation
 Composition
Abstraction
 Def: An abstraction denotes the essential characteristics of an object that distinguish it from
all other kinds of object and thus provide crisply defined conceptual boundaries, relative to
the perspective of the viewer
 What it does instead how it does (television)
 Decompose complex systems into smaller components
 Interface & Abstract Classes
 When Should We Use Abstraction
 when we want to achieve abstraction of data or actions
 when functionality is exposed to another component
Inheritance
 extends keyword
 Inherits/Shares the attributes and methods (public or protected) of existing classes
 Code reusability
 One Super-Class -> Multiple Sub-Class => Supported
 One Sub-Class-> Multiple Super-Class (Multiple Inheritance) – NOT Supported
 Compile time
 Super-Class & Sub-Class Constructor
 ‘super’ keyword - access the overridden method in the super class
 IS-A Relationship
 Sub-Class has Same attribute/method as in Super-Class – No inherit occur
 Types
 Single Inheritance
 Multiple Inheritance
 Multi-Level Inheritance
 Hierarchical Inheritance
 Hybrid Inheritance
Encapsulation
 Hide the data & methods into Object
 Binding variables (instance variable) & methods into class
 Security
 Java Bean
 Also referred as ‘Block Box’
 private, public keyword
 Exposes only required things
 java.util.Hashtable
Polymorphism
 one name, many forms
 Overloading(compile-time/Static-binding)
 Method & operator overloading
 Overridding (run-time/Dynamic-binding)
 @Override annotation
 argument list & return type(covariant return type) must be same
 Final & private methods – Can’t Overridden
 Protected methods – can, but within package
 not applicable for static methods or variables (static and non-static)
 can throw any new unchecked (runtime) exception
 Public cannot be made default, but a default can be made public
 Shape Example (draw())
Association
 Relationship between two objects (one-to-one, one-to-many, many-to-one, many-to-many)
 Example: Teacher & Student
 own lifecycle and there is no owner
 Both can exists without each other
Aggregation
 “Has-a” relationship
 Special form of Association
 One object is owner for other
 Example: Teacher & Department
 own lifecycle but child object can not belongs to another parent object
Composition
 Special form of Aggregation
 Child object dose not have their lifecycle
 All the child objects will be deleted if Parent object deleted
 Example: House & Room
OO design Principles & OO basic principles
Access Modifiers
 default
 Public
 Private
 protected
Variables
 Instance Variables (Non-Static Fields)
 Class Variables (Static Fields)
 Local Variables (method level variables)
Thank You All 

OOPs in Java

  • 1.
    OOPs in Java RanjithSekar Jun 2015
  • 2.
    Agenda  Class  SOLIDPrinciples  Object  OOPs Concepts  Access Modifiers  Variables
  • 3.
    Class  Blueprint/template/contract  Properties/Characteristics/Attributes& Actions  Creation of a class  Only one public class per source file  Can contain multiple non-public classes (inner-classes)  Example: Mobile  Attributes (model, manufacturer, cost, operating system etc.,)  Actions (call, file transfer, etc.,)
  • 4.
    SOLID Principles How toidentify and design a Class?  SRP (Single Responsibility Principle)  OCP (Open Closed Principle)  LSP (Liskov Substitution Principle)  ISP (Interface Segregation Principle)  DIP (Dependency Inversion Principle)
  • 5.
    Single Responsibility Principle(SRP)  A class should have only one reason to change (responsibility)  Separation of responsibilities  How to Recognize a Break of the SRP?  Class Has Too Many Dependencies  Method Has Too Many Parameters  The Test Class Becomes Too Complicated  Class / Method is Long (200-250 LOC)  Descriptive Naming  Change In One Place Breaks Another  How to make the design compliant with the Single Responsibility Principle  TDD  Code Coverage Metrics  Refactoring and Design Patterns  Clear Modularization of the System
  • 6.
    Open Closed Principle(OCP)  Minimal changes on existing code (tested already)  Open for extension but closed for modifications  Inheritance using Interface/class  Decorator Design Pattern
  • 7.
    Liskov Substitution Principle(LSP)  Derived types must be completely substitutable for their base types.  Subtypes must be replaceable for the super type references without affecting the program execution.  Program to Interface, not the Implementation
  • 8.
    Interface Segregation Principle(ISP)  Clients should not be forced to implement interfaces they don't use  Create different interfaces based on the method groups  it produce a flexible design
  • 9.
    Dependency Inversion Principle(DIP)  High-level modules should not depend on low-level modules. Both should depend on abstractions.  Abstractions should not depend on details. Details should depend on abstractions.  High Level Classes --> Abstraction Layer --> Low Level Classes
  • 10.
    Object  Any Realworld entity  Instance of class  Stores States in Variables & Behaviors in methods  Constructors – initialize during object creation  Static blocks
  • 11.
    How to Createan Object?  Using ‘new’ keyword List<String> obj1 = new ArrayList<String>();  Using Class.forName() method MyClass obj2 = Class.forName(“com.mycompany.MyClass”);  Cloning Person p1 = new Person(); Person p2 =(Person) p1.clone();  Deserialization ObjectInputStream inStream = new ObjectInputStream(null); MyClass object = (MyClass) inStream.readObject();  Class Loader MyClass classLoader = (MyClass ) this.getClass().getClassLoader().loadClass("com.mycompany.MyClass ") .newInstance();
  • 12.
    OOPs Concepts  Abstraction Inheritance  Encapsulation  Polymorphism  Association  Aggregation  Composition
  • 13.
    Abstraction  Def: Anabstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer  What it does instead how it does (television)  Decompose complex systems into smaller components  Interface & Abstract Classes  When Should We Use Abstraction  when we want to achieve abstraction of data or actions  when functionality is exposed to another component
  • 14.
    Inheritance  extends keyword Inherits/Shares the attributes and methods (public or protected) of existing classes  Code reusability  One Super-Class -> Multiple Sub-Class => Supported  One Sub-Class-> Multiple Super-Class (Multiple Inheritance) – NOT Supported  Compile time  Super-Class & Sub-Class Constructor  ‘super’ keyword - access the overridden method in the super class  IS-A Relationship  Sub-Class has Same attribute/method as in Super-Class – No inherit occur  Types  Single Inheritance  Multiple Inheritance  Multi-Level Inheritance  Hierarchical Inheritance  Hybrid Inheritance
  • 15.
    Encapsulation  Hide thedata & methods into Object  Binding variables (instance variable) & methods into class  Security  Java Bean  Also referred as ‘Block Box’  private, public keyword  Exposes only required things  java.util.Hashtable
  • 16.
    Polymorphism  one name,many forms  Overloading(compile-time/Static-binding)  Method & operator overloading  Overridding (run-time/Dynamic-binding)  @Override annotation  argument list & return type(covariant return type) must be same  Final & private methods – Can’t Overridden  Protected methods – can, but within package  not applicable for static methods or variables (static and non-static)  can throw any new unchecked (runtime) exception  Public cannot be made default, but a default can be made public  Shape Example (draw())
  • 17.
    Association  Relationship betweentwo objects (one-to-one, one-to-many, many-to-one, many-to-many)  Example: Teacher & Student  own lifecycle and there is no owner  Both can exists without each other
  • 18.
    Aggregation  “Has-a” relationship Special form of Association  One object is owner for other  Example: Teacher & Department  own lifecycle but child object can not belongs to another parent object
  • 19.
    Composition  Special formof Aggregation  Child object dose not have their lifecycle  All the child objects will be deleted if Parent object deleted  Example: House & Room
  • 20.
    OO design Principles& OO basic principles
  • 21.
    Access Modifiers  default Public  Private  protected
  • 22.
    Variables  Instance Variables(Non-Static Fields)  Class Variables (Static Fields)  Local Variables (method level variables)
  • 23.