şükela:  tümü | bugün
  • (ing. single responsibility principle)

    "bir sinifin degi$tirilmesi icin yalnizca bir sebep olmalidir" cumlesiyle ozetlenebilecek nesne yonelimli yazilim geli$tirme prensibi. yani eger bir gun bir sinif uzerinde iki ayri i$ yapan iki ayri degi$iklik yaptiginizi farkederseniz, aslinda iki ayri sinifiniz olmasi gerektigi gercegiyle yuz yuzesiniz demektir.

    bugun cogu uygulamada kullanilan "data abstraction (veri soyutlama)" veya "3-tiered development (cok katmanli uygulama geli$tirme)" ya da kisaca uygulamamizi "data-business-presentation" katmanlarina ayirma meselesinin dayandigi nokta budur i$te.

    ayrica;

    (bkz: acik kapali prensibi)
    (bkz: ters bagimlilik prensibi)
    (bkz: arayuz ayirma prensibi)
    (bkz: liskov degistirme prensibi)
  • 1000 satırlık bir class'ınız varsa muhtemelen bu oop kuralını çiğniyorsunuzdur.

    şu linklerde ayrıntılı olarak anlatılmış:
    http://www.cihataltuntas.com/?p=111
    http://www.ceturk.com/…esponsibility-principle.html
    http://www.msegitim.net/…aleyazdir.aspx?makaleid=49
  • 1000 satırlık bir class'ınız varsa, bunu çiğneme ihtimaliniz yüksektir fakat bu çiğnediğinize dair bir kesinlik belirtmez. bir class'ın 100 adet member variable'ı olabilir, single responsibility principle, satır sayısı ile değil, sorumluluk ve metodların/fonksiyonların davranışı ile ilgilidir.

    bunun sınırı nerededir, mesela bir class, ad, soyad, doğum tarihi, tc kimlik no, ilkokul, ortaokul, lise, üniversite, açık adres, kapalı adres (bu şakaydı), ev telefonu, cep telefonu gibi bilgileri barındırabilir ve bu parametreler sayıca fazla olabilir. "bir saniye srp var, bunların hepsi aynı yerde olamaz" diyen srp'yi yanlış anlamıştır. srp nasıl bir oop paradigmasıysa, builder ve prototype pattern'lerin tanımlı oldğu design patterns de oop paradigmalarındandır. hafızada büyük yer kaplayan objeler olmasa ne builder, ne de prototype pattern'e ihtiyaç duyulurdu.

    fakat siz, bir metodun içinde 6 farklı işlevi birleştiriyorsanız, bu srp'ye aykırıdır. alakasız 9 tane class'ı tek bir class'ın altında composite yapıp, bu 9 class instance'ına dair işlemleri yani metod ve fonksiyonları altında toplayıp şişirdiğiniz class'in içine koyuyorsanız da (büyük bir işgüzarlıkla) gene srp'yi çiğniyor olursunuz çünkü birbirinden soyut olarak ayrılabilecek class'ların sorumluluklarını birleştirerek class'ı zerg hatchery gibi bug cennetine dönüştürüyorsunuzdur. ilkeler pratiklerden türediği için bu ve benzeri sıkıntılı senaryoların gerçekleşmesine mani olmak maksadıyla srp ve diğer ilkeler türemiştir.
  • (bkz: #94280510)

    bir sınıfın ya da bir metodun tek bir görevi olmalıdır. ikinci, üçüncü görevlerin dahil edilmesi bu prensibe aykırıdır.
    öğretmen, mühendis, bakkal vb. class lar yerine gidip de ınsan diye bir class yazsak, sonra da bunların yapacakları tüm işleri bu classta tanımlasak çok büyük bir karmaşa ortaya çıkacaktır. bunun yerine öğretmen, mühendis, bakkal gibi (gerektiğinde bunları da dallandırarak) classlarla çalışarak bu prensibe ayak uydurabiliriz.