Proxy, Dekoratör, Adaptör ve Köprü Kalıpları arasındaki farklar nelerdir?

Proxy Deseni'ne bakıyordum ve bana göre Dekoratör, Adaptör ve Köprü desenleri gibi korkunç bir şey gibi görünüyor. Bir şeyi yanlış mı anlıyorum? Fark ne? Neden Proxy desenini diğerlerine karşı kullanayım? Bunları geçmişte gerçek dünya projelerinde nasıl kullandınız?

Proxy, Dekoratör, Bağdaştırıcı ve Köprü, bir sınıfın "kaydırılması" ndaki çeşitlemelerdir. Ancak kullanımları farklıdır.

• Proxy , bir nesneyi tembel olarak başlatmak veya uzak bir hizmeti çağırdığınızı gizlemek veya nesneye erişimi kontrol etmek istediğinizde kullanılabilir.

• Dekoratöre "Akıllı Proxy" de denir. Bu, bir nesneye işlevsellik eklemek istediğinizde kullanılır, ancak nesnenin türünü genişleterek kullanılmaz. Bu, çalışma zamanında bunu yapmanızı sağlar.

• Bağdaştırıcı , soyut bir arabiriminiz olduğunda kullanılır ve bu arabirimi benzer işlevsel rolü olan, ancak farklı bir arabirime sahip başka bir nesneye eşlemek istediğinizde.

• Bridge , Bağdaştırıcıya çok benzer, ancak hem soyut arabirimi hem de temeldeki uygulamayı tanımladığınızda Bridge olarak adlandırırız. Yani bazı eski veya üçüncü taraf kodlarına adapte olmuyorsunuz, tüm kodun tasarımcısı sizsiniz, ancak farklı uygulamaları değiştirebilmeniz gerekiyor.

• Cephe , bir veya daha fazla sınıftan oluşan bir alt sistem için daha yüksek düzeyli (okuma: daha basit) bir arabirimdir. Diyelim ki birden fazla nesnenin temsil edilmesini gerektiren karmaşık bir kavramınız var. Hangi nesne kümesinde değişiklik yapmak kafa karıştırıcıdır, çünkü hangi nesnenin çağırmanız gereken yönteme sahip olduğunu her zaman bilmezsiniz. Nesnelerin toplanmasında yapabileceğiniz tüm karmaşık işlemler için üst düzey yöntemler sağlayan bir Cephe yazma zamanı. Örnek: gibi yöntemlerle bir okul bölümü için Alan Modeli, countStudents(), reportAttendance(), assignSubstituteTeacher(), vb.

Bill'in cevabının dediği gibi, kullanım durumları farklıdır .

Yapıları da öyle.

• Proxy ve Dekoratör her ikisi de sarılmış türleriyle aynı arabirime sahiptir, ancak proxy kaputun altında bir örnek oluşturur, oysa dekoratör yapıcıda bir örnek alır.

• Adaptör ve Cephe'nin her ikisi de sardıklarından farklı bir arayüze sahiptir. Ancak adaptör mevcut bir arayüzden elde edilirken, cephe yeni bir arayüz oluşturur.

• Köprü ve Adaptör her ikisi de mevcut bir türü işaret eder. Ancak köprü soyut bir türe işaret eder ve adaptör somut bir türe işaret edebilir. Köprü, uygulamayı çalışma zamanında eşleştirmenize izin verirken, adaptör genellikle bunu yapmaz.

Konuyu ele alacağım.

Dört desenin de ortak noktası vardır, dördü de bazen gayri resmi olarak sarmalayıcı veya sarmalayıcı desen olarak adlandırılır. Hepsi kompozisyon kullanır, özneyi sarar ve yürütmeyi bir noktada özneye devrederken, bir yöntem çağrısını diğerine eşleme yapar. Müşteriye farklı bir nesne inşa etme ve ilgili tüm verilerin üzerine kopyalama yapma gereğini yedeklerler. Akıllıca kullanılırlarsa, bellek ve işlemci tasarrufu sağlarlar.

Gevşek kuplajı teşvik ederek, bir zamanlar istikrarlı kodu kaçınılmaz değişikliklere daha az maruz bırakır ve diğer geliştiriciler için daha iyi okunabilir hale getirir.

adaptör

Adaptör konuyu (adapte) farklı bir arayüze uyarlar. Bu şekilde, nominal olarak farklı tipte bir koleksiyona yerleştirilecek nesne ekleyebiliriz.

Bağdaştırıcı, yalnızca ilgili yöntemleri istemciye maruz bırakır, diğerlerini kısıtlayabilir, harici kitaplığın uyarlanması gibi belirli bağlamlar için kullanım amaçlarını ortaya çıkarabilir, daha az genel görünmesini ve uygulama gereksinimlerimize daha fazla odaklanmasını sağlar. Adaptörler, kodumuzun okunabilirliğini ve kendi tanımını artırır.

Adaptörler bir takımı diğer takımlardan gelen geçici koddan korur; offshore takımlarıyla uğraşırken hayat kurtarıcı bir araç ;-)

Daha az bahsedilen, konu sınıfının ek açıklamaları aşmasını önlemeyi amaçlamaktadır. Ek açıklamalara dayanan çok sayıda çerçeveyle bu, her zamankinden daha önemli bir kullanım haline geliyor.

Bağdaştırıcı, yalnızca tek kalıtımın Java sınırlamasını aşmanıza yardımcı olur. Birden fazla kalıtım izlenimi veren birkaç uyarlamayı tek bir zarf altında birleştirebilir.

Kod bakımından Adaptör “incedir”. Adaptasyon sınıfına çok fazla kod eklememeli, sadece adaptasyon yöntemini ve bu tür çağrıları yapmak için gerekli veri dönüşümlerini çağırmanın yanı sıra.

JDK veya temel kütüphanelerde pek çok iyi adaptör örneği yoktur. Uygulama geliştiricileri, kütüphaneleri uygulamaya özel arayüzlere uyarlamak için Adaptörler oluşturur.

Dekoratör

Dekoratör sadece temsilci değil, sadece bir yöntemi diğerine eşler, daha fazlasını yaparlar, bazı konu yöntemlerinin davranışını değiştirirler, konu yöntemini hiç çağırmamaya karar verebilir, farklı bir nesneye, yardımcı bir nesneye delege edebilirler.

Dekoratörler genellikle günlüğe kaydetme, şifreleme, biçimlendirme veya nesneye sıkıştırma gibi sarılmış nesneye işlevsellik ekler (saydam olarak). Bu Yeni işlev birçok yeni kod getirebilir. Bu nedenle, dekoratörler genellikle Adaptörlerden çok daha “şişmandır”.

Dekoratör, öznenin arayüzünün bir alt sınıfı olmalıdır. Konuları yerine şeffaf olarak kullanılabilirler. Bkz. BufferedOutputStream, yine de OutputStream ve bu şekilde kullanılabilir. Bu Adaptörlerden önemli bir teknik farktır.

Bütün dekoratörler ailesinin ders kitabı örnekleri JDK - Java IO'da. BufferedOutputStream , FilterOutputStream ve ObjectOutputStream gibi tüm sınıflar OutputStream'in dekoratörleridir . Soğan tabakası olabilir, burada bir dekoratör tekrar dekore edilir, daha fazla işlevsellik eklenir.

vekil

Vekil tipik bir paket değildir. Sarılmış nesne, proxy konusu, proxy oluşturulduğu sırada henüz mevcut olmayabilir. Proxy genellikle dahili olarak oluşturur. İstek üzerine oluşturulan ağır bir nesne olabilir veya farklı JVM veya farklı ağ düğümündeki uzak nesne ve hatta yerel koddaki bir bileşen olan Java olmayan bir nesne olabilir. Başka bir nesneye hiçbir şekilde sarılması veya temsil edilmesi gerekmez.

En tipik örnekler uzak proxy'ler, ağır nesne başlatıcılar ve erişim proxy'leridir.

• Remote Proxy - konu uzak sunucuda, farklı JVM'de veya hatta Java olmayan bir sistemde. Proxy, RMI / REST / SOAP çağrılarına veya gerekli olan her şeye yöntem çağrılarını çevirerek istemcinin temel teknolojiye maruz kalmasını önler.

• Lazy Load Proxy - nesneyi yalnızca ilk kullanımda veya ilk yoğun kullanımda tamamen başlatın.

• Erişim Proxy'si - özneye erişimi denetler.

Cephe

Cephe, En Az Bilgi Tasarım İlkesi (Demeter Yasası) ile yakından ilişkilidir. Cephe Adaptöre çok benzer. İkisi de sarıyor, ikisi de bir nesneyi diğerine eşliyorlar, ama niyetleri farklı. Cephe, bir öznenin karmaşık yapısını, karmaşık nesne grafiğini düzleştirir, karmaşık bir yapıya erişimi basitleştirir.

Cephe karmaşık bir yapı sararak ona düz bir arayüz sağlar. Bu, istemci nesnesinin özne yapısındaki iç ilişkilere maruz kalmasını önleyerek gevşek bağlantıyı teşvik eder.

Köprü

Sadece uygulamanın değil, aynı zamanda soyutlamanın da değiştiği Adaptör modelinin daha karmaşık bir çeşidi. Delegasyona bir aktarım daha ekliyor. Ek heyet köprüdür. Arayüzü uyarlama arayüzünden bile ayırır. Karmaşıklığı diğer sarma desenlerinden daha fazla arttırır, bu yüzden dikkatli uygulayın.

Yapıcılardaki farklılıklar

Desen farklılıkları, yapıcılarına bakıldığında da açıktır.

• Proxy var olan bir nesneyi sarmıyor. Yapıcıda konu yok.

• Dekoratör ve Bağdaştırıcı zaten var olan nesneyi sarar ve bu genellikle
  yapıcıda sağlanır.

• Cephe yapıcısı tüm nesne grafiğinin kök elemanını alır, aksi takdirde Bağdaştırıcı ile aynı görünür.

Gerçek hayat örneği - JAXB Marshalling Adaptörü . Bu bağdaştırıcının amacı, basit bir düz sınıfın dışarıdan gereken daha karmaşık yapıya eşleştirilmesi ve konu sınıfının aşırı ek açıklamalarla "kirletilmesini" önlemektir.

GoF modellerinin çoğunda çok fazla çakışma var. Hepsi polimorfizmin gücü üzerine inşa edilmiştir ve bazen sadece gerçekten niyeti farklıdır. (strateji vs eyalet)

Desenler hakkındaki anlayışım, Head First Design Patterns'i okuduktan sonra 100 kat arttı .

Şiddetle tavsiye ederim!

Uzmanlardan gelen tüm iyi cevaplar, her bir modelin ne anlama geldiğini zaten açıkladı.

Ben edecek süslemeleri kilit noktaları.

Dekoratör:

1. Çalışma zamanında nesneye davranış ekleyin . Kalıtım, bu modelin hem avantajı hem de dezavantajı olan bu işlevselliğe ulaşmanın anahtarıdır.
2. Arayüz davranışını değiştirir .

örneğin (zincirleme ile): java.ioInputStream & OutputStreamarayüzlerle ilgili paket sınıfları

FileOutputStream fos1 = new FileOutputStream("data1.txt");  
ObjectOutputStream out1 = new ObjectOutputStream(fos1);

vekil:

1. Tembel başlatma, nesneyi önbelleğe alarak ve istemciye / arayana erişimi kontrol ederek performans iyileştirme için kullanın . Alternatif davranış sağlayabilir veya gerçek nesneyi çağırabilir. Bu işlem sırasında yeni bir Nesne oluşturabilir.
2. aksine Nesnelerin zincirlenmesine izin veren Dekoratör'ün , Proxy zincirlemeye izin vermez.

örneğin: java.rmipaket sınıfları.

Adaptör:

1. İlişkisiz iki arabirimin farklı nesneler üzerinde birlikte çalışmasına ve muhtemelen aynı rolü oynamasına izin verir.
2. Orijinal arayüzü değiştirir .

örneğin java.io.InputStreamReader(a InputStreamdöndürür Reader)

Köprü:

1. Hem soyutlamaların hem de uygulamaların bağımsız olarak değişmesine izin verir .
2. Kompozisyon kalıtım üzerine kullanır .

Örn java.util. Listtarafından uygulandıArrayList .

Önemli notlar:

1. Adaptör , konusuna farklı bir arayüz sağlar. Proxy aynı arabirimi sağlar. Dekoratör gelişmiş bir arayüz sağlar.
2. Adaptör bir nesnenin arayüzünü değiştirir, Dekoratör bir nesnenin sorumluluklarını geliştirir.
3. Dekoratör ve Proxy'nin farklı amaçları vardır, ancak benzer yapıları vardır
4. Adaptör işleri tasarlandıktan sonra çalışır hale getirir; Bridge onları daha önce çalıştırır.
5. Köprü , soyutlamanın ve uygulamanın bağımsız olarak değişmesini sağlamak için ön tarafta tasarlanmıştır. İlişkisiz sınıfların birlikte çalışması için adaptör sonradan takılır
6. Dekoratör , alt sınıflama yapmadan nesnelere sorumluluk eklemenize izin vermek için tasarlanmıştır.

Çeşitli tasarım modellerinin örnekleriyle ilgili harika SE sorularına / makalelerine göz atın

Dekoratör Kalıbı Ne Zaman Kullanılmalı?

Köprü Deseni ne zaman kullanılır? Adaptör modelinden farkı nedir?

Proxy ve Dekoratör Kalıbı arasındaki farklar

Oldukça benzerler ve aralarındaki çizgiler oldukça gridir. Proxy Desenini ve Dekoratör Desenini okumanızı öneririmC2 wiki girişlerini .

Buradaki girişler ve tartışmalar oldukça geniştir ve ayrıca ilgili diğer makalelere de bağlanırlar. Bu arada, c2 wiki, farklı desenler arasındaki nüansları merak ederken mükemmel.

C2 girişlerini özetlemek için, bir dekoratör davranış eklediğini / değiştirdiğini söyleyebilirim, ancak bir proxy erişim kontrolü (tembel örnekleme, uzaktan erişim, güvenlik vb.) Ama dediğim gibi, aralarındaki çizgiler gri ve kolayca dekoratör olarak görülebilecek vekillere atıflar görüyorum.

Dört desenin tümü, iç nesnenin / sınıfın dış olanla sarılmasını içerir, bu nedenle yapısal olarak çok benzerler. Farkı amaç ile özetleyebilirim:

• vekil , içten dışa erişimi kapsar.
• Dekoratör , iç ile dış arasındaki davranışı değiştirir veya genişletir.
• adaptör arayüzü içten dışa dönüştürür.
• Köprü, değişmeyen davranış kısmını (dış) değişken veya platforma bağımlı kısımdan (iç) ayırır.

Ve iç ve dış nesneler arasındaki arayüz varyasyonu ile:

• içinde proxy arayüzleri aynıdır.
• içinde dekoratör arayüzleri aynıdır.
• içinde Adaptörü arayüzleri resmen farklı, ama aynı amaca hizmet.
• içinde Köprüsü arayüzleri kavramsal olarak farklıdır.

Bu, Head First Tasarım Desenlerinden alıntıdır

Tanımlar kitaba aittir. Örnekler bana ait.

Dekoratör - Arayüzü değiştirmez, ancak sorumluluk ekler. Bir araba arayüzünüz olduğunu varsayalım, bunu farklı otomobil modelleri için uyguladığınızda, bazı modeller için daha fazla sorumluluk eklemeniz gerekebilir . Sunroof, hava yastığı vb.

Bağdaştırıcı - Bir arabirimi diğerine dönüştürür. Bir araba arayüzünüz var ve cip gibi davranmasını istiyorsunuz. Böylece arabayı alır, değiştirir ve bir cip haline getirirsiniz. Gerçek bir cip olmadığı için. Ama bir cip gibi davranıyor.

Cephe - Bir arayüzü basitleştirir. Araba, uçak, gemi arayüzleriniz olduğunu varsayın. Aslında ihtiyacınız olan tek şey insanları bir yerden başka bir yere gönderen bir sınıftır. Cephenin hangi aracın kullanılacağına karar vermesini istiyorsunuz. Daha sonra tüm bu arayüz referanslarını 1 şemsiyenin altında toplar ve basit tutmaya karar vermesine / yetki vermesine izin verirsiniz.

Önce Baş: "Bir cephe sadece bir arayüzü basitleştirmekle kalmaz, bir istemciyi bir bileşen alt sisteminden ayırır. Cepheler ve adaptörler birden fazla sınıfı sarabilir, ancak bir cephenin amacı basitleştirmek, bir adaptörün arayüzü ise farklı bir şeye dönüştürmektir. "

Web servislerini kullanırken oldukça sık kullanıyorum. Proxy Deseni muhtemelen 'Wrapper Pattern' gibi daha pragmatik bir isimle yeniden adlandırılmalıdır.Ayrıca MS Excel Proxy'si olan bir kütüphanem de var.Gibi Excel'in arka plan ayrıntıları hakkında endişelenmenize gerek kalmadan Excel'i otomatikleştirmeyi çok kolay hale getiriyor sürümü yüklüyse (varsa).

Ayrıntılı uygulamadan bahsediyorum, Proxy ve Dekoratör, Adaptör, Cephe arasında bir fark buluyorum ... Bu desenlerin ortak uygulamasında, kapalı bir nesne tarafından sarılmış bir hedef nesne var. İstemci, hedef nesne yerine kapalı nesne kullanır. Ve hedef nesne, nesneyi kuşatma yöntemlerinin bazılarında önemli bir rol oynar.

Ancak, Proxy durumunda, çevreleyen nesne kendi başına bazı yöntemleri çalabilir, sadece istemci hedef nesnenin yer alması gereken bazı yöntemleri çağırdığında hedef nesneyi başlatır. Bu tembel başlatmadır. Diğer kalıplar söz konusu olduğunda, çevreleyen nesne sanal olarak hedef nesneye dayanır. Böylece hedef nesne her zaman yapıcılar / ayarlayıcılar içindeki nesneyle birlikte başlatılır.

Başka bir şey, bir proxy tam olarak bir hedefin yaptığı şeyi yaparken, diğer desenler hedeflemek için daha fazla işlevsellik ekler.

Bill Karwing cevabına örnek eklemek istiyorum (ki bu harika bir btw.) Ayrıca, uygulamanın eksik olduğunu düşündüğüm bazı önemli farklılıkları da ekliyorum.

Alıntı yapılan parçalar [ https://stackoverflow.com/a/350471/1984346] (Bill Karwing)

Proxy, Dekoratör, Bağdaştırıcı ve Köprü, bir sınıfın "kaydırılması" ndaki çeşitlemelerdir. Ancak kullanımları farklıdır.

• Proxy , bir nesneyi tembel olarak başlatmak veya uzak bir hizmeti çağırdığınızı gizlemek veya nesneye erişimi kontrol etmek istediğinizde kullanılabilir.

Vekil olan ProxyClass ve ObjectClass aynı arabirimi uygulamalıdır, böylece birbirlerinin yerine kullanılabilirler

Örnek - proxy pahalı nesne

class ProxyHumanGenome implements GenomeInterface  {
    private $humanGenome = NULL; 

    // humanGenome class is not instantiated at construct time
    function __construct() {
    }

    function getGenomeCount() {
        if (NULL == $this->humanGenome) {
            $this->instantiateGenomeClass(); 
        }
        return $this->humanGenome->getGenomeCount();
    }
} 
class HumanGenome implement GenomeInterface { ... }

• Dekoratöre "Akıllı Proxy" de denir. Bu, bir nesneye işlevsellik eklemek istediğinizde kullanılır, ancak nesnenin türünü genişleterek kullanılmaz. Bu, çalışma zamanında bunu yapmanızı sağlar.

DecoratorClass, ObjectClass'ın genişletilmiş arayüzünü uygulamalıdır (uygulayabilir). Böylece ObjectClass, DecoratorClass ile değiştirilebilir, ancak tam tersi olamaz.

Örnek - ekleme işlevi ekleme

class DecoratorHumanGenome implements CheckGenomeInterface  {

    // ... same code as previous example

    // added functionality
    public function isComplete() {
        $this->humanGenome->getCount >= 21000
    }
}

interface CheckGenomeInterface extends GenomeInterface {

    public function isComplete();

}

class HumanGenome implement GenomeInterface { ... }

• Bağdaştırıcı , soyut bir arabiriminiz olduğunda kullanılır ve bu arabirimi benzer işlevsel rolü olan, ancak farklı bir arabirime sahip başka bir nesneye eşlemek istediğinizde.

İmplentasyon farklılıkları Proxy, Dekoratör, Adaptör

Adaptör, konusuna farklı bir arayüz sağlar. Proxy aynı arabirimi sağlar. Dekoratör gelişmiş bir arayüz sağlar.

• Bridge , Bağdaştırıcıya çok benzer, ancak hem soyut arabirimi hem de temeldeki uygulamayı tanımladığınızda Bridge olarak adlandırırız. Yani bazı eski veya üçüncü taraf kodlarına adapte olmuyorsunuz, tüm kodun tasarımcısı sizsiniz, ancak farklı uygulamaları değiştirebilmeniz gerekiyor.

• Cephe , bir veya daha fazla sınıftan oluşan bir alt sistem için daha yüksek düzeyli (okuma: daha basit) bir arabirimdir. Diyelim ki birden fazla nesnenin temsil edilmesini gerektiren karmaşık bir kavramınız var. Hangi nesne kümesinde değişiklik yapmak kafa karıştırıcıdır, çünkü hangi nesnenin çağırmanız gereken yönteme sahip olduğunu her zaman bilmezsiniz. Nesnelerin toplanmasında yapabileceğiniz tüm karmaşık işlemler için üst düzey yöntemler sağlayan bir Cephe yazma zamanı. Örnek: gibi yöntemlerle bir okul bölümü için Alan Modeli, countStudents(), reportAttendance(), assignSubstituteTeacher(), vb.

Bu yanıttaki bilgilerin çoğu, tasarım desenleri için mükemmel bir kaynak olarak önerdiğim https://sourcemaking.com/design_patterns adresinden alınmıştır .

Kodun (başkalarının cevaplarını da tamamlamak için) net bir fikir vereceğine inanıyorum. Lütfen aşağıya bakın, (Bir sınıfın uyguladığı ve saran türlere odaklanın)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace TestConsole
{
    class Program
    {
        static void Main(string[] args)
        {
            /* Proxy */

            Console.WriteLine(Environment.NewLine);
            Console.WriteLine("PROXY");
            Console.WriteLine(Environment.NewLine);

            //instead of creating here create using a factory method, the facory method will return the proxy
            IReal realProxy = new RealProxy();
            Console.WriteLine("calling do work with the proxy object ");
            realProxy.DoWork();

            Console.WriteLine(Environment.NewLine);
            Console.WriteLine("ADAPTER");
            Console.WriteLine(Environment.NewLine);

            /*Adapter*/
            IInHand objectIHave = new InHand();
            Api myApi = new Api();
            //myApi.SomeApi(objectIHave); /*I cant do this, use a adapter then */
            IActual myAdaptedObject = new ActualAdapterForInHand(objectIHave);
            Console.WriteLine("calling api with  my adapted obj");
            myApi.SomeApi(myAdaptedObject);


            Console.WriteLine(Environment.NewLine);
            Console.WriteLine("DECORATOR");
            Console.WriteLine(Environment.NewLine);

            /*Decorator*/
            IReady maleReady = new Male();
            Console.WriteLine("now male is going to get ready himself");
            maleReady.GetReady();

            Console.WriteLine(Environment.NewLine);

            IReady femaleReady = new Female();
            Console.WriteLine("now female is going to get ready her self");
            femaleReady.GetReady();

            Console.WriteLine(Environment.NewLine);

            IReady maleReadyByBeautician = new Beautician(maleReady);
            Console.WriteLine("now male is going to get ready by beautician");
            maleReadyByBeautician.GetReady();

            Console.WriteLine(Environment.NewLine);

            IReady femaleReadyByBeautician = new Beautician(femaleReady);
            Console.WriteLine("now female is going to get ready by beautician");
            femaleReadyByBeautician.GetReady();

            Console.WriteLine(Environment.NewLine);

            Console.ReadLine();


        }
    }

    /*Proxy*/

    public interface IReal
    {
        void DoWork();
    }

    public class Real : IReal
    {
        public void DoWork()
        {
            Console.WriteLine("real is doing work ");
        }
    }


    public class RealProxy : IReal
    {
        IReal real = new Real();

        public void DoWork()
        {
            real.DoWork();
        }
    }

    /*Adapter*/

    public interface IActual
    {
        void DoWork();
    }

    public class Api
    {
        public void SomeApi(IActual actual)
        {
            actual.DoWork();
        }
    }

    public interface IInHand
    {
        void DoWorkDifferently();
    }

    public class InHand : IInHand
    {
        public void DoWorkDifferently()
        {
            Console.WriteLine("doing work slightly different ");
        }
    }

    public class ActualAdapterForInHand : IActual
    {
        IInHand hand = null;

        public ActualAdapterForInHand()
        {
            hand = new InHand();
        }

        public ActualAdapterForInHand(IInHand hnd)
        {
            hand = hnd;
        }

        public void DoWork()
        {
            hand.DoWorkDifferently();
        }
    }

    /*Decorator*/

    public interface IReady
    {
        void GetReady();
    }

    public class Male : IReady
    {
        public void GetReady()
        {
            Console.WriteLine("Taking bath.. ");
            Console.WriteLine("Dress up....");
        }
    }

    public class Female : IReady
    {
        public void GetReady()
        {
            Console.WriteLine("Taking bath.. ");
            Console.WriteLine("Dress up....");
            Console.WriteLine("Make up....");
        }
    }

    //this is a decorator
    public class Beautician : IReady
    {
        IReady ready = null;

        public Beautician(IReady rdy)
        {
            ready = rdy;
        }

        public void GetReady()
        {
            ready.GetReady();
            Console.WriteLine("Style hair ");

            if (ready is Female)
            {
                for (int i = 1; i <= 10; i++)
                {
                    Console.WriteLine("doing ready process " + i);
                }

            }
        }
    }

}

Tasarım örüntüsü matematik değil, sanat ve yazılım mühendisliğinin birleşimidir. Proxy, köprü vb. Kullanmak zorunda olduğunuz bu gereksinim için hiçbir şey yoktur. Bir tasarım sorunu bekliyorsanız kullanın. Deneyime dayanarak, hangi modeli kullanacağınızı belirli bir problem için öğreneceksiniz. Sağlam tasarım ilkelerinde iyiyseniz, desen olduğunu bilmeden tasarım desenini uygularsınız. Genel örnek staterji ve fabrika kalıplarıdır

Bu nedenle katı desighn ilkelerine, temiz kodlama ilkelerine ve ttd