YZM 2108 Yazılım Mimarisi ve Tasarımı

Transkript

1 YZM 2108 Yazılım Mimarisi ve Tasarımı Yrd. Doç. Dr. Deniz KILINÇ Celal Bayar Üniversitesi Hasan Ferdi Turgutlu Teknoloji Fakültesi Yazılım Mühendisliği 1

2 BÖLÜM - 3 Tasarım Prensipleri Bu bölümde; Tasarım Prensipleri ile ilgili konular anlatılacaktır. 2

3 Tasarım Prensipleri 1. Ayrıştırma (Decomposition) 2. Kohezyon (Cohesion) 3. Tek Sorumluluk Prensibi (Single Responsibility) 4. Zayıf Bağlaşım Prensibi (Low Coupling) 5. Yeniden Kullanılabilirlik prensibi (Reusability) 6. Açık Kapalı Prensibi (OCP) 7. Liskov Yerine Geçme Prensibi (LSP) 8. Bağımlılığı Ters Çevirme Prensibi (DIP) 3

4 5. Yeniden Kullanılabilirlik (Reusability) Yeniden kullanılabilirlik nesne yönelimli programlamanın en önemli özelliklerinden biridir ve çoğu zaman, yanlış bir yaklaşımla sadece kalıtımdan ibaret olduğu sanılır. Oysa kalıtım yeniden kullanılabilirliği sağlama noktasında her zaman yeterli olmaz. Salt kalıtım yerine, kalıtım ile birlikte nesneler arasında kompozisyon kurgulanmalıdır. 4

5 5. Yeniden Kullanılabilirlik (Reusability) (devam...) Yandaki gibi bir raporlama sınıfı yazıldığında, Rapor sınıfına gereğinden fazla sorumluluk yüklenmiştir. Bu sınıftan türetilen sınıflar yeniden kullanıma doğru bir örnek teşkil etmemektedirler. Doğru olan yaklaşım Rapor sınıfının içinde bu işlemleri kodlamak yerine, veri tabanı ve yazıcı işlemlerinin ayrı sınıflarda yapılması ve bu sınıflarla bir composition sağlanmasıdır. 5

6 5. Yeniden Kullanılabilirlik (Reusability) (devam...) Doğru Tasarımı: 6

7 Black Box ve White Box Kavramları GoF doktrin de yeniden kullanılabilirlik bu kavramlarla ikiye ayrılmıştır: White Box sınıf türetmesine dayalıdır ve salt türetme bazı tasarımsal sakıncalar doğurabilmektedir. Black Box ise nesne kompozisyonuna dayalıdır. Yani önceki örnekte ele alınan Rapor sınıfı gibi sarmalayıcı bir sınıf, VeriTabanilslemleri ve YaziciIslemleri sınıflarına ait nesneleri kullanarak, yani composition yaparak, "black box reusability" sağlamaktadır. 7

8 6. Açık/Kapalı Prensibi (OCP) Değişim gerektirmeyen yazılımın ömrü bitmiştir. Yazılımlar, kullanıcı beklentileri değiştikçe değişime uğramaktadır. Bu noktada yapılması gereken şey yazılım sisteminin herhangi bir yerindeki değişimin başka yerlerde de zincirleme değişim gerektirmeyecek şekilde tasarlanmasıdır. Böylece ufak bir değişimde oluşabilecek kargaşa engellenmiş olur. Değişim kargaşasını önlemek için esnemez tasarımlardan uzak durulmalıdır. 8

9 6. Açık/Kapalı Prensibi (OCP) (devam...) Sistemler gelişime açık, ancak değişime kapalı olmalıdır. Bertnard Meyer Bu prensibe göre, sistemlerdeki değişimleri kodları değiştirerek gerçekleştirmek yerine yeni kod blokları eklenerek yapılması öngörülmektedir. 9

10 6. Açık/Kapalı Prensibi (OCP) (devam...) Yandaki UML ile gösterilen Dortgen ve Cember sınıfları Sekil sınıfından türetilmiştir. Bu sınıflar Ciz sınıfı ile composition yapmaktadır. Ciz sınıfı verilen parametreye bağlı olarak şekli çizecek fonksiyonu çalıştıracaktır. Böyle bir tasarım esnemezdir ve dolayısıyla kırılgandır. Sekil sınıfından yeni bir şekil sınıfı türetildiğinde Ciz sınıfında da değişmesi gerekecektir. 10

11 6. Açık/Kapalı Prensibi (OCP) (devam...) Sekil.java Dortgen.java Cember.java Celal Bayar Üniversitesi 11

12 6. Açık/Kapalı Prensibi (OCP) (devam...) Ciz.java Celal Bayar Üniversitesi 12

13 6. Açık/Kapalı Prensibi (OCP) (devam...) Doğru tasarım Sekil sınıfının soyut sınıf ya da ara yüz şeklinde tanımlanarak yapılabilir. Bu sınıftan türetilen sınıflar da kendi ihtiyaçlarına göre implemente edilmelidir. 13

14 6. Açık/Kapalı Prensibi (OCP) (devam...) Sekil.java Dortgen.java Cember.java Celal Bayar Üniversitesi 14

15 6. Açık/Kapalı Prensibi (OCP) (devam...) Ciz.java Celal Bayar Üniversitesi 15

16 7. Liskov Yerine Geçme Prensibi (LSP) Barbara Liskov tarafından formüle edilen ve Açık-Kapalı prensibi ile yakından ilgili olan bu prensip, türemiş sınıf nesnelerinin taban sınıf nesnesi yerine geçmesini öngörür. Daha açık bir ifadeyle, taban sınıf türündeki nesne üzerinde operasyon yapacak şekilde geliştirilmiş bir fonksiyon, bu sınıftan türeyen farklı sınıflara ait nesneler üzerinde de aynı operasyonu yapabilmelidir. 16

17 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Bu prensip türemiş sınıf türündeki nesnelerin taban sınıfa ait nesnelere atanması halinde gerçekleşen otomatik tür dönüşümünden (upcast) faydalanır. 17

18 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: Veritabanından bağımsız bir veri katmanı yazılmak istenmiştir. Bu yapı yeni veri tabanları için yeni sınıf eklenebilirliği gerekmemesiyle hem Açık-Kapalı prensibine, hem de DBHelper türünden aldığı parametreden dolay Liskov prensibiyle uygundur. 18

19 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: DBHelper tasarımı 19

20 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: DBHelper.java 20

21 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: SQLHelper.java 21

22 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: OracleHelper.java 22

23 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: Program.java 23

24 7. Liskov Yerine Geçme Prensibi (LSP) (devam...) Örnek: Program çıktısı 24

25 8. Bağımlılığı Ters Çevirme Prensibi (DIP) Bağımlılığı Ters Çevirme prensibi (Dependency Inversion Principle) yüksek seviyeli sınıfların, aşağı seviyeli sınıflarla doğrudan bir bağımlılığının olmamasını öngörmektedir. Bağımlılığın artmaması için yüksek seviyeli sınıflar ile düşük seviyeli sınıfların arasına bir ara yüz ya da soyut sınıf sokulması gerekmektedir. 25

26 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Düşük seviyeli sınıflar, uygulamadaki temel işlevleri yerine getirirler. Örn.: Stok takip uygulamasında kota bilgilerini alan Finder sınıfı ya da sayfada bu bilgileri göstermeye yarayan Renderer sınıfı gibi sınıflardır. Öte yandan bu sınıfları kullanarak çalışan Stock sınıfı ise yüksek seviyeli bir sınıftır. Yüksek seviyeli sınıflar aşağı seviyeli sınıfları anlamlı kılarlar. 26

27 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının KÖTÜ tasarımı: 27

28 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının KÖTÜ tasarımı: Finder.java 28

29 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının KÖTÜ tasarımı: Renderer.java 29

30 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının KÖTÜ tasarımı: Stock.java 30

31 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının KÖTÜ tasarımı: 31

32 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: 32

33 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: 33

34 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: IFinder.java 34

35 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: 35

36 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: wsfinder.java 36

37 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: DBFinder.java 37

38 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: 38

39 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: IRenderer.java 39

40 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: 40

41 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: WebRender.java 41

42 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: ConsoleRender.java 42

43 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: 43

44 Bağımlılığı Ters Çevirme Prensibi (DIP) (devam...) Stock sınıfının İYİ tasarımı: Stock.java 44

45 Yararlanılan Kaynaklar Aykut Taşdelen, C++, Java ve C# ile UML ve Dizayn Paternleri, Pusula Yayıncılık, İstanbul, 2014 Eric Freeman, Head First Design Patterns, O'Reilly Media,2004 Stephen Stelting & Olav Maassen, Applied Java Patterns, Prentice Hall PTR,

46 İYİ ÇALIŞMALAR Yrd. Doç. Dr. Deniz KILINÇ 46