Solid Programlama - Liskov's Substitution Principle

[@TheHackhell]

Burada precoditionları güçlendirdik, post conditionları zayıflattık. Evet "negatif side effects" oluştu. Normalde LSP için child instance ları parent instance yerine kullanabilmeliyiz. Burada çözüm olarak ne yapılmalı peki bu kod örneğinde? Nasıl bir tasarım yapılmalı sizce?

[@FatihCengel]

Sorun ve yapılan yanlışlık tamam, ama çözüm? Bu kod nasıl yazılmalıydı LS prensibi ile?

[@repiatx]

Dilinize Sağlık hocam.

[@Deniz1989dnz]

Hocam burada sorunu güzel anlatmışsınız fakat çözümü unutmuşsunuz :)

[@repiatx]

Ata class çocuk classla aynı variant,precondition ve postconditionları almak zorunda, yani çocuk class'ın conditionlarını olduğu değerlerle ata class'a kopyalıyacaksın. İyi günler dilerim.

[@ismailyou]

Teşekkürler hocam. Gayet güzel anlatmışsın.

[@ITheAvengersI]

Burada invariant ile ilgili bir şey yapmadık ya da ben mi kaçırdım .?

[@medicalturkishteam5928]

Merhaba C++ la yapilamaz mi bu niye herkes c sharp java ile ayni ornekleri yapip duruyor ki liskov sadece bu iki dilde mi gecerli ?

[@gokhancacan1202]

Merhaba, C++ veya farklı dillerde kendi yapıları ile yapılabilir. Java ve C# object oriented diller olduğu için zaten kendi bünyesinde SOLID prensiplerini sağlıyordur diye düşünüyorum.C++ dili Java veya C# kadar esneklik sağlamıyor.

[@yusuftunc338]

yanlis anlamadiysam en basit sekilde sunu anlatmak istiyor bu prensib bize. Tanimlanan kurallar farkli farkli classlarda farkli sekillerde sinirlanamaz. Ornek vermek gerekirse butun armutlar sadece armut icin uretilen kutuya gidecektir. Ben armutun kirmizi olanini koymak istersen tanimlamalarima yeni bir secici ifade eklerim. Buda Liskov prensibine uymaz. Kisaca basta hangi sekilde sinirlama yaparsam asagiya dogru ayni sekilde olmak zorunda ki hatanin nerede oldugunu bulabileyim

[@ozgunturkmen4357]

Teşekkürler hocam, birkaç sorum vardı. -şimdi preconditonlar'ın davranışlarının değişkenlik göstermesi durumunda true/false döndüren sınıfı(Örnekte Require) nasıl tasarlayabiliriz?Daha doğrusu bu sınıfı tasarlarken Open/Closed şekilde mi tasarlanmalıdır? Daha komplike düşünürsek bir preconditons başka bir preconditons'un postconditonsu olduğu durumlarda nasıl tasarlanmalıdır?

[@TarikGuney]

Merhabalar. Öncelikle şunu söylemekte yarar var, OpenClosed Principle ilk olarak bir hedef ama her yerde kullanılması yardımcı olmayabilir. Require meselesine gelince, diğer sınıflardan farklı olarak bunun backward compatibility sorunu hemen hemen hiç olmayacaktır. Nedeni ise pre-conditionlar methodlar içinde tanımlandığı ve Require ile true yada false oldukları check edilmesinden dolayı Require sınıfının tek sahip olduğu logic true ve false check edilmesidir. Ama neyin check edildiği hakkında bir bilgisi yoktur. Buda onu OpenClosed gibi prensiplerin çözdükleri sorunlara immune edecek kadar generic kılmaktadır. Require sınıfı basit bir static sınıf olarak tasarlanabilir ve içerisine kalıtım yada başka yöntemler kullanmadan zamanla gereksinim halinde yeni static methodlar eklenebilir. Yada istenirse .NET ile gelen Contract sınıfıda kullanılabilir. msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx Bu sınıfın özelliği VS gibi araçlar ile özel bir integrasyonu olması ve bu sayede daha erken zamanlı warningler sunması. "...preconditons başka bir preconditons'un postconditonsu olduğu durumlarda nasıl tasarlanmalıdır?" ile alakalı olan sorunuzu tam anlamadım. Biraz açabilirseniz cevaplamaya çalışabilirim.

[@ozgunturkmen4357]

Anladım hocam. Require sınıfının neyin check edildiğini bilmediğini kaçırmışım.Bir yan da işin best practisesinin sınıfın static olması gerekliliğini kavradım. Dediğiniz gibi her prensip her zaman uygulanamıyor. ...preconditons başka bir preconditons'un postconditonsu olduğu durumlarda nasıl tasarlanmalıdır? ile demeye çalıştığım ;(bu örnekte pek uygun olmadı ama) userID'nin ve zipcode'un birbirini etkilediği durumlarda bir logic mekanizması varsa süreci nasıl yönetebileceğimizi anlatmaya çalışmıştım. Yanıtınız için çok teşekkür ederim.

[@TarikGuney]

Özgün Türkmen Dediğiniz gibi bir mekanizmayı kurmak kod ile farklı bir tasarım yapmaktan daha ziyade domain bilgisiyle daha çok alakadar. Hatta ayrı bir cod ile ayrı bir tasarım yapmak fazla coupling olmasına sebep vereceğinden zararlı bile olabilir. Kısacası bunu basit true false checkleri yapmak yeterli olacaktır.

[@ozgunturkmen4357]

İlginiz için tekrardan teşekkür ederim. Yazılım ile ilgili en genel kavram sanırım yeterlilik. Bazı süreçler sadece pratikle anlaşılabiliyor.

[@TarikGuney]

Bence genelde yazılımcıların en temel handikaplarından bir tanesi domain bilgisine çok bakmamaları. Yani çözmek istedikleri problemin kod yazmadan önce ki süreçteki çözümünün ne kadar anlaşıldığı yazılacak kodun kalitesi ile doğrudan alakalı. Aksi halde en temel prensip olan kodun bir iş değeri üretmesi ve bunu doğru bir şekilde gereksiz komplekslikten arındırılmış şekilde yapılması ihlal edilmiş oluyor. SOLID prensipler domain tarafında ki çözüm bulunduktan sonra devreye giriyor. Dolayısıyla iyi yazılımcılar aynı zamanda çalıştıkları şirketlerde iş akışını ve domain bilgisi iyi bilen ve bunu anlaşılır bir şekilde kod olarak çözüme döken insanlardır. Mühendisleri programcılardan ayıran kısımda budur ve şirketlerin uzun vadede çalışmak isteyecekleri insanları bu grup teşkil eder. Kısacası iyi bir yazılım sadece bakımı kolay olan bir yazılım değildir, aynı zamanda doğru problemlere doğru çözümler üreten ve bunu yaparkende realiteli göz ölünde bulunduran bir yazılım ve iyi bir yazılımcıda bunu başaran insandır.