--- title: Yapısal Tasarım Kalıpları slug: yapisal-tasarim-kaliplari-e9388 url: /detay/yapisal-tasarim-kaliplari-e9388 type: article language: Türkçe entity: primary: Yapısal Tasarım Kalıpları type: article disambiguation: Yapısal Tasarım Kalıpları: Adapter, Bridge ve daha fazlası. Uyumluluk ve esneklik için ideal çözümler. categories: - name: Yazılım Ve Yapay Zekâ slug: yazilim-ve-yapay-zeka url: /kategori/yazilim-ve-yapay-zeka tags: - SoftwareEngineering - DesignPatternsInJava - CleanCode - StructuralPatterns - DesignPatterns author: Sinan Turan created_at: 2025-04-09T11:56:20.785297+03:00 updated_at: 2025-04-17T09:52:45.179360+03:00 --- # Yapısal Tasarım Kalıpları ## Article Content ### ** 1. Adapter (Uyarlayıcı) Tasarım Kalıbı** İki uyumsuz arayüzün [birlikte](/tr/detay/birlikte/llms.txt) çalışmasını sağlar. Var olan bir sınıfın arayüzünü, beklenen başka bir arayüze çevirir. Yeni bir kodu eski sisteme entegre etmek için idealdir. #### **-> Ne Zaman Kullanılır** - Halihazırdaki bir sınıf, ihtiyacımız olan işlevselliğe sahiptir ama beklediğimiz arayüze uymuyorsa. - Üçüncü parti kütüphaneleri kendi sistemimize entegre etmek istiyorsak. - Geriye dönük uyumluluk (backward compatibility) istiyorsak. #### **-> Kod Örneği** Diyelim ki bir uygulamamız Target arayüzünü kullanan sınıflarla çalışıyor. Ancak elimizde Adaptee adında farklı bir arayüze sahip bir sınıf var. Bu iki sınıf uyumsuz. Adapter, Adaptee sınıfını Target arayüzüne uydurur. - Target: Sistemimizin beklediği arayüz. - Adaptee: Farklı arayüze sahip ama işlevsel olarak ihtiyacımızı karşılayan sınıf. - Adapter: Adaptee'yi alır ve Target arayüzüne çevirir. - Client: Sadece Target arayüzüyle ilgilenir. #### **->Avantajları** - Var olan kodu değiştirmeden yeni sistemle uyumlu hale getirmeni sağlar. - Eski sistemlerin yeniden kullanılmasını kolaylaştırır. - Farklı arayüzler arasında geçiş köprüsü oluşturur. #### **->Dezavantajları** - Kodun karmaşıklığını artırabilir. - Gereğinden fazla adapter kullanımı bakımı zorlaştırabilir. ###  **2. Bridge (Köprü) Tasarım Kalıbı** Soyutlama (abstraction) ile implementasyon (uygulama) arasındaki bağımlılığı ayırarak, her ikisinin de [bağımsız](/tr/detay/bagimsiz-2/llms.txt) olarak geliştirilebilmesini sağlar. #### **->Ne Zaman Kullanılır** - Soyutlama ve onun implementasyonunu ayrı ayrı değiştirmek istiyorsan. - Sınıf hiyerarşisinin patlamasını (class explosion) önlemek istiyorsan. - Birden fazla boyutta değişkenliğe sahipsen (örneğin **Cihaz Türü** ve **Marka** gibi iki eksen varsa). #### **->Gerçek Hayat Analojisi** TV'yi uzaktan kumandayla kontrol ettiğimizi düşün. TV farklı markalarda olabilir (Sony, Samsung...), kumandalar ise farklı türlerde olabilir (BasicRemote, AdvancedRemote...). Kumanda ile TV arasında bir [köprü](/tr/detay/kopru-3/llms.txt) kurarız. TV’yi soyutlarız ve farklı kumandaları onun üzerinde çalıştırabiliriz. #### **->Kod Örneği** Uygulanacak yapılar: - **Abstraction**: Kumanda (Remote) - **Implementor**: Cihaz (Device) - **RefinedAbstraction**: Gelişmiş kumanda (AdvancedRemote) - **ConcreteImplementor**: Somut cihazlar (TV, Radio) - Device: Uygulanacak işlevlerin soyut arayüzü. - Tv: Bu arayüzün bir uygulaması (başka cihazlar da olabilir). - Remote: Soyut bir kumanda. - AdvancedRemote: Kumandanın gelişmiş versiyonu. - **Remote** ile **Device** arasında bir "köprü" vardır. Yeni cihazlar eklediğinde kumandayı değiştirmene gerek kalmaz; yeni kumandalar eklediğinde de cihazı değiştirmezsin. #### **->Avantajları** - Soyutlama ile implementasyonu ayırır. - Her iki taraf bağımsız olarak geliştirilebilir. - Kod tekrarını azaltır, genişletilebilirliği artırır. #### **->Dezavantajları** - Ekstra katmanlar sebebiyle yapı biraz daha karmaşık olabilir. ### ** 3.** **Composite Design Pattern (Bileşik Tasarım Deseni)** Nesneleri [ağaç](/tr/detay/agac-4/llms.txt) yapısı (tree structure) şeklinde organize edip, bireysel nesnelerle nesne gruplarını aynı şekilde işlemeni sağlar. #### **->Ne zaman Kullanılır** - Nesnelerin **hiyerarşik yapıda** olduğu durumlarda. - Müşterinin (client) hem **tekil nesneler** hem de **nesne grupları** ile aynı şekilde işlem yapmasını istediğinde. #### **->Gerçek Hayat Analojisi** Bir şirketin yapısını düşün: CEO, yöneticiler ve çalışanlar. Bir yöneticinin altında başka yöneticiler ve çalışanlar olabilir. Ama hepsi birer “çalışan”dır ve hepsi için getSalary() gibi işlemler yapılabilir. Yani alt elemanları olan bir grup elemanı da, sıradan bir çalışan gibi ele alabiliriz. #### **->Kod Örneği** Uygulanacak Yapılar: - **Component**: Ortak arayüz (Graphic) - **Leaf**: Yaprak nesne (Dot, Circle) - **Composite**: Grup nesnesi (CompoundGraphic) - Graphic: Ortak arayüz, hem Dot hem de CompoundGraphic bunu uygular. - Dot, Circle: Basit grafik öğeleri. - CompoundGraphic: Birden fazla grafik öğesini veya diğer CompoundGraphic nesnelerini tutabilen grup nesnesi. - graphic.draw() çağrısı, hem tekil hem de bileşik nesneleri çizer. #### **->Avantajları** - Karmaşık ağaç yapılar basitçe temsil edilir. - Müşteri kodu, bireysel nesneler ile grupları ayırt etmeden kullanabilir. - Kolay genişletilebilirlik. #### **->Dezavantajları** - Tasarımı anlamak ve uygulamak karmaşık olabilir. - Ağaç yapısının yönetimi dikkat gerektirir. ### **4.Decorator Design Pattern (Süsleyici Tasarım Deseni)** Bir nesnenin davranışını, **mevcut sınıfı değiştirmeden** [dinamik](/tr/detay/dinamik-3/llms.txt) olarak ([çalışma](/tr/detay/calisma/llms.txt) zamanında) genişletmek için kullanılır. #### **->Ne Zaman Kullanılır** - Sınıfın işlevselliğini **alt sınıf oluşturmadan** değiştirmek istiyorsan. - Nesneye yeni işlevler eklemek istiyorsan ama kalıtım zinciri karmaşıklaşmasın istiyorsan. #### **->Gerçek Hayat Analojisi** [Kahve](/tr/detay/kahve-2/llms.txt) sipariş sistemini düşün. Bir temel kahven var (Coffee), ve üstüne süt, [şeker](/tr/detay/seker-751562/llms.txt), [çikolata](/tr/detay/cikolata-751797/llms.txt) gibi süslemeler (MilkDecorator, SugarDecorator) ekleyebilirsin. Her dekorasyon, yeni özellikler ekler ama kahvenin kendisi değişmez. #### **->Kod Örneği** - **Component**: Ortak arayüz (DataSource) - **ConcreteComponent**: Temel nesne (FileDataSource) - **Decorator**: Soyut süsleyici (DataSourceDecorator) - **ConcreteDecorator**: Özelleştirilmiş süsleyici (EncryptionDecorator, CompressionDecorator) - FileDataSource: Temel veri kaynağı. - EncryptionDecorator ve CompressionDecorator: Ek özellikler (şifreleme, sıkıştırma) kazandırır. - writeData() sırasıyla şifreleyip sıkıştırarak yazar. - readData() sırasıyla sıkıştırmayı açıp şifreyi çözer. #### **->Avantajları** - Yeni işlevler **alt sınıf oluşturmadan** eklenebilir. - Dinamik olarak davranış değiştirilebilir. - Birden fazla dekoratör üst üste uygulanabilir. #### **->Dezavantajları** - Çok sayıda küçük sınıf oluşturulabilir. - Hangi sırayla dekoratörlerin uygulanacağına dikkat etmek gerekir. ### ** 5.** **Facade Design Pattern (Cephe Tasarım Deseni)** Karmaşık bir sistemi basitleştirmek için kullanılan bu desen, birden fazla sınıf veya alt sistemin karmaşık işlevlerini **tek bir arayüzde birleştirerek** dış dünyaya sade bir görünüm sunar. #### **->Ne Zaman Kullanılır** - Alt sistem çok karmaşıksa ve kullanıcılar yalnızca belirli işlemleri basitçe yapmak istiyorsa. - Kodun okunabilirliğini ve kullanılabilirliğini artırmak istiyorsan. - Sisteme daha az bağımlılık ile erişmek istiyorsan. #### **->Gerçek Hayat Analojisi** Bilgisayarı açmak istiyorsun. Sen sadece **"Güç"** butonuna basarsın. O buton aslında birçok bileşeni çalıştırır: CPU, RAM, SSD vs. Seninle bu bileşenler arasında bir **"cephe" (facade)** vardır. #### **->Kod Örneği** - CPU, Memory, HardDrive: Alt sistemler. - ComputerFacade: Bu sistemleri dış dünyaya basit bir start() fonksiyonu ile sunar. - Client: Yalnızca start() çağırarak karmaşık işlemler zincirini başlatır. #### **->Avantajları** - Karmaşık sistemler basitleştirilir. - Bağımlılıklar azaltılır. - Kodun okunabilirliği ve bakımı kolaylaşır. #### **->Dezavantajları** - Fazla soyutlama bazı gelişmiş kullanıcılar için sınırlayıcı olabilir. - Facade sınıfı zamanla aşırı büyüyebilir ve **God Object**’e dönüşebilir. ### **6. Flyweight Design Pattern (Ağırlıksız Nesne Tasarım Deseni)** Flyweight tasarım deseni, **büyük sayıda nesnenin** bellekte verimli bir şekilde saklanmasını sağlamak için **paylaşılan durumları** (state) kullanır. Bu sayede, aynı veriyi birden fazla nesne için yeniden saklamak yerine **paylaşımlı hale getirir** ve belleği optimize eder. #### **->Ne Zaman Kullanılır** - Çok sayıda benzer nesne yaratılacaksa ve bellek kullanımı önemliyse. - Nesnelerin çoğu aynı veriyle çalışıyorsa ve sadece küçük bir kısmı farklıysa. - Bellek optimizasyonu sağlamak istiyorsan. #### **->Gerçek Hayat Analojisi** Birden fazla **kâğıt uçak** yapıyorsun. Her uçak, **aynı formda** olacak (aynı [yapı](/tr/detay/yapi-2/llms.txt), renkler vs.). Ancak her uçakta uçuş için **farklı bir yön veya hız** olabilir. Yani, **sadece uçuş yönü ve hızı** gibi değişkenler farklı olur, geri kalan tüm şeyler **paylaşılabilir**. #### **->Kod Örneği** - TreeType: Ağaç türlerini temsil eder ve nesnelerin **paylaşılan özelliklerini** (isim, renk) içerir. - TreeFactory: Nesne yaratımı ile ilgilenir. Aynı ağaç türüne sahip nesneler için **paylaşımı sağlar**. - Client: Aynı ağaç türünü farklı konumlarda çizerek belleği verimli kullanır. #### **->Avantajları** - Bellek kullanımı optimize edilir, çünkü paylaşılan nesneler sadece bir kez yaratılır. - Çok sayıda nesneyle çalışırken performans artışı sağlar. - **Paylaşılan nesneler**, bellekte gereksiz yere tekrar tutulmaz. #### **->Dezavantajları** - Yönetilmesi karmaşık olabilir, çünkü nesneler paylaşılır. - Nesnelerin paylaşılması, bazı durumlarda **esneklik** kaybına neden olabilir. ### **7. Proxy Design Pattern (Proxy Tasarım Deseni)** Proxy tasarım deseni, başka bir nesnenin **yerine geçerek** onunla olan etkileşimleri kontrol eder. Proxy, genellikle bir nesneye erişimi **kontrol etmek**, **ertelemek** veya **yönlendirmek** için kullanılır. #### **->Ne Zaman Kullanılır** - Nesneye **gerçekten ihtiyaç duyulmadan önce** ona erişimi kontrol etmek istiyorsan. - Büyük nesnelerin **yükleme maliyetlerini** önlemek veya **veritabanı erişimlerini** sınırlamak istiyorsan. - Güvenlik, erişim kontrolü veya **özelleştirilmiş işleme** ihtiyaç duyuyorsan. #### **->Gerçek Hayat Analojisi** Bir **araba kiralama** şirketini düşün. [Araba](/tr/detay/araba-2/llms.txt) gerçekten sadece **kullanıcı kiralama işlemi** gerçekleştiğinde teslim edilir. Öncesinde arabanın **fiziksel olarak verilmesi gerekmez**. Proxy, bir **araba temin etme** servisi gibi çalışır; ancak arabanın kendisi yalnızca gerektiğinde sağlanır. #### **->Kod Örneği** - RealSubject: Gerçek nesnenin işlevselliğini barındıran sınıftır. - Proxy: Gerçek nesneye erişimi **kontrol eden** sınıftır. Gerçek nesne yalnızca gerektiğinde **proxy tarafından yüklenir**. - Client: Proxy sınıfını kullanarak **gerçek nesneye erişir**. Proxy, gerçek nesneye erişim sağlamak için gerekli işlemleri yapar. #### **->Avantajları** - **Gecikmeli yükleme** sağlar, yani sadece gerçekten gerekli olduğunda nesne yaratılır. - Erişim kontrolü ve **güvenlik** için yararlıdır. Proxy, gerçek nesnenin erişimini kontrol edebilir. - **Performans optimizasyonu** sağlar, özellikle büyük nesnelerle çalışırken. #### **->Dezavantajları** - **Ekstra karmaşıklık** ekler, çünkü her nesneye erişim proxy üzerinden yapılır. - Proxy ile gerçek nesne arasındaki etkileşimler bazen **karışık** hale gelebilir. #### **->Kullanım Senaryoları** - **Sanat galerisi**: Gerçek resimler büyük ve pahalıdır. Proxy, galerideki **resimleri** sadece gerektiğinde yükler. - **Veritabanı bağlantıları**: Veritabanına bağlanmak **yüksek maliyetli** olabilir, bu yüzden proxy, veritabanına erişimi **gerektiğinde** sağlar. ## Academic Sources and References 1. "Structural Design Patterns," Refactoring Guru. Erişim Tarihi: 2025-04-05. https://refactoring.guru/design-patterns/structural-patterns. 2. Freeman, Eric, Elisabeth Robson, Bert Bates, and Kathy Sierra. Head First Design Patterns. O'Reilly Media, 2004. 3. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.