Cookie Consent by Free Privacy Policy Generator 📌 Single Responsibility Principle


✅ Single Responsibility Principle


💡 Newskategorie: Programmierung
🔗 Quelle: dev.to

Links

REPO
Linkedin
Github

Info : Single-responsibility principle - Wikipedia

The Single Responsibility Principle (SRP) is one of the SOLID principles of object-oriented programming. It states that a class should have only one reason to change. In other words, a class should have only one responsibility or job.

node dist/srp.js

Each class should focus on a single responsibility or task.

Example: E-commerce Order System

  • Imagine an e-commerce platform with an order processing system.
  • The system handles various tasks:
    • Product management
    • Order creation
    • Pricing calculation
    • Invoice generation
    • Payment processing
|---srp.ts 
|---order
    |---Order.ts
    |---Product.ts   
    |---Jobs
         |---invoice.ts
         |---PaymentProcessor.ts
         |---PricingCalculator.ts

Breaking Down Responsibilities

  • Product Class (Product.ts):
    • Responsible for representing product details (ID, name, price).
  • Order Class (Order.ts):
    • Manages the list of products in an order.
    • Adds and retrieves products.
  • Invoice Class (invoice.ts):
    • Generates an invoice for an order.
    • Displays product names and prices.
  • PaymentProcessor Class (PaymentProcessor.ts):
    • Handles payment processing.
    • Sends emails and updates accounting.
  • PricingCalculator Class (PricingCalculator.ts):
    • Calculates the total price of an order.

order/Product.ts

export class Product {

    constructor(id: string, name: string, price: number) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    id : string;
    name : string;
    price : number;
}

order/Order.ts

import {Product} from "./Product";
export class Order {
    product: Product [] = []

    addProduct(product: Product) {
        this.product.push(product)
    }

    getProduct() {
        return this.product
    }
}

order/Jobs/invoice.ts

import {Product} from "../Product";

export class Invoice {

    generateInvoice(product: Product[] , amount: number) {
        console.log(`
        Invoice Date : ${new Date().toLocaleString()}
        _____________________________

        Product Name\t\t\tPrice
        `);

        product.forEach((product:Product)=> {
            console.log(`${product.name}\t\t\t${product.price}`)
        });

        console.log(`_____________________________`);
        console.log(`Total Price : ${amount}`)
    }
}

order/Jobs/PaymentProcessor.ts

import {Order} from "../Order";

export class PaymentProcessor {
    processPayment(order: Order) {
        console.log(`Processing payment...`)
        console.log(`Payment processed successfully.`)
        console.log(`Added to accounting system!`)
        console.log(`Email sent to customer!`)
    }
}

order/Jobs/PricingCalculator.ts

import {Product} from "../Product";

export class PricingCalculator {
    calculatePricing(products: Product[]): number {
        return products.reduce((acc, product) => acc + product.price, 0);
    }
}

Exceptions and Violations

  • Exceptions:
    • Sometimes, combining responsibilities is necessary for efficiency.
    • For example, tightly coupling pricing calculation and order management might be acceptable.
  • Violations:

    // Product class representing product details
    class Product {
        constructor(public id: string, public name: string, public price: number) {}
    }
    
    // Imagine an Order class that handles both order management and payment processing
    class Order {
        private orderID: string;
        private products: Product[];
    
        constructor(orderID: string) {
            this.orderID = orderID;
            this.products = [];
        }
    
        addProduct(product: Product) {
            this.products.push(product);
        }
    
        calculateTotalPrice(): number {
            return this.products.reduce((total, product) => total + product.price, 0);
        }
    
        processPayment(paymentMethod: string) {
            // Process payment logic here
            console.log(`Payment for order ${this.orderID} processed via ${paymentMethod}`);
        }
    }
    
    // Usage
    const product1 = new Product("1", "Laptop", 200000);
    const product2 = new Product("2", "Phone", 60000);
    
    const order = new Order("123");
    order.addProduct(product1);
    order.addProduct(product2);
    
    const total = order.calculateTotalPrice();
    console.log(`Total price: ${total}`);
    
    order.processPayment("Credit Card");
    
    • The Order class combines two distinct responsibilities: managing the list of products (order management) and processing payments.
    • Violation: If payment processing logic changes, it impacts the Order class, which should focus only on order management.
    • Solution: Separate payment processing into a dedicated class (e.g., PaymentProcessor). Each class should have a clear purpose to adhere to SRP.

srp.ts

import {Product, Order, PricingCalculator, Invoice ,PaymentProcessor} from "./order";

const product1 = new Product("1","Laptop", 200000);
const product2 = new Product("2","Phone", 60000);
const product3 = new Product("3", "Car", 8000000);

const order = new Order();

order.addProduct(product1);
order.addProduct(product2);
order.addProduct(product3);

const pricingCalculator = new PricingCalculator();
const total = pricingCalculator.calculatePricing(order.getProduct());

const invoice = new Invoice();
invoice.generateInvoice(order.getProduct(), total);

const paymentProcessor = new PaymentProcessor();
paymentProcessor.processPayment(order);

Summary

  • SRP ensures that each class has a clear purpose.
  • By separating concerns, we improve maintainability and reduce the impact of changes.
  • In our e-commerce example, adhering to SRP leads to a more robust and flexible system.
...

✅ Series Belajar Solid Principle - Single Responsibility Principle (SRP)


📈 59 Punkte

✅ Understanding the Single Responsibility Principle (SRP)


📈 41.8 Punkte

✅ #1 Single Responsibility Principle ['S' in SOLID]


📈 41.8 Punkte

✅ Single Responsibility Principle


📈 41.8 Punkte

✅ Series Belajar Solid Principle - Liskov Substitution Principle (LSP)


📈 34.41 Punkte

✅ Series Belajar Solid Principle - Open Close Principle (OCP)


📈 34.41 Punkte

✅ Refugee Responsibility Sharing or Responsibility Dumping?


📈 30.52 Punkte

✅ HITRUST Shared Responsibility: Assigning privacy and responsibility on the cloud


📈 30.52 Punkte

✅ Single Sign-On bis 1.3.3/1.4.2 auf Cloud Foundry Single Sign-On service UI Cross Site Scripting


📈 18.66 Punkte

✅ A single protective technology means a single point of failure


📈 18.66 Punkte

✅ Single-SPA Parcels and vite-plugin-single-spa


📈 18.66 Punkte

✅ Single Sign-On up to 1.3.3/1.4.2 on Cloud Foundry Single Sign-On service UI cross site scripting


📈 18.66 Punkte

✅ Single single-sign-on SNAFU threatens three Cisco products


📈 18.66 Punkte

✅ 🚀 Understanding the YAGNI Principle in Software Development


📈 17.21 Punkte

✅ [Reflective Coding Journal] The DRY Principle: A Lazy Programmer's Best Friend


📈 17.21 Punkte

✅ Open/Closed Principle


📈 17.21 Punkte

✅ On the Principle of Non-Use of Force in Current International Law


📈 17.21 Punkte

✅ 6 Most Important Used Design Principle for UX Design.


📈 17.21 Punkte

✅ The Principle of Proportionality in the DoD Law of War Manual


📈 17.21 Punkte

✅ The Cicada Principle and Why It Matters to Web Designers (updated)


📈 17.21 Punkte

✅ Organizations Fail to Maintain Principle of Least Privilege


📈 17.21 Punkte

✅ COVID-19 and International Law: Refugee Law – The Principle of Non-Refoulement


📈 17.21 Punkte

✅ Boosting Development Efficiency With the Specification-First Principle


📈 17.21 Punkte

✅ Plato im Escape Room: «Talos Principle 2» im Test


📈 17.21 Punkte

✅ Software Design Principle: Inversion of Control(IOC) and Dependency Injection


📈 17.21 Punkte

✅ Do Moral Judgments of War Support the Principle of Combatant Equality?: What Empirical Studies Tells Us


📈 17.21 Punkte

✅ #5 Dependency Inversion Principle ['D' in SOLID]


📈 17.21 Punkte

✅ Applying the Tyson Principle to Cybersecurity: Why Attack Simulation is Key to Avoiding a KO


📈 17.21 Punkte











matomo

Datei nicht gefunden!