DEV Community: Sivakumar Natarajan

OOP - Abstraction - Part 2

Sivakumar Natarajan — Sun, 08 Dec 2024 10:49:44 +0000

What ?

We have already looked at Part1 of the definition here. Now let's dive deep into the part 2.

Part 2: Abstraction is the process of hiding implementation details from users, enabling them to focus on the functionality rather than the internal workings.

note: Users in the definition points to developers.

Why (hide implementation details) ?

Scenario: A new service importing an already existing reusable authentication setup.

A usual setup as part of the authentication process is to hash user passwords before comparing them with stored credentials. However, for a user of this reusable Authentication class, it suffices for them to know if a given credential is valid or not; it's not necessary for them to know about this particular hashing logic, as it's an implementation detail.

In the above scenario, by hiding the implementation detail we gained benefits like,

Controlled access (users can't access the hashing setup)
Focus on the WHAT rather than the HOW
Reduced complexity/cognitive load
Reduced maintenance efforts - Because the hashing process is not open for users, if there is a need to change the hashing algorithm it's simple to refactor as no one else is using it.

How

There are several ways to hide implementation detail to achieve abstraction. However, let's focus on using the abstract keyword to maintain consistency with the examples from Part 1 and ensure the explanation remains intuitive.

Scenario:

Designing a coffee machine capable of making a variety of coffee flavours

Ofcourse, there are several ways to achieve this, and that's the beauty of software programming. However, one effective way to implement such a coffee machine is by using abstraction — hiding the implementation details and allowing the user or programmer to focus on selecting the desired coffee flavour.

Solution

The below code snippet uses partial abstract class that's explained in detail on part 1 of this blog post.

type CupSize = "small" | "medium" | "large";

type CoffeeTemperature = "hot" | "warm" | "ice";

type Milk = "almond" | "semi-skimmed" | "full-fat" | "skimmed";

// Partial abstract class with all implementation details hidden
abstract class CoffeeMachine {
  private cupSize: CupSize;
  private coffeeTemperature: CoffeeTemperature;
  private milk: Milk | undefined;
  constructor(
    cupSize: CupSize,
    coffeeTemperature: CoffeeTemperature,
    milk?: Milk
  ) {
    this.cupSize = cupSize;
    this.coffeeTemperature = coffeeTemperature;
    this.milk = milk;
  }
  private setCoffeeCupSize() {
    console.log(`set Coffee cup size to - ${this.cupSize}`);
  }

  private heatWater() {
    console.log(`heating water to default temperature`);
  }

  private addMilk() {
    this.milk
      ? console.log(`milk addition - ${this.milk}`)
      : console.log(`no milk added`);
  }

  private setCoffeeTemperature() {
    console.log(
      `heating coffee to provided temperature - ${this.coffeeTemperature}`
    );
  }

  // the only abstract method
  protected abstract addExtras(): void;

  public makeCoffee() {
    this.setCoffeeCupSize();
    this.heatWater();
    this.addMilk();
    this.setCoffeeTemperature();
    this.addExtras();
  }
}

Introducing Cappuccino flavour:

Now it's straight forward to introduce any new flavour as we have an abstract class with all implementation details that is hidden away from the developer extending the machine to one more flavour.

// Subclass inheriting concrete methods from CoffeeMachine but als extends an abstract method
class Cappuccino extends CoffeeMachine {
  constructor(
    cupSize: CupSize,
    temperaturemilk: CoffeeTemperature,
    milk?: Milk
  ) {
    super(cupSize, temperaturemilk, milk);
  }

  protected addExtras(): void {
    console.log(`adding Cappuccino coffee pod`);
  }
}

Making the coffee

const coffee = new Cappuccino("large", "hot", "almond");
// makeCoffee on Cappuccino object works here because its inherited from CoffeeMachine
coffee.makeCoffee();

Conclusion

In summary, abstraction is a cornerstone of object-oriented programming that simplifies complex systems by hiding unnecessary details and exposing only the essential features. By defining clear blueprints or contracts, abstraction promotes code clarity, consistency, and extensibility. It allows developers to focus on higher-level design while ensuring the underlying implementation remains flexible and reusable.

Through the examples provided, we’ve seen how abstraction helps streamline workflows, encourages adherence to design principles, and makes systems easier to maintain and scale. Whether using abstract classes, interfaces, or encapsulated methods, abstraction is a powerful tool for building robust and efficient software systems.

OOP - Abstraction - Part 1

Sivakumar Natarajan — Wed, 04 Dec 2024 22:25:31 +0000

What ?

Definitions

Part 1: Abstraction provides a blueprint or plan for designing classes with a defined set of rules. It ensures consistency and enforces that certain behaviors are implemented across derived classes.

Part 2: Abstraction is the process of hiding implementation details from users, enabling them to focus on the functionality rather than the internal workings.

Eg: A commonly used analogy is the TV remote control: users interact with buttons to operate the TV without needing to know how the internal mechanics work.

I find Part 1 to be more intuitive and easy to explain so this post explains in detail Part 1 of the definition.

Part 2 is explained in detail here.

Why a blueprint?

To understand the need for abstraction (a blue print), let’s first explore a problem.

Problem:

Imagine creating classes to draw pictures of animals. Each animal has its own unique features, but certain traits—such as having four legs and a tail—are shared among them. Without a structured approach, developers might forget to include these common traits, leading to incomplete or inaccurate depictions.

class DogPicture {
  drawATail() {}

  drawFourLegs() {}

  drawFloppyEars() {}
}

class CatPicture {
  drawATail() {}

  drawFourLegs() {}

  drawConeShapedEars() {}
}

class HorsePicture {
  drawATail() {}

  drawFourLegs() {}

  drawManeHair() {}
}

class GoatPicture {
  drawATail() {}

  drawFourLegs() {}

  drawHorns() {}
}

class ZebraPicture {
  drawATail() {}

  drawFourLegs() {}

  drawStripesOnBody() {}
}

Solution:

Abstraction can solve this problem by defining a shared plan or rules that every animal picture class must follow. This can be achieved using an abstract class or interface in TypeScript.

abstract class AnimalPicture {
  abstract drawFourLegs(): void;

  abstract drawATail(): void;
}

Now, any class that implements AnimalPicture must define these methods. Failing to do so will result in an error.

Incorrect implementation

class DogPicture implements AnimalPicture { // this will throw error as `drawFourLegs` & `drawATail` are not implemented. 
  drawFloppyEars() {}
}

Error:

Class 'DogPicture' incorrectly implements class 'AnimalPicture'. Did you mean to extend 'AnimalPicture' and inherit its members as a subclass?
  Type 'DogPicture' is missing the following properties from type 'AnimalPicture': drawFourLegs, drawATailts(2720)

Correct implementation

class DogPicture implements AnimalPicture {
  drawFourLegs(): void {
    console.log("Drawing four legs for a dog.");
  }
  drawATail(): void {
    console.log("Drawing four legs for a dog.");
  }
  drawFloppyEars() {}
}

class CatPicture implements AnimalPicture {
  drawFourLegs(): void {
    console.log("Drawing four legs for a cat.");
  }
  drawATail(): void {
    console.log("Drawing four legs for a cat.");
  }
  drawConeShapedEars() {}
}

class HorsePicture implements AnimalPicture {
  drawFourLegs(): void {
    console.log("Drawing four legs for a horse.");
  }
  drawATail(): void {
    console.log("Drawing four legs for a horse.");
  }
  drawManeHair() {}
}

class GoatPicture implements AnimalPicture {
  drawFourLegs(): void {
    console.log("Drawing four legs for a goat.");
  }
  drawATail(): void {
    console.log("Drawing four legs for a goat.");
  }
  drawHorns() {}
}

class ZebraPicture implements AnimalPicture {
  drawFourLegs(): void {
    console.log("Drawing four legs for a zebra.");
  }
  drawATail(): void {
    console.log("Drawing four legs for a zebra.");
  }
  drawStripesOnBody() {}
}

This ensures that all animal picture classes implement the shared rules (drawFourLegs and drawATail), while allowing flexibility for unique features like floppy ears or stripes.

Types of abstract classes:

- Pure abstract class

These classes are plain blueprints that won't have any concrete/implemented methods.

// pure abstract class
abstract class AnimalPicture {
  abstract drawFourLegs(): void;

  abstract drawATail(): void;
}

In Typescript these pure abstract classes (with no access privilege needs like protected) can be replaced with interfaces which is as well could as a blue print.

// interface
interface AnimalPicture {
  drawFourLegs(): void;

  drawATail(): void;
}

//usage
class HorsePicture implements AnimalPicture {
  drawFourLegs(): void {
    console.log("Drawing four legs for a horse.");
  }
  drawATail(): void {
    console.log("Drawing four legs for a horse.");
  }
  drawManeHair() {}
}

- Impure/partial abstract class:

Abstract classes that have one or more concrete methods along with a few abstract attributes(methods/properties).

These classes can be extended(inherited) to create sub classes.

Defining the abstract class

// impure abstract class
abstract class AnimalPicture {
  // Concrete method 1
  protected drawFourLegs() {
    console.log(`drawing common four legs feature`);
  }

  // Concrete method 2
  protected drawATail() {
    console.log(`drawing common tail feature`);
  }

  // Abstract method 1
  protected abstract drawUniqueFeature(): void;

  // Concrete method 3
  public drawFinalPicture() {
    this.drawATail();
    this.drawFourLegs();
    this.drawUniqueFeature();
  }
}

Extending the abstract class

class DogPicture extends AnimalPicture {
  // because its inheritance, calling the super/parent class is required.
  constructor() {
    super();
  }
  // Abstract method 1 implemented
  protected drawUniqueFeature(): void {
    console.log("Drawing four legs for a dog.");
  }
}

Usage

const dog = new DogPicture();
// Concrete method 3 of abstract class is inherited
dog.drawFinalPicture();

Part1(abstract as blueprint) Conclusion

Abstraction in OOP helps enforce a consistent structure across related classes while allowing flexibility for unique implementations. It ensures that essential behaviors are not overlooked, making code more predictable and maintainable.

Also, please carryon reading the part2 post to understand the part2 of the definition.

OOPS - Inheritance

Sivakumar Natarajan — Sat, 30 Nov 2024 13:21:36 +0000

What ?

Inheritance concept allows a class to inherit properties and behaviors from another class.

Why ?

Let's understand the necessity of inheritance and the problem that it solves using an example.

Task:

Build a website that allows users to view and handle their electricity account. It should have the below pages,

Dashboard
Account summary
Payments page and more importantly the pages should be visible only to logged in user.

Find below some pseudo code that could achieve the task in hand,

Dashboard page:

class Dashboard {
  login() {
    // some logic to login the user
    console.log(`User logged in successfully`);
  }
}

const dashObj = new Dashboard();
dashObj.login();

Payments page:

class PaymentPage {
  login() {
    // some logic to login the user
    console.log(`User logged in successfully`);
  }
}

const payObj = new PaymentPage();
payObj.login();

AccountSummary page:

class AccountSummaryPage {
  login() {
    // some logic to login the user
    console.log(`User logged in successfully`);
  }
}

const accObj = new AccountSummaryPage();
accObj.login();

Problems:

Redundancy: Each class repeats the same login() method. As the number of pages grows, so does the duplication of this logic.
Maintainability: If the login logic changes, every class needs to be updated, increasing the risk of errors.

How to solve? (Inheritance to rescue)

We can solve the problem by extracting the common functionality (login) into a base class. The individual page classes will then inherit this functionality.

Parent/Base class:

class LoginParent {
  login() {
    // some logic to login the user
    console.log(`User logged in successfully`);
  }
}

Child classes inheriting the parent's method/members:

class DashboardChild extends LoginParent {}

class PaymentPageChild extends LoginParent {}

class AccountSummaryChild extends LoginParent {}

Usage:

const dash = new DashboardChild();
dash.login();

const pay = new PaymentPageChild();
pay.login();

const acc = new AccountSummaryChild();
acc.login();

Advantages:

Reusability: The login() method is defined once in the base class and reused across all pages.
Maintainability: Any updates to the login() logic need to be made only in the base class, reducing the scope for errors.
Clarity: The code for each page focuses only on page-specific functionality, keeping the implementation clean and focused.

When to Use Inheritance?

Inheritance is useful when:

Classes share common functionality that is central to their behavior.
You want to adhere to the DRY (Don’t Repeat Yourself) principle.
You aim to create a hierarchical structure to represent relationships between entities.

Conclusion:

Inheritance simplifies code by promoting reusability and maintainability. By moving shared logic into a base class, we can eliminate redundancy, making the application easier to scale and manage.

OOP - Encapsulation

Sivakumar Natarajan — Sat, 30 Nov 2024 13:20:10 +0000

What ???

Encapsulation is the process of bundling data & functions into a single unit (i.e., capsule), it can also limit access to some of the data/methods.

It is one of the four pillars of OOP, along with Inheritance, Polymorphism, and Data Abstraction.

Why ?

It's easier to take a blind assumption and proceed using encapsulation at all places, but its important to understand the why so you could use it the right way.

Let's try to understand the why(s) by looking at an example task.

Task:

Build a student result calculator that should,

Calculate the average mark
Determine if a student is failed or passed
Throw error if any of the subjects mark is invalid ( < 0 || > 100)

Solution 1: the non-encapsulated way

The idea is to just to solve the problem, so I have chosen the Procedural programming way of achieving it which I believe could show good contrast between the two solutions and make the problems of the non-encapsulated approach more obvious.

type Subject = "english" | "maths";

interface IStudent {
  name: string;
  marks: Record<Subject, number>;
}

// Receive Input
const studentInput: IStudent = {
  name: "John",
  marks: {
    english: 100,
    maths: 100,
  },
};

// Step1: Validate the provided marks
Object.keys(studentInput.marks).forEach((subjectName) => {
  const mark = studentInput.marks[subjectName as Subject];
  if (mark > 100 || mark < 0) {
    throw new Error(`invlid mark found`);
  }
});

// Step2: find the total marks
const totalMarks = Object.keys(studentInput.marks).reduce(
  (accumulator: number, current: string) =>
    studentInput.marks[current as Subject] + accumulator,
  0
);

// Step3: find the average
const average = totalMarks / Object.keys(studentInput.marks).length;

// Step4: find the result
const boolResult = average > 40;

// Step 5: print result
console.log(boolResult);
console.log(average);

Problems with Solution 1:

This definitely achieves the expected result but there are several problems associated to it. To name a few,

Every implementation here is globally accessible and there is no control over its usage by future contributors.

Data & operations are separate making it hard to trace which functions affect the data. You would have to carefully go through every piece of code to understand what is called and part of an execution.

Functions become harder to manage as the logic scales. Changes can break unrelated code due to tight coupling.

How to solve the problem ?

By incorporating Encapsulation or make it more obvious by doing the below two steps,

Controlled Access to Data & functions
Bundling Data with Behaviour

Solution 2: The Encapsulated way

type SubjectNames = "english" | "maths";

interface IStudent {
  name: string;
  marks: Record<SubjectNames, number>;
}

class ResultCalculator {
  protected student: IStudent;
  constructor(student: IStudent) {
    this.student = student;
  }

  isPassed(): boolean {
    let resultStatus = true;
    Object.keys(this.student.marks).forEach((subject: string) => {
      if (this.student.marks[subject as SubjectNames] < 40) {
        resultStatus = false;
      }
    });
    return resultStatus;
  }

  getAverage(): number {
    this.validateMarks();
    return this.totalMarks() / this.subjectCount();
  }

  private validateMarks() {
    Object.keys(this.student.marks).forEach((subject: string) => {
      if (
        this.student.marks[subject as SubjectNames] < 0 ||
        this.student.marks[subject as SubjectNames] > 100
      ) {
        throw new Error(`invalid mark`);
      }
    });
  }

  private totalMarks() {
    return Object.keys(this.student.marks).reduce(
      (acc, curr) => this.student.marks[curr as SubjectNames] + acc,
      0
    );
  }

  private subjectCount() {
    return Object.keys(this.student.marks).length;
  }
}

// Receive Input
const a: IStudent = {
  name: "jingleheimer schmidt",
  marks: {
    english: 100,
    maths: 100,
  },
};

// Create an encapsulated object
const result = new ResultCalculator(a);

// Perform operations & print results
console.log(result.isPassed());
console.log(result.getAverage());

notice in the above solution,

Methods totalMarks, subjectCount, validateMarks & the member variable student are not exposed and can only be used by the class object.

2.the data student is bundled with every behaviour of it.