Bu Liskov Değişim İlkesinin ihlali midir?

Diyelim ki bir Görev varlıkları listesi ve bir ProjectTaskalt tür var. Görevler, ProjectTasksBaşlama statüsüne sahip olduklarında kapatılamaz olmaları haricinde, herhangi bir zamanda kapatılabilir. Kullanıcı Arabirimi, bir başlatmayı kapatma seçeneğinin ProjectTaskhiçbir zaman kullanılabilir olmadığından emin olmalıdır , ancak alanda bazı güvenlik önlemleri vardır:

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();
     }
}

Şimdi Close()bir Görevi çağırırken , başlangıç ProjectTaskdurumuna sahipse, bir temel Görev olmasaydı aramanın başarısız olması ihtimali var . Ancak bu iş gereksinimleridir. Başarısız olmalı. Bu Liskov ikame ilkesinin ihlali olarak kabul edilebilir mi?

Evet, bu LSP'nin ihlalidir. Liskov değiştirme İlke gerektirir olduğu

• Bir alt türde ön koşullar güçlendirilemez.
• Son koşullar bir alt tipte zayıflayamaz.
• Üst tipin değişmezleri bir alt tipte korunmalıdır.
• Tarih kısıtlaması ("tarih kuralı"). Nesnelerin sadece yöntemleri ile değiştirilebildiği kabul edilir (kapsülleme). Alt tipler, üst tipte bulunmayan yöntemleri ortaya koyabildiğinden, bu yöntemlerin eklenmesi, alt tipte üst tipte izin verilmeyen durum değişikliklerine izin verebilir. Tarih kısıtlaması bunu yasaklar.

Örneğiniz, Close()yöntemi çağırmak için bir ön koşulu güçlendirerek ilk gereksinimi ihlal eder .

Güçlendirilmiş ön koşulu miras hiyerarşisinin en üst seviyesine getirerek düzeltebilirsiniz:

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

Bir çağrının Close()yalnızca CanClose()iadeler truedurumunda geçerli olacağını öngörerek, ön koşulu LSP ihlalini düzelterek için Taskde geçerli kılacağınızı belirtin ProjectTask:

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();
    }
}

Evet. Bu, LSP'yi ihlal ediyor.

Önerim, CanClosetemel göreve yöntem / özellik eklemektir , böylece herhangi bir görev bu durumdaki görevin kapatılıp kapatılamayacağını söyleyebilir. Ayrıca nedenini de sağlayabilir. Ve sanal olanı kaldırın Close.

Yorumuma göre:

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);
    }
}

Liskov ikame prensibi, bir temel sınıfın, programın istenen özelliklerinden herhangi birini değiştirmeden, alt sınıflarından herhangi biri ile değiştirilebilir olması gerektiğini belirtir. Sadece ProjectTaskkapalı olduğunda bir istisna yarattığından, ProjectTaskbunun yerine bir programın değiştirilmesi gerekecekti , yerine kullanılmalı Task. Bu yüzden bir ihlaldir.

Eğer değiştirirseniz Ama Taskonun imzası belirten edebilir kapatıldığında bir istisna, o zaman ilkesini ihlal olmaz.

Bir LSP ihlali üç taraf gerektirir. T Tipi, Alt Tipi S ve T'yi kullanan P programı ancak S örneği verilmiştir.

Sorunuz T (Görev) ve S (ProjectTask) sağladı, ancak P sağladı. Yani sorunuz tamamlanmadı ve cevap nitelikli: Eğer bir istisna beklemeyen bir P varsa, o zaman P için bir LSP'niz var. ihlal. Her P bir istisna beklerse, LSP ihlali olmaz.

Ancak, bunu bir var SRP ihlali. Bir görev durumunun değiştirilebilmesi ve belirli eyaletlerdeki belirli görevlerin başka devletlere değiştirilmemesi gerektiği politikası , iki farklı sorumluluğa sahiptir.

• Sorumluluk 1: Bir görevi temsil eder.
• Sorumluluk 2: Görevlerin durumunu değiştiren politikaları uygulayın.

Bu iki sorumluluk farklı nedenlerden dolayı değişir ve bu nedenle ayrı sınıflarda olması gerekir. Görevler, bir görev olma gerçeğini ve bir görevle ilişkili verileri ele almalıdır. TaskStatePolicy, verilen bir uygulamada görevlerin durumdan duruma geçiş yolunu kullanmalıdır.

Bu , LSP'nin ihlali olabilir veya olmayabilir .

Ciddi anlamda. Bana kulak ver.

LSP'yi izlerseniz, tür ProjectTasknesnelerinin Taskdavranması beklendiği için tür nesnelerinin davranması gerekir .

Kodunuzla ilgili sorun, türdeki nesnelerin nasıl Taskdavranması beklendiğini belgelememenizdir . Kod yazdınız, ancak sözleşmeniz yok. İçin bir sözleşme ekleyeceğim Task.Close. Eklemiş olduğum sözleşmeye bağlı olarak, kodun ProjectTask.Closeya LSP'yi izlemesi ya da izlememesi.

Task.Close için aşağıdaki sözleşme göz önüne alındığında, için kod LSP takip ProjectTask.Close etmez :

     // 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;
     }

Task.Close için kodu için aşağıdaki sözleşme Verilen ProjectTask.Close gelmez LSP'yi izleyin:

     // 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;
     }

Geçersiz kılınabilecek yöntemler iki şekilde belgelenmelidir:

• "Davranış", alıcı nesnesinin bir olduğunu bilen Task, ancak hangi sınıfın doğrudan olduğunu bilmeyen bir müşterinin neye güvenebileceğini belgelemektedir . Ayrıca, geçersiz kılan ve makul olmayan alt sınıf tasarımcılarına da söyler.

• "Varsayılan davranış", alıcı nesnenin doğrudan bir örneği olduğunu bilen bir müşteri tarafından neye güvenebileceğini belgelemektedir Task(yani, eğer kullanırsanız ne elde edersiniz new Task(). Ayrıca, alt sınıf tasarımcılarına, eğer yapmazlarsa hangi davranışların kalıtsal olacağını da söyler. yöntemi geçersiz kıl.

Şimdi aşağıdaki ilişkiler geçerli olmalı:

• S, T'nin bir alt türü ise, S'nin belgelenmiş davranışı, T'nin belgelenmiş davranışını düzeltmelidir.
• S, T'nin bir alt türü (veya eşittir) ise, S'nin kodunun davranışı, T'nin belgelenmiş davranışını düzeltmelidir.
• S, T'nin bir alt türü (veya eşittir) ise, S'nin varsayılan davranışı, T'nin belgelenmiş davranışını düzeltmelidir.
• Bir sınıfın kodunun gerçek davranışı, belgelenen varsayılan davranışını iyileştirmelidir.

Liskov Değişim İlkesinin ihlali değildir.

Liskov Değişim Prensibi şöyle diyor:

Let q (X) nesneler hakkında kanıtlanabilir bir özellik olabilir x tipi T . S , T'nin bir alt türü olsun . Tip G bir amacı ise Liskov değiştirme prensibi ihlal y tipi S bulunacak şekilde, q, (y) kanıtlanabilir değildir.

Alt tipi uygulamanızın Liskov Yerine Getirme İlkesini ihlal etmemesinin sebebi oldukça basittir: Task::Close()gerçekte ne yaptığı konusunda hiçbir şey kanıtlanamaz . Tabii, ProjectTask::Close()ne zaman bir istisna atar Status == Status.Started, ama çok olabilir Status = Status.Closedde Task::Close().

Evet, bir ihlaldir.

Hiyerarşinizi geri almanızı öneriyorum. Her biri kapalı değilse Task, o close()zamanTask . Belki de CloseableTasktüm olmayanların ProjectTasksuygulayabileceği bir arayüz istiyorsunuz .

Bir LSP sorununa ek olarak, program akışını kontrol etmek için istisnalar kullanıyor gibi görünüyor (Bu önemsiz istisnayı bir yerde yakaladığınızı ve uygulamanızın çökmesine izin vermek yerine bazı özel akışlar yaptığınızı varsaymalıyım).

TaskState için Devlet modelini uygulamak ve durum nesnelerinin geçerli geçişleri yönetmesine izin vermek için iyi bir yer gibi görünüyor.

Burada, LSP ve Sözleşmeye Göre Tasarım ile ilgili önemli bir şeyi özlüyorum - önkoşullarda, önkoşulların yerine getirildiğinden emin olmak, arayanın sorumluluğundadır. DbC teorisinde çağrılan kod ön koşulu doğrulamamalıdır. Sözleşme, bir görevin ne zaman kapanabileceğini (örneğin CanClose, True döndürür) belirtmeli ve daha sonra arama kodu, ön koşulun Kapat () çağrılmadan önce yerine getirilmesini sağlamalıdır.

Evet, bu açıkça bir LSP ihlalidir.

Bazı insanlar burada temel sınıfta alt sınıfların istisnalar ortaya koyabileceğini açıkça belirtmenin bunu kabul edilebilir kılacağını savunuyorlar, ancak bunun doğru olduğunu sanmıyorum. Temel sınıfta ne belgelemiş olursanız olun veya kodu hangi soyutlama seviyesine götürürseniz götürün, önkoşullar alt sınıfta da güçlenecektir, çünkü ona "Başlatılan Proje Görevi kapatılamıyor" bölümünü eklediniz. Bu, geçici bir çözümle çözebileceğiniz bir şey değildir, LSP'yi ihlal etmeyen farklı bir modele ihtiyacınız vardır (veya "önkoşullar güçlendirilmez" kısıtlamasını gevşetmemiz gerekir).

Bu durumda, LSP ihlalini önlemek istiyorsanız, dekoratör desenini deneyebilirsiniz. İşe yarayabilir, bilmiyorum.