Tasarım Desenlerinin Kaç İlkesi Vardır?
Categories:
En erken tasarımlı desenler sadece 5 idi, yani SOLID:
Tek Sorumluluk İlkesi (Single Responsibility Principle, SRP): Bir sınıfın değişiklik nedeni olmaması gerekir, yani bir sınıfın tek bir sorumluluğu olmalıdır.Açık/Kapalı İlkesi (Open/Closed Principle, OCP): Yazılım varlıkları (sınıflar, modüller, fonksiyonlar vb.) genişletmeye açık, değişikliğe kapalı olmalıdır, yani mevcut kodu değiştirmek yerine genişletme yoluyla değişiklikler yapılmalıdır.Liskov Yerine Koyma İlkesi (Liskov Substitution Principle, LSP): Alt tiplerin temel tiplerini yerine koyması gerekir, yani türev sınıf temel sınıfını değiştirmeden programın doğruluğunu etkilemeden yerine koymalıdır.Arayüz Ayrımı İlkesi (Interface Segregation Principle, ISP): İstemcilerin kullanmadıkları arayüzlere bağımlı olmaları zorunlu olmamalıdır. Büyük arayüzleri daha küçük ve daha spesifik arayüzlere ayırmalıyız, böylece istemciler yalnızca ihtiyaç duydukları metotları bilmelidir.Bağımlılık Tersine Çevirme İlkesi (Dependency Inversion Principle, DIP): Yüksek seviyeli modüller düşük seviyeli modüllere bağımlı olmamalı, her ikisi de soyutlamaya bağımlı olmalıdır. Soyutlamalar somut uygulama ayrıntılarına bağımlı olmamalı, somut uygulama ayrıntıları soyutlamaya bağımlı olmalıdır.
Daha sonra iki kural eklendi. Bu eklenen kurallar daha somut ve daha yönlendirici. SOLID açıklamalarından nasıl yapılmalı şeklinde, eklenen kurallardan öncelikle/tercihen nasıl yapılmalı şeklinde anlayabiliriz.
Birleştirme/Toplama Yeniden Kullanım İlkesi (Composition/Aggregation Reuse Principle, CARP): Kodun yeniden kullanılması için miras yerine nesne birleştirmeyi (kompozisyon) ve toplamayı tercih etmeliyiz.Demeter Yasası (Law of Demeter, LoD): Bir nesnenin diğer nesneler hakkında mümkün olduğunca az bilgiye sahip olması gerekir, yani bir nesnenin diğer nesnelerin iç yapısı ve uygulama ayrıntıları hakkında az bilgiye sahip olması gerekir.
Önceki bölümde bahsedilen yaygın tasarım ilkelerinin yanı sıra, yazılım tasarımı ve mimarisinde önemli bir rehberlik sağlayan, ama önceki kadar yaygın olmayan diğer tasarım ilkeleri de vardır. Sonradan eklenen bu kurallar biraz abartı gibi, en azından ben bunların sezgisel olmadığını, derinlemesine düşünülmesi gerektiğini düşünmüyorum.
En Az Bilgi İlkesi (Principle of Least Knowledge, PoLK): Demeter Yasası’nın bir uzantısı olarak da bilinen bu ilke, bir nesnenin diğer nesnelerin bilgisini mümkün olduğunca azaltması gerektiğini savunur. Bu ilkenin kökeni 1987’de Patricia Lago ve Koos Visser tarafından geliştirilen “En Az İletişim İlkesi"ne dayanır.Kararlı Bağımlılık İlkesi (Stable Dependencies Principle, SDP): Bu ilke, yazılım tasarımı kararlı bileşenlerin kararsız bileşenlere bağımlı olmaması gerektiğini, yani kararlılığı yüksek olan bileşenlerin kararlılığı düşük olan bileşenlere daha az bağımlı olması gerektiğini savunur. Bu ilkenin temeli, yazılım sistemindeki bileşenler arasındaki ilişkilerin ayrıntılı incelenmesine dayanır.Kararlı Soyutlama İlkesi (Stable Abstraction Principle, SAP): Kararlı Bağımlılık İlkesi’ne paralel olarak, bu ilke soyutlamayı kararlılıkla eşleştirmeyi, yani kararlı bileşenlerin soyut olması ve kararsız bileşenlerin somut olması gerektiğini rehberlik eder. Bu ilke, yazılım sisteminin kararlılığı ve esnekliği sağlamak için yardımcı olur.