şükela:  tümü | bugün
  • oop'de kullanilan bir prensip. bir temel sinifa referans ya da pointeri kullanan fonksiyon, bu temel siniftan turetilen bir baska sinifi da sorunsuz olarak onun yerine kullanabilmelidir. bunun olabilmesi icin:

    -temel sinif destructorunu virtual tanimlamalidir.
    -turetilen sinif, temel sinifin virtual bir member functionunu tekrar tanimlamamalidir.
    -virtual functionlar overload edilmemeli, ya da default parametre verilmemelidir.

    (bkz: liskov substitution principle)
  • bahçeşehir üniversitesi yazılım mühendisliğinden bir hocamızın, sunumunda bunla ilgili bir slayt olmasına rağmen sorduğumda bilemediği, wtf ifadesiyle beni süzdüğü prensip. üzüldüm biraz. sonra soda içtim geçti.
  • http://en.wikipedia.org/wiki/barbara_liskov adresinden kendisini görebileceğiniz ablanın prensipleridir. kadın işte, herşey düzenli, bir kurala uygun.
  • bob amca bu pirensibi şöyle özetler: "temel tiplerden türetilen alt tipler değiştirebilir olmalıdır." yani bir alt sınıf bir şekilde üst sınıfın yöntemlerini geçersiz kıldığında işlevselliğinin bozulmaması gerektiğini söyler. aynı zamanda bu pirensip açık kapalı prensibinin bir gerekliliğidir.
  • c# dilinde eğer türetilmiş sınıfın herhangi bir metodu için throw new notimplementedexception ifadesi mevcutsa, bu kural ihlal edilmiştir.
  • ana sınıfın sistem davranışını değiştirmeden kendi alt sınıfı ile değiştirilebillir olması prensibi. örneğin ördek adında bir ana sınfımız olsun ve bu sınıfımız içerisinde hayvani tepkiler verdiği metotlar(yüzmek, beslenmek) olduğunu farzedelim.

    buraya kadar her şey normal fakat bu ördek sınıfından oyuncak ördek türettiğimiz zaman bu prensibi çiğneyebiliyoruz. nedeni ise oyuncak ördek sınıfımızın ana sınıfımızın tepkilerini veremeyecek olmasından kaynaklanıyor (üst sınıfımızın nesneleri ile çalışılabilir bir şekilde yer değiştiremez). böylece unimplement exception hatası alırız .
  • iş akışınızdaki objeleri alt tipleriyle değiştirdiğinizde iş akışınızın bozulmaması gerektiğini belirten prensiptir. bu durum aynı zamanda objeleri iş akışınızda nasıl kullandığınızla ilgilidir. örnek vermek gerekirse, kare teknik olarak kenarları ve açıları birbirine eşit olan bir dikdörtgendir ancak karenin bir kenarının uzunluğu değiştiğinde, şeklinin bozulmaması için karenin tüm kenarlarının uzunluğu değişmek zorundadır. dikdörtgenin bir kenarının uzunluğunu değiştiğinde sadece ona paralel olan kenarın uzunluğu değişir eğer iş akışınızda kenar uzunluklarıyla ilgili bir hesaplama yada kontrol varsa kare ile dikdörtgen farklı davranışlar sergilediğinden birbirlerinin yerine geçemezler.
  • programlamada yazililm kod kalitesini arttirmayi amaclayan "solid" prensiplerinin "l" harfine denk gelen "liskov substitution principle" yani bir temel sinif bir method tarafindan kullaniliyo ise o temel sinifin alt siniflari da kullanilabilmelidir. bu cok soyut bir anlatim, bunu bir ornek (java) ile anatir isek su sekilde ifade edebiliriz. ornegin bir "kus" sinifimiz olsun. dolayisi ile kuslar ucabilir, o nedenle "uc" diye methodumuz olsun.

    class kus{
    public void uc(){
    //ucma islemini yap
    };
    }

    simdi "serce" sinifi uretelim, serce bir kustur (ıs-a) o nedenle kus sinifini "extend" eder.
    class serce extends kus{}

    simdi de "devekusu" sinfi uretelim, devekusu bir kustur (ıs-a), o nedenle kus sinifini extend eder, ama bir sartla devekusu ucamaz. bu nedenle "uc" methodunu "override" edip, hicbirsey yapmayan bir method haline getirmek durumundayiz.
    class devekusu extends kus{
    public void uc(){
    //hicbirsey yapma
    };
    }

    bu durum liskov değiştirme prensibinin ihlalidir. cunku ilerde gelen kuslari ucurma gorevine sahip bir method tum kuslara "uc" emrini verebilir, cunku tum kuslarin ucma methodu var. ama bazi kuslarin ucma emri karsisinda hicbir sey yapmadigini gorecektir. bu sistemde hatalara neden olacaktir. bu nedenle kuslara uc emrini veren method sadece ucabilen kuslar ile calismalidir, sadece ucabilen kuslari kabul etmelidir. biz bu methoda sadece ucabilen kuslari once tiplerine gore kontrol edip gonderebiliriz ama bu durumda da "solid" prensiplerinin "o" harfine denk gelen "open/closed principle" prensibini ihlal etmis oluruz. bu mimari hatayi su sekilde cozebiliriz, onelikle "tum kuslar ucabilir" on kabulunu reddedecegiz ve "kus" sinifindan "uc" methodunu silecegiz, cunku tum kuslar ucamaz.

    class kus{//ucma ozelligi olmamali, cunku tum kuslar ucamaz}

    daha sonra ucabilen kuslar icin ozellik yaratmaliyiz. bu bir interface olabilir.

    public interface ucabilir {
    public void uc();
    }

    daha sonra da sadece ucabilen kuslaria bu ozelligi ekleyecegiz, yani serce bir kustur ve ucabilir.
    class serce extends kus implements ucabilir{
    public void uc(){
    //hicbirsey yapma
    };
    }

    ama devekusuna bu ucabilme ozelligini eklemeyecegiz, devekusu sadece bir kustur.
    class devekusu extends kus {}

    en son olarak da kuslari ucurma gorevine sahip method sadece ucabilir kuslari kabul etmeli
    void ucurucu(ucabilir u){
    u.uc();
    }

    boylece ucurucu methodu "ucurucu(new serce());" ile cagirilabilirken "ucurucu(new kus());" ve "ucurucu(new devekusu());" ile cagirilamaz, cunku sadece ucabilen kuslar "ucurucu" tarafindan kabul edilir.
  • (bkz: #94280510)

    bir classtan türetilmiş classlar birbirlerinin yerine kullanılabilir olmalıdır. ana classta belirtilen özellikler alt sınıflarda da eksiksiz yerine getirilebilmelidir.
    bilgisayar diye bir ana sınıfımız, asus ve dell diye de 2 alt sınıfımız olsun. bilgisayar ana sınıfımızı tanımlarken düşündük ve dedik ki bir bilgisayarın bir ana kartı, bir işlemcisi, bir ekran kartı, bir klavyesi, bir de kamerası olur dedik.
    her ne kadar bir bilgisayarın ana kartı, işlemcisi ekran kartı ve klavyesi oluyor olsa da kamerası olmayabilir. bu da liskov substitution principle'e aykırıdır.
hesabın var mı? giriş yap