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
BÖLÜM - 3 Tasarım Prensipleri Bu bölümde; Tasarım Prensipleri ile ilgili konular anlatılacaktır. 2
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
1.Ayrıştırma (Decomposition) Nesne yönelimli tasarımın ilk prensibi olan ayrıştırmanın tanımı; problem alanındaki ilgili varlıkların tespit edilip, doğru nesneler biçiminde ifade edilmesidir. Bir yöntem olarak da nitelendirilebilecek ayrıştırma, sistemdeki karmaşıklıkla (complexity) başa çıkabilmek için yapılır. Buna kısaca böl ve fethet (divide and conquer) denilmektedir. 4
1.Ayrıştırma (Decomposition) (devam...) Varlıklar Nesneler Yazılımcının çözümlemeyi gerçekleştirirken en büyük yardımcısı analiz sırasında ortaya çıkan use case tanımlarıdır. Use case tanımlarını isim ve fiilleri ortaya çıkaracak şekilde okumak olası nesnelerin tespitine yardımcı olacaktır. 5
1.Ayrıştırma (Decomposition) (devam...) NASIL? NE(LER)? Bu aşamada yazılımcı, "NASIL?" sorusu yerine "NE(LER)? sorusunun cevabına odaklanmalıdır. Böylece algoritma düşünmek yerine nesneleri düşünmeye yoğunlaşabilir. 6
1.Ayrıştırma (Decomposition) (devam...) Fonksiyonel Ayrıştırma Büyük ve karmaşık fonksiyonlar bu yöntemle daha küçük ve anlaşılabilir alt fonksiyonlara ayrılırlar. Genellikle analiz aşamasında diagram şeklinde üretilirler. İlk seviye bileşenler ve fonksiyonları ayrıştırılarak başlanır. İstenilen detayda alt seviyelere inildiğinde işlem durdurulur. 7
1.Ayrıştırma (Decomposition) (devam...) Fonksiyonel Ayrıştırma 8
1.Ayrıştırma (Decomposition) (devam...) Fonksiyonel Ayrıştırma 9
2.Kohezyon (Cohesion) Yazılım mühendisliğinde kohezyon; bir sınıftaki tanımlı üyelerin birbirlerine mantıksal ilişkilenmesi biçiminde tanımlanabilir. Diğer bir deyişle kohezyon, sınıf içerisindeki üyelerin ya da fonksiyonlar içindeki görevlerin birbirlerine olan mantıksal uzaklığını belirler. 10
2.Kohezyon (Yapışıklık) (devam...) Tasarımda kohezyon faktörünün yüksek olması arzu edilir. Zira bir sınıfa ilişkin üye fonksiyonlar aralarında mantıksal bir kopukluk olmayacak şekilde yazılmış olmalıdır. Üyeler arasındaki mantıksal kopukluklar kohezyonu azaltarak sınıfın yazılma amacını çarpıtacağı gibi bağımlılıkların da artmasına neden olur. 11
2.Kohezyon (Yapışıklık) (devam...) Örneğin; string işlemleri için yazılmış bir sınıf, string'in ekrana basılmasını sağlayan fonksiyonlara sahip olmamalıdır. Her şeyden önce böylesi yanlış bir tercih, o sınıfı sadece belirli GUI sistemleriyle çalışmaya bağımlı kılacaktır. Öte yandan o string sınıfı içinde yazılan ve string işlemleriyle doğrudan ilişkili fonksiyonlar ise olması arzu edilen yüksek kohezyonu yaratacak bir tercihtir. 12
2.Kohezyon (Yapışıklık) (devam...) 13
2.Kohezyon (Yapışıklık) (devam...) Yüksek kohezyon yazılım sisteminin esnekliğini arttırır, bakım ve yeniden kullanılabilirliği kolaylaştırır. Kohezyonun türleri: Rastlantısal (Coincidental) Kohezyon Mantıksal (Logical) Kohezyon Geçici (Temporal) Kohezyon Prosedürel Kohezyon Ardışıl Kohezyon Fonksiyonel Kohezyon 14
3.Tek Sorumluluk Prensibi (SRP) Tek Sorumluluk Prensibi (Single Responsibility Principle) Kohezyon olgusuyla yakından ilişkili olup, bir modülün (örneğin sınıfın) sadece tek bir sorumluluğu yerine getirmek üzere tasarlanmasını öngörmektedir. 15
3.Tek Sorumluluk Prensibi (SRP) (devam...) Bu prensip diğer bir bakış açısıyla Kohezyon kavramının özgün bir tanımıdır. Zira gereksiz sorumluluklardan arındırılarak sadece belirli bir görevi yerine getirmek üzere tasarlanmış bir sınıf elde etmenin yolu; sınıfın yazılma amacını çarpıtacak yani kohezyonunu düşürecek fonksiyonlara yer vermemektir. 16
3.Tek Sorumluluk Prensibi (SRP) (devam...) Bu prensibin uygulanması teoride kolay ancak pratikte zor olmaktadır. Sorumluluk ya da görevleri ayrıştırabilmek zordur. Doğru bir tasarımda ileride olabilecek bir değişiklikte sadece değişen durumun sorumluluğunu üstlenmiş sınıf değiştirilebilir olması öngörülür. 17
3.Tek Sorumluluk Prensibi (SRP) (devam...) Yani; bir sınıfı değiştirmek için sadece tek bir gerekçeniz olmalıdır. Şayet birden fazla gerekçe söz konusuysa o sınıfın bölünmeye ihtiyacı var demektir. Çünkü değişiklik ihtiyacı daima bir tek nedene dayandırılmalıdır. 18
3.Tek Sorumluluk Prensibi (SRP) (devam...) Üye sınıfına gereğinden fazla sorumluluk yüklenmiştir. GirisYap(), EPostaGonder(), SmsGonder(), HaberGonder() fonksiyonları kohezyonun düşmesine neden olmaktadır. 19
3.Tek Sorumluluk Prensibi (SRP) (devam...) Doğru tasarım şu şekilde olmalıdır: Kodlayalım 20
3.Tek Sorumluluk Prensibi (SRP) (devam...) Uye.java 21
3.Tek Sorumluluk Prensibi (SRP) (devam...) SmsUtil.java 22
3.Tek Sorumluluk Prensibi (SRP) (devam...) GirisServisi.java 23
4.Zayıf Bağlaşım Prensibi (LCP) Gerçek dünyada nesneler nadiren tek başlarına bulunmaktadırlar. Çoğu zaman birbirleriyle ilişki ve iletişim halinde olan nesneler birbirlerini içerebilir ya da çeşitli biçimlerde kullanabilirler. Coupling, nesneler arasındaki ilişkilerin nesneleri birbirlerine ne kadar bağlı kıldığının ölçütüdür. 24
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Sınıf A Sınıf B Coupling Kohezyon Kohezyon Kohezyon faktörü; sınıf içerisindeki dolayısıyla nesneye ilişkin üyelerin birbirleriyle mantıksal ilişkisi olarak tanımlanmıştı. Kendi içinde kohezyonu yüksek sınıfların birbirleriyle ilişkiler kurarken, bu ilişkide coupling faktörü olabildiğince düşük tutulmalıdır. 25
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Coupling faktörünün 5 seviyesi vardır: 1. Nil Coupling 2. Export Coupling 3. Overt Coupling 4. Covert Coupling 5. Surreptitious (Gizlice) Coupling 26
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) 1. Nil Coupling Teorik olarak en düşük dolayısıyla en iyi coupling düzeyidir. Zira bu seviyede bağımlılık söz konusu olmamaktadır. Diğer sınıflarla hiçbir ilgisi olmayan, tek başlarına kullanılan sınıflar bu duruma örnek teşkil etmektedir. 27
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) 2. Export Coupling Herhangi bir sınıf başka bir sınıfa ortak bir arayüzle bağlıysa aralarında export coupling oluşur. Birçok durumda ulaşılmaya çalışılan ideal seviye export coupling seviyesidir. Bu seviyeden sonraki seviyeler yaratılmak istenen low coupling ilkesine zarar vermeye başlar. 28
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) 3. Overt Coupling Bir sınıf, başka bir sınıfa ilişkin üyeleri belli bir izin dahilinde kullanıyorsa aralarında overt coupling söz konusudur. 4. Covert Coupling Bir sınıf, başka bir sınıfa herhangi bir izin vermeden arkadaşlık kurması durumudur. 29
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) 5. Surreptitious (Gizlice) Coupling Bir sınıf, başka bir sınıfın içsel detaylarının tümünü biliyorsa ve bunları kullanarak işlem gerçekleştiriyorsa bu sınıfların arasında surreptitious coupling oluşur. Tasarım açısından tehlikelidir. Bağımlılık, prensip gereğince az olması gerekirken, bu seviyedeki coupling de çok fazladır. 30
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Aşağıdaki UML de gösterildiği gibi bir sınıfın içerisinde başka bir sınıftan nesne yaratmak ve o nesnelerle bir çok işlem yaptırmak coupling i oldukça arttırmaktadır. Kumanda Televizyon 31
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Dikkat!!! Yanlış Tasarım!!! 32
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Burada kumanda nesnesi görevini yapabilmek için televizyon nesnesine ihtiyaç duymaktadır, yani kumanda televizyona bağımlıdır. Tasarım kırılgan olup bu bağımlılığım zararları aşağıdaki gibidir: Tv olmazsa kumanda bir işe yaramaz. Tv değiştiğinde kumanda bu değişimden direk etkilenir. Kumanda sadece televizyonu kontrol edebilir başka aletleri kontrol edemez. Kumanda Televizyon 33
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) ÇÖZÜM Kumanda ile Televizyonun sınıfsal ve nesnesel bağını kopart. Kumanda içerisinde IKumanda interface i ile bağ kur. Televizyon sınıfı da IKumanda interface ini implement etsin. Hatta Radyo sınıfını da ekle. O da IKumanda interface ini implement etsin. Tasarımı test et. 34
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) IKumanda.java Televizyon.java 35
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Kumanda.java 36
4.Zayıf Bağlaşım Prensibi (LCP) (devam...) Radyo.java KumandaTest.java 37
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,2001 http://www.algoritmaveprogramlama.com 38
İYİ ÇALIŞMALAR Yrd. Doç. Dr. Deniz KILINÇ deniz.kilinc@cbu.edu.tr 39