Yazılım geliştirmede tasarım modelleri: Biraz farklı IKEA raf sistemi

Saberie

Active member
Tasarım desenleri, çeşitli boyut ve renklerde mevcut olan IKEA modüler raf sistemini anımsatıyor. Her zaman aynı şekilde birleştirilebilirler ve her zaman aynı amaca hizmet edebilirler. Renk programlama diliyle, rafın boyutu tasarım modeliyle karşılaştırılabilir. Uygulamaya ve projenin büyüklüğüne göre farklı renk veya ebatta raf kullanılabilir.

Duyuru



Özellikle tasarım desenleri, nesne yönelimli programlamada (OOP) yeniden kullanılabilir kodun öğeleridir. Sabit bir tasarımları yoktur ve tamamlanmış kod içermezler. Tasarım modelleri, OOP dünyasındaki tipik sorunlara çözümler sunar ve aynı zamanda giderek daha karmaşık hale gelen çerçevelerle de ilgilidir. Bir bilgisayar bilimcisi, söz konusu programlama dili ne olursa olsun bunları kullanabilir.







Bu makale, Haberler editör ekibinin genç geliştiricileri güncel trendler, gelişmeler ve kişisel deneyimler hakkında bilgi vermeye davet ettiği bir dizi makalenin parçasıdır. Siz de “genç bir profesyonel” misiniz ve (ilk) makalenizi yazmak mı istiyorsunuz? Önerinizi editör ekibine gönderin: Developer@Haber. Yazılarınızda size yardımcı olmak için buradayız.







Şu anda 100'den fazla farklı tasarım modeli bulunmaktadır (Ocak 2024 itibarıyla). Her tasarım desenine bir tür atanabilir. Temel türleri şunlardır: nesil modelleri, yapısal modeller ve davranışsal modeller. Ama artık başka türler de var. Giderek artan sayıda tasarım deseni nedeniyle eklendiler. Basitlik açısından bu makale yalnızca temel türlere odaklanacaktır (Şekil 1).







Tasarım deseni birkaç alt kümeye bölünmüştür. En iyi bilinenler listelenmiştir (Şekil 1).



İlk tip nesil modellerdir. Bunlar yalnızca yeni örnekler oluşturmak ve spesifik uygulamasına bakılmaksızın yeni bir nesnenin oluşturulmasına izin vermek için kullanılır. Bu, nesne yaratımının dışsallaştırıldığı ve kapsüllendiği anlamına gelir. En sık kullanılan üretim modelleri singleton ve fabrika yöntemidir.

Benzersiz bir parça yaratın


Singleton, OOP'ta erişim koruması olmayan global bir değişken olarak düşünülebilir. Tüm çalışma süresi boyunca yalnızca bir kez oluşturulabilir, bu nedenle bir sistemde en fazla bir singleton örneği bulunur. Örnek yönetimini kapsar ve birleşik bir erişim noktası sağlar.

Her singleton, özel bir statik değişkenden ve yayınlanmış bir statik yöntemden oluşur (Şekil 2). Değişken, nesnenin tüm yaşam döngüsü boyunca mevcut örneğini içerir. Genel yöntem getInstance() statik bir değişken döndürür. Örneği yalnızca nesnenin kendisi oluşturabilir. Özel bir inşaatçı bunu garanti eder.







Bir singleton, genel bir statik yöntem ve özel bir statik değişkenden oluşur (Şekil 2).



Yapının kullanımı ve anlaşılması kolaydır. Aynı zamanda mimari kararları da kolaylaştırır. Ancak bazı dezavantajlar da var. Bir yandan, kullanıcı bir singleton'a her eriştiğinde sınıfın tam adına ihtiyaç duyar. Bu, otomatik yazılım testinde büyük bir sorun olan belirli türe güçlü bir bağlantı oluşturur. Son olarak, yapay öğeler genellikle gereksiz öğelerin yerini alır. Ancak klasik programlama yöntemlerini kullanan singleton ile bu mümkün değildir. Öte yandan bu yapının kullanılması sistem mimarisini kötüleştirir. Sonuçta bu nesne için herhangi bir erişim kontrolü mümkün değildir ve herhangi bir kullanıcı ona erişebilir. Uygulamada kullanıcıların Singleton yapısal modelinin kullanımı konusunda dikkatli düşünmeleri gerekmektedir.

Bu yapı, basitliği nedeniyle özellikle yeni başlayanlar arasında popülerdir. Yazılım mimarisini dikkate almayan çeşitli örnekler olmasına rağmen, birçok dezavantaj nedeniyle yalnızca istisnai durumlarda kullanılmalıdır: örneğin test edilebilirlik veya erişim kontrolünün gerekli olmadığı durumlarda.



Haberin Sonu
 
Üst