Apakah ini merupakan pelanggaran terhadap Prinsip Pergantian Liskov?

Katakanlah kita memiliki daftar entitas Tugas, dan ProjectTasksub tipe. Tugas dapat ditutup kapan saja, kecuali ProjectTasksyang tidak dapat ditutup setelah status Mulai. UI harus memastikan opsi untuk menutup permulaan ProjectTasktidak pernah tersedia, tetapi beberapa perlindungan ada dalam domain:

public class Task
{
     public Status Status { get; set; }

     public virtual void Close()
     {
         Status = Status.Closed;
     }
}

public class ProjectTask : Task
{
     public override void Close()
     {
          if (Status == Status.Started) 
              throw new Exception("Cannot close a started Project Task");

          base.Close();
     }
}

Sekarang ketika memanggil Close()suatu Tugas, ada kemungkinan panggilan akan gagal jika itu adalah ProjectTaskdengan status yang dimulai, ketika itu tidak akan jika itu adalah Tugas dasar. Tetapi ini adalah persyaratan bisnis. Itu harus gagal. Bisakah ini dianggap sebagai pelanggaran prinsip substitusi Liskov ?

Ya, ini merupakan pelanggaran terhadap LSP. Prinsip Pergantian Liskov mensyaratkan itu

• Prasyarat tidak dapat diperkuat dalam subtipe.
• Postconditions tidak dapat dilemahkan dalam subtipe.
• Invarian tipe supertipe harus dipertahankan dalam subtipe.
• Batasan sejarah ("aturan sejarah"). Objek dianggap dapat dimodifikasi hanya melalui metode mereka (enkapsulasi). Karena subtipe dapat memperkenalkan metode yang tidak ada dalam supertipe, pengenalan metode ini memungkinkan perubahan status pada subtipe yang tidak diizinkan dalam supertipe. Batasan sejarah melarang ini.

Contoh Anda melanggar persyaratan pertama dengan memperkuat prasyarat untuk memanggil Close()metode.

Anda dapat memperbaikinya dengan membawa pra-kondisi yang diperkuat ke tingkat atas hierarki warisan:

public class Task {
    public Status Status { get; set; }
    public virtual bool CanClose() {
        return true;
    }
    public virtual void Close() {
        Status = Status.Closed;
    }
}

Dengan menetapkan bahwa panggilan Close()valid hanya di negara bagian ketika Anda CanClose()kembali, trueAnda membuat pra-kondisi berlaku untuk Taskdan juga untuk ProjectTask, memperbaiki pelanggaran LSP:

public class ProjectTask : Task {
    public override bool CanClose() {
        return Status != Status.Started;
    }
    public override void Close() {
        if (Status == Status.Started) 
            throw new Exception("Cannot close a started Project Task");
        base.Close();
    }
}

Iya. Ini melanggar LSP.

Saran saya adalah menambahkan CanClosemetode / properti ke tugas dasar, sehingga tugas apa pun dapat mengetahui apakah tugas dalam kondisi ini dapat ditutup. Itu juga bisa memberikan alasan mengapa. Dan menghapus virtual dari Close.

Berdasarkan komentar saya:

public class Task {
    public Status Status { get; private set; }

    public virtual bool CanClose(out String reason) {
        reason = null;
        return true;
    }
    public void Close() {
        String reason;
        if (!CanClose(out reason))
            throw new Exception(reason);

        Status = Status.Closed;
    }
}

public ProjectTask : Task {
    public override bool CanClose(out String reason) {
        if (Status != Status.Started)
        {
            reason = "Cannot close a started Project Task";
            return false;
        }
        return base.CanClose(out reason);
    }
}

Prinsip substitusi Liskov menyatakan bahwa kelas dasar harus dapat diganti dengan sub-kelasnya tanpa mengubah sifat yang diinginkan dari program. Karena hanya ProjectTaskmenimbulkan pengecualian ketika ditutup, program harus diubah menjadi acommodate untuk itu, harus ProjectTaskdigunakan sebagai pengganti Task. Jadi itu pelanggaran.

Tetapi jika Anda memodifikasi Taskpernyataan dalam tanda tangannya bahwa hal itu dapat menimbulkan pengecualian saat ditutup, maka Anda tidak akan melanggar prinsip.

Pelanggaran LSP membutuhkan tiga pihak. Tipe T, Subtipe S, dan program P yang menggunakan T tetapi diberi instance S.

Pertanyaan Anda telah memberikan T (Tugas) dan S (ProjectTask), tetapi tidak P. Jadi pertanyaan Anda tidak lengkap dan jawabannya memenuhi syarat: Jika ada P yang tidak mengharapkan pengecualian, maka untuk P itu, Anda memiliki LSP pelanggaran. Jika setiap P mengharapkan pengecualian maka tidak ada pelanggaran LSP.

Namun, Anda memang memiliki pelanggaran SRP . Fakta bahwa keadaan tugas dapat diubah, dan kebijakan yang tugas-tugas tertentu di negara-negara tertentu harus tidak diubah ke negara-negara lain, dua tanggung jawab yang sangat berbeda.

• Tanggung jawab 1: Mewakili tugas.
• Tanggung jawab 2: Menerapkan kebijakan yang mengubah keadaan tugas.

Kedua tanggung jawab ini berubah karena alasan yang berbeda dan karenanya harus berada di kelas yang terpisah. Tugas harus menangani fakta sebagai tugas, dan data yang terkait dengan tugas. TaskStatePolicy harus menangani cara transisi tugas dari negara ke negara dalam aplikasi yang diberikan.

Ini mungkin atau mungkin bukan merupakan pelanggaran terhadap LSP.

Serius. Dengarkan aku.

Jika Anda mengikuti LSP, objek bertipe ProjectTaskharus berperilaku sebagai objek bertipe Taskdiharapkan berperilaku.

Masalah dengan kode Anda adalah bahwa Anda belum mendokumentasikan bagaimana objek bertipe Taskdiharapkan berperilaku. Anda memiliki kode tertulis, tetapi tidak memiliki kontrak. Saya akan menambahkan kontrak untuk Task.Close. Bergantung pada kontrak yang saya tambahkan, kode untuk ProjectTask.Closemengikuti atau tidak mengikuti LSP.

Diberikan kontrak berikut untuk Task.Close, kode untuk ProjectTask.Close tidak mengikuti LSP:

     // Behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Diberikan kontrak berikut untuk Task.Close, kode untuk ProjectTask.Close tidak mengikuti LSP:

     // Behaviour: Moves the task to the closed status if possible.
     // If this is not possible, this method throws an Exception
     // and leaves the status unchanged.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Metode yang mungkin diganti harus didokumentasikan dalam dua cara:

• "Perilaku" mendokumentasikan apa yang bisa diandalkan oleh klien yang tahu objek penerima adalah Task, tetapi tidak tahu kelas apa itu contoh langsungnya. Ini juga memberi tahu desainer subclass mana yang menimpa wajar dan mana yang tidak masuk akal.

• "Perilaku default" mendokumentasikan apa yang bisa diandalkan oleh klien yang tahu bahwa objek penerima adalah contoh langsung dari Task(yaitu apa yang Anda dapatkan jika Anda gunakan new Task(). Ini juga memberi tahu perancang subkelas perilaku apa yang akan diwarisi jika mereka tidak mewarisi timpa metode ini.

Sekarang hubungan-hubungan berikut harus berlaku:

• Jika S adalah subtipe dari T, perilaku yang didokumentasikan dari S harus memperbaiki perilaku yang didokumentasikan dari T.
• Jika S adalah subtipe dari (atau sama dengan) T, perilaku kode S harus memperbaiki perilaku terdokumentasi dari T.
• Jika S adalah subtipe dari (atau sama dengan) T, perilaku default S harus memperbaiki perilaku T.
• Perilaku aktual kode untuk kelas harus memperbaiki perilaku default yang didokumentasikan.

Ini bukan pelanggaran Prinsip Pergantian Liskov.

Prinsip Pergantian Liskov mengatakan:

Biarkan q (x) menjadi properti dapat dibuktikan tentang obyek x tipe T . Biarkan S menjadi subtipe dari T . Tipe S melanggar Prinsip Pergantian Liskov jika objek y dari tipe S ada, sehingga q (y) tidak dapat dibuktikan.

Alasannya, mengapa penerapan subtipe Anda bukan merupakan pelanggaran terhadap Prinsip Pergantian Liskov, cukup sederhana: tidak ada yang dapat dibuktikan tentang apa yang Task::Close()sebenarnya dilakukannya. Tentu, ProjectTask::Close()melempar pengecualian ketika Status == Status.Started, tapi begitu mungkin Status = Status.Closeddi Task::Close().

Ya, itu pelanggaran.

Saya sarankan Anda memiliki hierarki Anda mundur. Jika tidak semua dekat Task, maka close()tidak termasuk dalam Task. Mungkin Anda menginginkan sebuah antarmuka, CloseableTaskyang tidak ProjectTasksdapat diimplementasikan oleh semua.

Selain menjadi masalah LSP, sepertinya menggunakan pengecualian untuk mengontrol aliran program (saya harus berasumsi bahwa Anda menangkap pengecualian sepele ini di suatu tempat dan melakukan beberapa aliran kustom daripada membiarkannya merusak aplikasi Anda).

Sepertinya ini menjadi tempat yang baik untuk menerapkan pola Negara untuk TaskState dan membiarkan objek negara mengelola transisi yang valid.

Saya kehilangan di sini hal penting yang terkait dengan LSP dan Desain oleh Kontrak - dalam prasyarat, adalah penelepon yang bertanggung jawab untuk memastikan prasyarat terpenuhi. Kode yang dipanggil, dalam teori DbC, seharusnya tidak memverifikasi prasyarat. Kontrak harus menentukan kapan tugas dapat ditutup (mis. CanClose mengembalikan Benar) dan kemudian kode panggilan harus memastikan prasyarat terpenuhi, sebelum memanggil Tutup ().

Ya, ini jelas merupakan pelanggaran terhadap LSP.

Beberapa orang berpendapat di sini bahwa membuat eksplisit di kelas dasar bahwa subclass dapat membuang pengecualian akan membuat ini dapat diterima, tetapi saya tidak berpikir itu benar. Tidak peduli apa yang Anda dokumentasikan di kelas dasar atau pada level abstraksi apa Anda memindahkan kode, prasyarat masih akan diperkuat dalam subkelas, karena Anda menambahkan bagian "Tidak dapat menutup tugas proyek yang dimulai" ke dalamnya. Ini bukan sesuatu yang bisa Anda selesaikan dengan solusi, Anda memerlukan model yang berbeda, yang tidak melanggar LSP (atau kita perlu melonggarkan kendala "prasyarat tidak dapat diperkuat").

Anda dapat mencoba pola dekorator jika Anda ingin menghindari pelanggaran LSP dalam kasus ini. Mungkin berhasil, saya tidak tahu.