阿川私房教材：學程式，拿 offer！

63 個專案實戰，直接上手！
無需補習，按步驟打造你的面試作品。

立即解鎖你的轉職秘笈
小編精選 - 技術文章翻譯  ·  02月25日

S.O.L.I.D：提升編碼技能的 5 個黃金法則

S.O.L.I.D：提升編碼技能的 5 個黃金法則

在軟體開發領域，這個以其多樣化和強烈持有觀點而聞名的領域，很少有實踐能夠像 SOLID 原則那樣達成共識，作為成為更好的軟體工程師的保證途徑。

Robert C. Martin 在 2000 年代初期正式製定的 5 條黃金法則極大地影響了軟體開發產業，並為更好的程式碼品質和決策過程製定了新標準，至今仍具有相關性。

堅實的原則

SOLID 原則是專門為支援 OOP（物件導向程式設計）範例而設計的。因此，本文是為希望提高開發技能並編寫更優雅、可維護和可擴展程式碼的 OOP 開發人員而設計的。

這裡使用的語言是 TypeScript，遵循常見的跨語言 OOP 概念。需要基本的 OOP 知識。

  1. S = 單一職責原則（SRP）

單一職責原則 (SRP) 是五個 SOLID 原則之一，它規定每個類別應該只有一個職責，以保持有意義的關注點分離。

此模式是一種稱為「上帝物件」的常見反模式的解決方案，「上帝物件」只是指承擔太多職責的類別或物件，使其難以理解、測試和維護。

遵循 SRP 規則有助於使程式碼元件可重複使用、鬆散耦合且易於理解。讓我們探討這項原則，展示 SRP 違規情況和解決方案。

全域宣告

enum Color {
    BLUE = 'blue',
    GREEN = 'green',
    RED = 'red'
}

enum Size {
    SMALL = 'small',
    MEDIUM = 'medium',
    LARGE = 'large'
}

class Product {
    private _name: string;
    private _color: Color;
    private _size: Size;

    constructor (name: string, color: Color, size: Size) {
        this._name = name;
        this._color = color;
        this._size = size;
    }

    public get name(): string { return this._name; }
    public get color(): Color { return this._color; }
    public get size(): Size { return this._size; }
}

違反

在下面的程式碼中， ProductManager類別負責products 的建立和存儲，違反了單一職責原則。

class ProductManager {
    private _products: Product[] = [];

    createProduct (name: string, color: Color, size: Size): Product {
        return new Product(name, color, size);
    }

    storeProduct (product: Product): void {
        this._products.push(product);
    }

    getProducts (): Product[] {
        return this._products;
    }
}

const productManager: ProductManager = new ProductManager();

const product: Product = productManager.createProduct('Product 1', Color.BLUE, Size.LARGE);
productManager.storeProduct(product);

const allProducts: Product[] = productManager.getProducts();

解決

將產品建立和儲存的處理分離到兩個不同的類別可以減少ProductManager類別的職責數量。這種方法進一步模組化了程式碼並使其更易於維護。

class ProductManager {
    createProduct (name: string, color: Color, size: Size): Product {
        return new Product(name, color, size);
    }
}

class ProductStorage {
    private _products: Product[] = [];

    storeProduct (product: Product): void {
        this._products.push(product);
    }

    getProducts (): Product[] {
        return this._products;
    }
}

用法：

const productManager: ProductManager = new ProductManager();
const productStorage: ProductStorage = new ProductStorage();

const product: Product = productManager.createProduct("Product 1", Color.BLUE, Size.LARGE);

productStorage.storeProduct(product);
const allProducts: Product[] = productStorage.getProducts();

  1. O = 開閉原理 (OCP)

“軟體實體應該對擴展開放，但對修改關閉”

開閉原則 (OCP) 是「寫一次，寫得夠好以便可擴展，然後就忘記它」。

這項原則的重要性取決於這樣一個事實：模組可能會根據新的需求不時發生變化。如果在模組編寫、測試並上傳到生產環境後出現新需求，則修改此模組通常是不好的做法，尤其是當其他模組依賴它時。為了防止這種情況，我們可以使用開閉原則。

全域宣告

enum Color {
    BLUE = 'blue',
    GREEN = 'green',
    RED = 'red'
}

enum Size {
    SMALL = 'small',
    MEDIUM = 'medium',
    LARGE = 'large'
}

class Product {
    private _name: string;
    private _color: Color;
    private _size: Size;

    constructor (name: string, color: Color, size: Size) {
        this._name = name;
        this._color = color;
        this._size = size;
    }

    public get name(): string { return this._name; }
    public get color(): Color { return this._color; }
    public get size(): Size { return this._size; }
}

class Inventory {
    private _products: Product[] = [];

    public add(product: Product): void {
        this._products.push(product);
    }

    addArray(products: Product[]) {
        for (const product of products) {
            this.add(product);
        }
    }

    public get products(): Product[] {
        return this._products;
    }
}

違反

讓我們描述一個實作產品過濾類別的場景。讓我們加入按顏色過濾產品的功能。

class ProductsFilter {
    byColor(inventory: Inventory, color: Color): Product[] {
        return inventory.products.filter(p => p.color === color);
    }
}

我們已經測試了此程式碼並將其部署到生產中。

幾天后，客戶請求一項新功能 - 也按大小過濾。然後我們修改該類別以支援新的要求。

現在違反了開閉原則！

class ProductsFilter {
    byColor(inventory: Inventory, color: Color): Product[] {
        return inventory.products.filter(p => p.color === color);
    }

    bySize(inventory: Inventory, size: Size): Product[] {
        return inventory.products.filter(p => p.size === size);
    }
}

解決

在不違反 OCP 的情況下實現過濾機制的正確方法應該使用「規範」類別。

abstract class Specification {
    public abstract isValid(product: Product): boolean;
}

class ColorSpecification extends Specification {
    private _color: Color;

    constructor (color) {
        super();
        this._color = color;
    }

    public isValid(product: Product): boolean {
        return product.color === this._color;
    }
}

class SizeSpecification extends Specification {
    private _size: Size;

    constructor (size) {
        super();
        this._size = size;
    }

    public isValid(product: Product): boolean {
        return product.size === this._size;
    }
}

// A robust mechanism to allow different combinations of specifications
class AndSpecification extends Specification {
    private _specifications: Specification[];

    // "...rest" operator, groups the arguments into an array
    constructor ((...specifications): Specification[]) {
        super();
        this._specifications = specifications;
    }

    public isValid (product: Product): boolean {
        return this._specifications.every(specification => specification.isValid(product));
    }
}

class ProductsFilter {
    public filter (inventory: Inventory, specification: Specification): Product[] {
        return inventory.products.filter(product => specification.isValid(product));
    }
}

用法：

const p1: Product = new Product('Apple', Color.GREEN, Size.LARGE);
const p2: Product = new Product('Pear', Color.GREEN, Size.LARGE);
const p3: Product = new Product('Grapes', Color.GREEN, Size.SMALL);
const p4: Product = new Product('Blueberries', Color.BLUE, Size.LARGE);
const p5: Product = new Product('Watermelon', Color.RED, Size.LARGE);

const inventory: Inventory = new Inventory();
inventory.addArray([p1, p2, p3, p4, p5]);

const greenColorSpec: ColorSpecification = new ColorSpecification(Color.GREEN);
const largeSizeSpec: SizeSpecification = new SizeSpecification(Size.LARGE);

const andSpec: AndSpecification = new AndSpecification(greenColorSpec, largeSizeSpec);
const productsFilter: ProductsFilter = new ProductsFilter();

const filteredProducts: Product[] = productsFilter.filter(inventory, andSpec); // All large green products

過濾機制現在是完全可擴展的。現有的類別不應該再被修改。

如果有新的過濾要求，我們只需建立一個新規範即可。或者如果需要更改規範組合，可以透過使用AndSpecification類別輕鬆完成。

  1. L=里氏替換原理（LSP）

里氏替換原則（LSP）是軟體元件靈活性和穩健性的重要規則。它由 Barbara Liskov 提出，並成為 SOLID 原則的基本要素。

LSP 規定超類別的物件應該可以用子類別的物件替換，而不影響程式的正確性。換句話說，子類別應該擴展超類別的行為而不改變其原始功能。採用這種方法可以提高軟體元件的質量，確保可重複使用性並減少意外的副作用。

違反

下面的範例說明了違反里氏替換原則 (LSP) 的場景。當Rectangle物件被Square物件取代時，透過檢查程序的行為可以觀察到這種違規的跡象。

聲明：

class Rectangle {
    protected _width: number;
    protected _height: number;

    constructor (width: number, height: number) {
        this._width = width;
        this._height = height;
    }

    get width (): number { return this._width; }
    get height (): number { return this._height; }

    set width (width: number) { this._width = width; }
    set height (height: number) { this._height = height; }

    getArea (): number {
        return this._width * this._height;
    }
}

// A square is also rectangle
class Square extends Rectangle {
    get width (): number { return this._width; }
    get height (): number { return this._height; }

    set height (height: number) {
        this._height = this._width = height; // Changing both width & height
    }

    set width (width: number) {
        this._width = this._height = width; // Changing both width & height
    }
}

function increaseRectangleWidth(rectangle: Rectangle, byAmount: number) {
    rectangle.width += byAmount;
}

用法：

const rectangle: Rectangle = new Rectangle(5, 5);
const square: Square = new Square(5, 5);

console.log(rectangle.getArea()); // Expected: 25, Got: 25 (V)
console.log(square.getArea()); // Expected: 25, Got: 25 (V)

// LSP Violation Indication: Can't replace object 'rectangle' (superclass) with 'square' (subclass) since the results would be different.
increaseRectangleWidth(rectangle, 5);
increaseRectangleWidth(square, 5);

console.log(rectangle.getArea()); // Expected: 50, Got: 50 (V)

// LSP Violation, increaseRectangleWidth() changed both width and height of the square, unexpected behavior.
console.log(square.getArea()); //Expected: 50, Got: 100 (X)

解決

重構的程式碼現在遵循 LSP，確保超類別Shape的物件可以替換為子類別Rectangle和Square的物件，而不會影響計算面積的正確性，也不會引入任何改變程式行為的不必要的副作用。

聲明：

abstract class Shape {
    public abstract getArea(): number;
}

class Rectangle extends Shape {
    private _width: number;
    private _height: number;

    constructor (width: number, height: number) {
        super();
        this._width = width;
        this._height = height;
    }

    getArea (): number { return this._width * this._height; }
}

class Square extends Shape {
    private _side: number;

    constructor (side: number) {
        super();
        this._side = side;
    }

    getArea (): number { return this._side * this._side; }
}

function displayArea (shape: Shape): void {
    console.log(shape.getArea());
}

用法：

const rectangle: Rectangle = new Rectangle(5, 10);
const square: Square = new Square(5);

// The rectangle's area is correctly calculated
displayArea(rectangle); // Expected: 50, Got: 50 (V)

// The square's area is correctly calculated
displayArea(square); // Expected: 25, Got: 25 (V)

  1. I = 介面隔離原則 (ISP)

介面隔離原則 (ISP) 強調建立特定於客戶端的介面而不是一刀切的重要性。

這種方法根據客戶的需求集中類，消除了類別必須實現它實際上不使用或不需要的方法的情況。

透過應用介面隔離原則，軟體系統可以以更靈活、易於理解和易於重構的方式建構。讓我們來看一個例子。

違反

這裡違反了 ISP 規則，因為Robot必須實現完全沒有必要的eat()函數。

interface Worker {
    work(): void;
    eat(): void;
}

class Developer implements Worker {
    public work(): void {
        console.log('Coding..');
    }

    public eat(): void {
        console.log('Eating..');
    }
}

class Robot implements Worker {
    public work(): void {
        console.log('Building a car..');
    }

    // ISP Violation: Robot is forced to implement this function even when unnecessary
    public eat(): void {
        throw new Error('Cannot eat!');
    }
}

解決

下面的範例代表了我們之前遇到的問題的解決方案。現在，介面更加簡潔且更加特定於客戶端，允許客戶端類別僅實現與其相關的方法。

interface Workable {
    work(): void;
}

interface Eatable {
    eat(): void;
}

class Developer implements Workable, Eatable {
    public work(): void {
        console.log('Coding..');
    }

    public eat(): void {
        console.log('Eating...');
    }
}

class Robot implements Workable {
    public work(): void {
        console.log('Building a car..');
    }

    // No need to implement eat(), adhering ISP.
}

ISP 前後：

重構前後的介面隔離原則

  1. D = 依賴倒置原理（DIP）

依賴倒置原則（DIP）是最終的SOLID原則，重點是透過使用抽象來減少低層模組（例如資料讀取/寫入）和高層模組（執行關鍵操作）之間的耦合。

DIP 對於設計能夠適應變化、模組化且易於更新的軟體至關重要。

DIP 的關鍵準則是：

  1. 高層模組不應該依賴低層模組。兩者都應該依賴抽象。這意味著應用程式的功能不應該依賴特定的實現，以便使系統更加靈活並且更容易更新或替換低階實現。

  2. 抽像不應該依賴細節。細節應該取決於抽象。這鼓勵設計專注於實際需要什麼操作，而不是如何實現這些操作。

違反

讓我們來看一個展示依賴倒置原則 (DIP) 違規的範例。

MessageProcessor （高階模組）緊密耦合並直接依賴FileLogger （低階模組），違反了原則，因為它不依賴抽象層，而是依賴特定的類別實作。

額外獎勵：這也違反了開閉原則（OCP）。如果我們想要更改日誌記錄機制以寫入資料庫而不是文件，我們將被迫直接修改MessageProcessor函數。

import fs from 'fs';

// Low Level Module
class FileLogger {
    logMessage(message: string): void {
        fs.writeFileSync('somefile.txt', message);
    }
}

// High Level Module
class MessageProcessor {
    // DIP Violation: This high-level module is is tightly coupled with the low-level module (FileLogger), making the system less flexible and harder to maintain or extend.
    private logger = new FileLogger();

    processMessage(message: string): void {
        this.logger.logMessage(message);
    }
}

解決

以下重構的程式碼表示為了遵守依賴倒置原則 (DIP) 所需進行的變更。與前面的範例相反，高階類別MessageProcessor持有特定低階類別FileLogger的私有屬性，現在它持有Logger類型的私有屬性（表示抽象層的介面）。

這種更好的方法減少了類別之間的依賴關係，從而使程式碼更具可擴展性和可維護性。

聲明：

import fs from 'fs';

// Abstraction Layer
interface Logger {
    logMessage(message: string): void;
}

// Low Level Module #1
class FileLogger implements Logger {
    logMessage(message: string): void {
        fs.writeFileSync('somefile.txt', message);
    }
}

// Low Level Module #2
class ConsoleLogger implements Logger {
    logMessage(message: string): void {
        console.log(message);
    }
}

// High Level Module
class MessageProcessor {
    // Resolved: The high level module is now loosely coupled with the low level logger modules.
    private _logger: Logger;

    constructor (logger: Logger) {
        this._logger = logger;
    }

    processMessage (message: string): void {
        this._logger.logMessage(message);
    }
}

用法：

const fileLogger = new FileLogger();
const consoleLogger = new ConsoleLogger();

// Now the logging mechanism can be easily replaced
const messageProcessor = new MessageProcessor(consoleLogger);
messageProcessor.processMessage('Hello');

DIP 之前和之後：

重構前後的依賴倒置原則

結論

透過遵循 SOLID 原則，開發人員在開發或維護任何規模的軟體系統時，可以避免常見的陷阱，例如緊密耦合、缺乏靈活性、程式碼可重複使用性差以及一般維護困難。掌握這些原則是成為更好的軟體工程師的又一步。

原文出處：https://dev.to/idanref/solid-the-5-golden-rules-to-level-up-your-coding-skills-2p82

0個讚   0留言 313瀏覽
共有 0 則留言
登入之後發表留言
小編精選 - 技術文章翻譯
精選技術文章翻譯，幫助開發者持續吸收新知。

阿川私房教材：學程式，拿 offer！

63 個專案實戰，直接上手！
無需補習，按步驟打造你的面試作品。

立即解鎖你的轉職秘笈
熱門文章
🔥 沒有人長大後想成為 DevOps 工程師
🔥 S.O.L.I.D：提升編碼技能的 5 個黃金法則
🔥 增強您的 Windows 開發能力：WSL 終極指南🚀📟
🔥 24 款值得在 2023 年認識一下的 open source 專案
🔥 🚀 🌟 為什麼 Rust 是程式設計領域的明日之星 🔥
最新出爐作業包
⭐ 邁向資深之路：非同步 JS 訓練（二）—— 各種寫法的錯誤處理、收尾處理
⭐ 邁向資深之路：非同步 JS 訓練（一）—— 從 Callback Hell 到 Promise 介面
⭐ Github Desktop 新手入門教學 —— 用漂亮的 GUI 介面來學習 Git 基本觀念
⭐ 邁向資深之路：後端 JS 訓練（二）—— 玩玩看 Express，用純後端做做看部落格
⭐ 邁向資深之路：後端 JS 訓練（一）—— 玩玩看 Node，做做看老派 CLI 應用程式
熱門搜尋： 使用 開發 工作 專案 ui ar javascript 第一 JavaScript 分享 學習 id Git 網站 css for Ml COM 搜尋 技術 console 基礎 作為 git js html 作業 語言 結構 架構 ＣＳＳ 測試 JS 網頁 研究 Ai 後端 前端 jav JAVA app api Github 系列 CD ul Can Java %' javasc 工程師 github AI ci this java GIT go 資料庫 伺服器 Javas 套件 框架 清單 Node 主題 react 部落格 aws Line 公司 課程 Python with user 部署 效率 bi Javascript API 開源 REACT CSS 非同步 Css AWS 編輯 py 分析 json 乾淨 vs Vue create npm 登入 新手 聊天 HTML Html
🛡️ 隱私及網站安全：本站註冊過程「不須提供任何個資」，只要 E-Mail 與帳密即可註冊，請安心註冊！線上付款過程使用「綠界科技 ECPay 」第三方專業金流廠商，全程在「綠界科技 ECPay 」網站進行付款程序，本站「不會紀錄任何信用卡資訊」，請放心付款、解鎖課程！您隨時可以透過 FB 粉專或者 Email 聯絡站長，請求刪除網站上的個人資料。