İlgili yazılar

# 9

AhmetA / 18 Haziran 2013   

Single Responsibility , yanlış anlamış ve yanlış anlatmışsın. O maddede anlattığın sınıf üretimi , gevşek bağlı(losely couple) sistem geliştirmek için yapılır.

AhmetA / 19 Haziran 2013   

Bence bu makaleyi toptan sil, IOC’ü de yanlış anlatmışsın. IOC yazılımın akışının üst katmana devredilmesi demektir yani yazılımın akışını artık çağrılan değil çağıran belirleyecektir. Bunu da nasıl yapar, fonksiyonlara arayüzler yollanır , o arayüzü gerçekleştiren hangi sınıf yollanmışsa o sınıfın akışı uygulanır. Bu da akış kontrolünün bir üst sınıfa geçmesidir.

AhmetA / 19 Haziran 2013   

(L)Iskov’s Substitution Prensibini açıklarken de hata yapmışsın. Bu ilkede , türetilen sınıfları çağıran fonksiyon farklı alt sınıflar kullansa bile bunu ayırt edememesi istenir. Sen alt ve üst sınıf arasında uyumluluk olması gerektiğinden bahsetmişsin ki bu yanlış bir açıklama olur.

Onur Gazioğlu / 21 Haziran 2013   

AhmetA / 19 Haziran 2013

Bence bu makaleyi toptan sil, IOC’ü de yanlış anlatmışsın. IOC yazılımın akışının üst katmana devredilmesi demektir yani yazılımın akışını artık çağrılan değil çağıran belirleyecektir. Bunu da nasıl yapar, fonksiyonlara arayüzler yollanır , o arayüzü gerçekleştiren hangi sınıf yollanmışsa o sınıfın akışı uygulanır. Bu da akış kontrolünün bir üst sınıfa geçmesidir.

Bu yazıda IoC’un esamesi geçmiyor zaten. Dolayısıyla IOC ile ilgili birşey anlatılmıyor. DI ile IoC farklı kavramlar.

Onur Gazioğlu / 21 Haziran 2013   

AhmetA / 19 Haziran 2013
(L)Iskov’s Substitution Prensibini açıklarken de hata yapmışsın. Bu ilkede , türetilen sınıfları çağıran fonksiyon farklı alt sınıflar kullansa bile bunu ayırt edememesi istenir. Sen alt ve üst sınıf arasında uyumluluk olması gerektiğinden bahsetmişsin ki bu yanlış bir açıklama olur.

Burada da bir hata yok, kendin de söylüyorsun. Birbirini ayırd edemeyen şey zaten birbiriyle uyumludur. Gereksiz karalama kampanyalarının bir lüzumu yok. Lütfen öncelikle iyice öğrenelim.

Onur Gazioğlu / 21 Haziran 2013   

AhmetA / 18 Haziran 2013
Single Responsibility , yanlış anlamış ve yanlış anlatmışsın. O maddede anlattığın sınıf üretimi , gevşek bağlı(losely couple) sistem geliştirmek için yapılır.

Hayır, Single Responsibility (Tekil Sorumluluk) adı üstüne her sınıfın sadece bir tek işten sorumlu olması gerektiğini söyler. Bir sınıfta 50 tane farklı iş yapan metot kullanmak yerine ayrı ayrı işler yapan her metodu ayrı sınıflarda tut der. Veya bir metod birden çok karmaşık iş yapıyorsa, buradaki işleri de ayrı iş sınıflarına yaptırmak için böl ve ayır der (Bunu yapmak için DI kullanabilirsin). Aksi takdirde bütün lojik birbirine dolanır der.

Ama sen DI ile bunu nasıl bağlayabildin anlaşılabilir gibi değil. Yaptığın 3 yorumda tamamen yanlış ve art niyetli. Ancak hem senin öğrenmen hem de bunu okuyup belki yorum yazmasa da aynı yanlış fikirlere sahip okuyucuların da bilgilenmesi için tüm yorumlarını onaylayıp gereken cevapları verdim.

Ertuğrul / 15 Temmuz 2013   

Liskov Substitution ilkesi abstract class yapısı olması daha sağlıklıdır.

örnek:

public abstract class Meyve
{
public abstract string Renk();
}

public class Elma: Meyve{
public override Renk { return “Kırmızı”; }
}

public class Portakal: Meyve{
public override Renk { return “Turuncu”; }
}

class Program
{
static void Main(string[] args)
{
Meyve meyve = new Portakal();
Console.WriteLine(meyve.Renk());
meyve = new Elma();
Console.WriteLine(meyve.Renk());
}
}

Saygılar

Onur Gazioğlu / 15 Temmuz 2013   

Ertuğrul Bey,

Bu ilke sınıfları türetirken ezdiğimiz metotların çalışma mantığını korumamız gerektiğini anlatır. Burada sınıfın abstract olup olmaması önemli değildir. Ayrıca abstract bir metot varsa içinde herhangi bir implementasyon olmamasından dolayı burada göz önüne alacağımız bir durum (iş mantığı) zaten yoktur. Ama metodumuz virtual bir metot ise bunun içindeki implementasyonu göz önünde bulundurmamız gerekir. Sizin dediğiniz gibi sınıfı veya metodu abstract olarak tanıtmamız ise bu ilkeyi sadece türeyen sınıflar için es geçmemize neden olur ancak örneğinizdeki Meyve sınıfını inherit eden Elma sınıfını da bir gün ElmaAmasya, ElmaGrannySmith gibi ayrı sınıflar da inherit ederse bu ilkeyi tekrar göz önünde bulundurmalıyız. Hatta verdiğiniz örnek bu ilkeye burada uymayacaktır. Çünkü Elma için kesinlikle Kırmızıdır demişsiniz. Oysaki ElmaGrannySmith yeşil renklidir. Aşağıdaki gibi kullanımda farklı tiplerde farklı sonuçlar ürettiğinden Liskov Substitution ilkesine uymadığını görebiliriz:


class Program
{
static void Main(string[] args)
{
Elma meyve = new Elma();
Console.WriteLine(meyve.Renk());

Elma elma = getElma();
Console.WriteLine(elma.Renk());

Console.ReadLine();
}

private static Elma getElma()
{
return new ElmaGrannySmith();
}
}

public abstract class Meyve
{
public abstract string Renk();
}
public class Elma : Meyve
{
public override string Renk() { return "Kırmızı"; }
}
public class ElmaGrannySmith : Elma
{
public override string Renk() { return "Yeşil"; }
}

Bu örneğin çıktısı ve Kırmızı ve Yeşil olacaktır. Her iki nesne de Elma tipinde görünmesine rağmen birisi GrannySmith olarak instantiate edilmiş. Ama developer bu instantiate işlemini kodunu görmediği bir API üzerinden veya bir konteynerden çağırıyorsa dönen nesnenin Elma özellikleri göstereceğine güveniyor ve renginin Kırmızı olacağını düşünüyor. Oysaki instantiator rengi yeşil olan ElmaGrannySmith nesnesi örneklemiştir.

İşte bu ilke bu şekilde tasarım yapmamak gerektiğini söylüyor.

Muhammed Akabş / 28 Nisan 2015   

Emeğe saygı, bir insan hata yapabilir ama direk sen hatalısın denmez, yapıcı metotlar kullanmak lazım :) . bende bir yanlışlık görmedim. olsa bile kul yanlış yaparak doğruyu bulur adı üstünde prensipler anadan doğma olmadı tecrübeyle çıktı bunlar belki iki sene sonra bunlarda çöp olacak..

Club Crema Logo
Club Crema, Crema çalışanlarının, bilgi birikimlerini sektörle paylaştıkları, şirketiçi ve dışı aktivitelerin de duyurulduğu kurumsal bir blogdur.