Show Menu
Cheatography
  1. Home >
  2. Programming >

OOP key terms and principles Cheat Sheet by

Basic terms of object-oriented programming, table with comparison Abstract class and Interface in Java, SOLID principles, and Composition, Aggregation, Association.

OOP

Object­-or­iented progra­mming is a model that organizes software design around objects which interact with each other.

Basic terms

Class
Data type acting like blueprint for individual objects, attrib­utes, and methods. And rules for intera­cting with this entity
Objects
Instances of class created with specif­ically defined data. Object has a state (fields) and behavior (methods).
Methods
Functions describing behaviors of object.
Attributes
Defined in class template and represent state of object. Object fields.

Abstract Class | Interface

 
Abstract Class
Interface
Describes
Attrib­utes, methods
Methods
For classes
With close connec­tions (inher­itance)
That could have nothing in common
Multiple Inheri­tance
Key words
Implements interface
Extends class
Extends interface
Attributes
Methods without realis­ation
(
abstract
keyword)
Methods with realis­ation
(
default
keyword)
Constr­uctor
Access modifiers
any
 
public
(default), 
private
for methods with realis­ation
 

Inhe­rit­ance ( “is-a” relati­onship)

We can create a new class based on existing class. The new class can reuse the code and behavior of the ancestor class, and it can also add new features or modify the existing behavior.

Types:
• Single (one parent, one child)
• Multi-­level (child is created from another child)
• Multiple (many parents, one child)
• Hierar­chical (one parent, many children)
• Hybrid (child extend several parents, where one or more of them is a combin­ation of different types of inheri­tance)

Enca­psu­lat­ion (What happens in Vegas...)

By encaps­ulating a class's variables, only the methods of the class can access them. It protects the data from external access or modifi­cation.

Poly­mor­phism

Subclasses can define their own behaviors and yet share some of the same functi­onality of the parent class.
Compile time polymo­rphism -- Method overlo­ading
Class can have more than one method with the same name, but with different parameters
Run time polymo­rphism - Method overriding
An instance method in a subclass with the same signature (name, plus the number and the type of its parame­ters) and return type as an instance method in the superclass overrides the superc­lass's method.

Abst­rac­tion

We exposing only an object's relevant details to the outside world. And hiding the implem­ent­ation details. Reduces the code's complexity and makes it easier to use.

Not only Inheri­tance

Compos­ition “has-a” (strong connec­tion)
Building has a room. Containing object owns it. Objects' lifecycles are tied (if we destroy the owner object, its members also will be destroyed with it)
Aggreg­ation “has-a” (medium connec­tion)
Сar and its wheels. We can take off the wheels, and they'll still exist. Doesn't involve owning. Lifecycles of the objects aren't tied: every one of them can exist indepe­ndently of each other.
Associ­ation objects “know” each other (weak connec­tion)
Mother and child. The difference with aggreg­ation is only logical: whether one of the objects is part of other or not.

SOLID principles

Single Respon­sib­ility
Class should have a single, well-d­efined respon­sib­ility and should not be respon­sible for multiple things.
Open-C­losed
Software enteties (classes, modules, functions) should be open for extension but closed for modifi­cation. You should be able to add new functi­onality to class without changing its existing code.
Liskov Substi­tution
Objects of a subclass should be able to be used in the same way as objects of parent class without issues.
Interface Segreg­ation
Classes shouldn’t have to implement interfaces that they don't need.
Dependency Inversion
High-level modules (i.e., classes depending on other classes) should not depend on low-level modules. Both should depend on abstra­ctions. So, it's easier to change implem­ent­ation of low-level module without affecting high-level module.
   
 

Metadata

  • Languages:
  • Published: 4th August, 2023
  • Last Updated: 8th August, 2023

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Object Oriented Design Cheat Sheet
          Object-Oriented Design Principles Cheat Sheet
          Object Oriented Rules Cheat Sheet