Menggunakan \'Prinsip Penggantian Liskov\' dengan Typescript dan Java

Konsep

Antara muka

Antara muka mentakrifkan kontrak atau satu set kaedah dan sifat yang mesti dilaksanakan oleh kelas. Antara muka digunakan untuk memastikan kelas mengikut format tertentu, tetapi mereka tidak menyediakan pelaksanaan kaedah, hanya tandatangan mereka.

Setiap kali kelas melaksanakan antara muka, ia menandatangani semua kontrak (kaedah dan atribut) untuk antara muka. Setiap atribut dan kaedah dilaksanakan secara mandatori.

PADAT

SOLID ialah akronim yang mewakili lima prinsip asas pengaturcaraan berorientasikan objek, yang dicadangkan oleh Robert C. Martin - Uncle Bob. Di sini anda boleh membaca lebih lanjut tentang artikelnya.
Prinsip ini bertujuan untuk menambah baik struktur dan penyelenggaraan kod, menjadikannya lebih fleksibel, berskala dan lebih mudah difahami. Prinsip sedemikian membantu pengaturcara mencipta kod yang lebih teratur, membahagikan tanggungjawab, mengurangkan kebergantungan, memudahkan proses pemfaktoran semula dan menggalakkan penggunaan semula kod.

Mengenai LSP

"L" dalam akronim bermaksud "Prinsip Penggantian Liskov". Frasa yang uncle bob gunakan untuk mentakrifkan prinsip ini ialah:

"Kelas terbitan mesti boleh menggantikan kelas asas sepenuhnya"

Oleh itu adalah dicadangkan bahawa kelas terbitan hendaklah sedekat mungkin dengan kelas asas, supaya kelas terbitan boleh menggantikan kelas asasnya tanpa sebarang pengubahsuaian dalam kod.

Prinsip ini telah diperkenalkan oleh Barbara Liskov pada tahun 1988, berdasarkan teori abstraksi dan jenis data. Berasal daripada konsep Reka Bentuk oleh Kontrak (DBC), dipopularkan oleh Bertrand Meyer pada tahun 1986.

Satu lagi spesifikasi prinsip ini ialah:

Subjenis hendaklah digunakan sebagai jenis asas anda tanpa sebarang kejutan.

Dalam pengaturcaraan, perubahan dan kejutan boleh menyebabkan masalah. Jika ciri sistem perlu diganti, ciri baharu mesti memberikan jenis maklumat yang sama, atau sistem mungkin gagal. Untuk memastikan kelas S mempunyai tingkah laku yang sama seperti kelas asas T, adalah penting untuk menggunakan kontrak (antara muka atau kelas abstrak) yang mentakrifkan kaedah mandatori untuk melaksanakan fungsi baharu, untuk menjamin integriti persamaan antara kelas S. dan kelas T.

Aplikasi praktikal

Pertimbangkan kelas asas Burung dengan kaedah fly() yang akan digunakan dalam dua kelas kanak-kanak: Sparrow dan Ostrich.

Fail: bird.java

class Bird {
    void fly() {
        System.out.println("I can fly!");
    }
}

class Sparrow extends Bird {
    // Herda o comportamento de 'fly' da classe 'Bird'
}

class Ostrich extends Bird {
    @Override
    void fly() {
        throw new UnsupportedOperationException("I cannot fly");
    }
}

Fail: bird.ts

class Bird {
  fly() {
    console.log("I can fly!");
  }
}

class Sparrow extends Bird {}

class Ostrich extends Bird {
  fly() {
    throw new Error("I cannot fly");
  }
}

Masalah yang dihadapi

Di sini, kelas Sparrow mematuhi LSP kerana burung pipit memang boleh terbang. Walau bagaimanapun, kelas Ostrich melanggar LSP kerana ia mengatasi kaedah voo() dengan cara yang secara asasnya mengubah tingkah lakunya, melanggar jangkaan yang ditetapkan oleh kelas Ave.

Bagaimana untuk membetulkan?

Kita perlu menggunakan LSP dengan membahagikan setiap kekhususan kelas Sparrow dan Ostrich kepada kontrak (antara muka atau kelas abstrak, di sini saya akan menggunakan antara muka) yang mereka mesti tandatangani untuk memodulasi tingkah laku setiap:

Fail: bird.java

interface Bird {
    String getName();
    void makeSound();
}

interface FlyingBird extends Bird {
    void fly();
}

class Sparrow implements FlyingBird {
    private String name;

    public Sparrow(String name) {
        this.name = name;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public void makeSound() {
        System.out.println("Chirp chirp!");
    }

    @Override
    public void fly() {
        System.out.println(this.name + " is flying!");
    }
}

class Ostrich implements Bird {
    private String name;

    public Ostrich(String name) {
        this.name = name;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public void makeSound() {
        System.out.println("Boom boom!");
    }
}

public class Main {
    public static void main(String[] args) {
        Sparrow sparrow = new Sparrow("Little Sparrow");
        sparrow.makeSound(); // Chirp chirp!
        sparrow.fly(); // Little Sparrow is flying!

        Ostrich ostrich = new Ostrich("Ostrich");
        ostrich.makeSound(); // Boom boom!
        ostrich.fly(); // Error: Method 'fly' does not exist on 'Ostrich'
    }
}

Fail: bird.ts

interface Bird {
  name: string;
  makeSound(): void;
}

interface FlyingBird extends Bird {
  fly(): void;
}

class Sparrow implements FlyingBird {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  makeSound() {
    console.log("Chirp chirp!");
  }

  fly() {
    console.log(`${this.name} is flying!`);
  }
}

class Ostrich implements Bird {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  makeSound() {
    console.log("Boom boom!");
  }
}

const sparrow = new Sparrow("Little Sparrow");
sparrow.makeSound(); // Chirp chirp!
sparrow.fly(); // Little Sparrow is flying!

const ostrich = new Ostrich("Ostrich");
ostrich.makeSound(); // Boom boom!
ostrich.fly(); // Error: Method 'fly' does not exist on 'Ostrich'

Analisis

Penjelasan Pembetulan
Antara Muka Burung: Mentakrifkan tingkah laku yang biasa kepada semua burung, seperti makeSound(). Semua burung mesti melaksanakan antara muka ini.

Antara Muka FlyingBird: Mewarisi daripada Ave dan menambahkan gelagat fly(), yang khusus untuk burung yang boleh terbang.

Kelas Sparrow: Melaksanakan antara muka FlyingBird, kerana burung pipit boleh terbang. Kelas ini mentakrifkan kelakuan kedua-dua mengeluarkan bunyi dan terbang.

Kelas Burung Unta: Hanya melaksanakan antara muka Burung, kerana burung unta tidak boleh terbang. Kelas ini tidak mempunyai kaedah fly() dan oleh itu tidak melanggar LSP.

Kesimpulan

LSP adalah penting untuk memastikan kod itu modular, boleh digunakan semula dan mudah diselenggara. Pelanggaran LSP boleh menyebabkan kod rapuh yang pecah apabila subkelas baharu diperkenalkan atau apabila subkelas sedia ada diubah suai, kerana ini boleh membawa kepada tingkah laku yang tidak dijangka dalam bahagian kod yang bergantung pada superclass.

Penggantian subjenis membolehkan modul dilanjutkan tanpa pengubahsuaian, penting untuk fleksibiliti yang disediakan oleh Prinsip Terbuka/Tertutup (OCP), yang dimungkinkan oleh Prinsip Penggantian Liskov. Kontrak (dilaksanakan melalui antara muka atau kelas abstrak) adalah penting untuk reka bentuk yang selamat, tetapi ia mesti difahami dengan baik oleh pengaturcara, membantu mengelakkan ralat biasa dalam perisian warisan. Mereka juga memberikan panduan berharga tentang cara melaksanakan dan menggunakan kod, hanya dengan mematuhi kontrak yang dipersoalkan.

Implikasi Praktikal

1. Apabila mereka bentuk subkelas, pastikan ia boleh digunakan di mana-mana kelas super mereka digunakan, tanpa memperkenalkan pepijat atau memerlukan pengendalian khas.
2. Elakkan membuat subkelas yang melanggar gelagat kelas super yang diharapkan, kerana ini boleh membawa kepada isu penyelenggaraan dan pepijat yang tidak dijangka.

Memahami dan menggunakan Prinsip Penggantian Liskov membantu pembangun mencipta sistem berorientasikan objek yang lebih boleh diramal dan stabil.

Atas ialah kandungan terperinci Menggunakan \'Prinsip Penggantian Liskov\' dengan Typescript dan Java. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!