Şablon yöntemi ile strateji modelleri arasındaki fark nedir?


161

Birisi bana şablon yöntem modeli ile strateji modeli arasındaki farkın ne olduğunu açıklayabilir mi?

Görebildiğim kadarıyla% 99 aynıdır - tek fark, şablon yöntemi deseninin temel sınıf olarak soyut bir sınıfa sahip olması, strateji sınıfı ise her somut strateji sınıfı tarafından uygulanan bir arayüz kullanmasıdır.

Ancak, müşteri söz konusu olduğunda, aynı şekilde tüketilir - bu doğru mu?


2

12
Gob00st ile bağlantılı soru strateji ve köprü arasındaki farktır. Bu sorunun cevabı hiç de değil.
bluekeys

Yanıtlar:


135

İkisi arasındaki temel fark, beton algoritmasının seçilmesidir.

İle Şablon yöntemi desen şuna olur derleme zamanında tarafından sınıflara şablonu. Her alt sınıf, şablonun soyut yöntemlerini uygulayarak farklı bir somut algoritma sağlar. Bir istemci, şablonun harici arabiriminin yöntemlerini çağırdığında, şablon algoritmayı çağırmak için gerektiği gibi soyut yöntemlerini (dahili arabirimi) çağırır.

class ConcreteAlgorithm : AbstractTemplate
{
    void DoAlgorithm(int datum) {...}
}

class AbstractTemplate
{
    void run(int datum) { DoAlgorithm(datum); }

    virtual void DoAlgorithm() = 0; // abstract
}

Buna karşılık, Strateji desen bir algoritma seçilecek sağlayan çalışma zamanı tarafından çevreleme . Somut algoritmalar, stratejiye yapıcısına veya bir ayarlayıcı yöntemine parametre olarak iletilen ayrı sınıflar veya işlevler tarafından uygulanır. Bu parametre için seçilen algoritma, programın durumuna veya girişlerine bağlı olarak dinamik olarak değişebilir.

class ConcreteAlgorithm : IAlgorithm
{
    void DoAlgorithm(int datum) {...}
}

class Strategy
{
    Strategy(IAlgorithm algo) {...}

    void run(int datum) { this->algo.DoAlgorithm(datum); }
}

Özetle:

  • Şablon yöntemi düzeni: alt sınıfa göre derleme zamanı algoritması seçimi
  • Strateji kalıbı: kapsama göre çalışma zamanı algoritması seçimi

47
Her iki desen de kullanılan algoritmanın çalışma zamanı seçimini destekler (Şablon Yöntemi için böyle bir şey yaparsınız if (config.useAlgoA) impl = new AlgoA() else impl = new AlgoB()), bu nedenle bu cevap yanlıştır.
Borek Bernard

13
Elbette bunu yapabilirsiniz, ancak Şablon Şablonunu kullanmıyorsunuzdur. Aslında, Strateji örneğini oluşturan kod neredeyse tam olarak bu şekilde görünecektir!
thehouse

21
-1, sanırım bu cevap (tamamen yanlış olmasa da), gerçek farklılıkların olduğu noktayı kaçırıyor. @ tvanfosson'un cevabı çok daha iyi.
Doc Brown

1
@Karoly Nyisztor İkisi de "davranışın yerine" geçebilir ve "uzatma noktaları sağlayabilir." Bir şey ister bir davranış ister uzantı olsun, belirli bir deseni nereye uyguladığınızın bağlamına bağlıdır. Şablon yöntemi modelinin her alt sınıfını da "strateji" olarak adlandırabilir veya strateji modelindeki her strateji sınıfını "uzantı" olarak adlandırabilirsiniz. Gerçek şu ki, bu cevabın bahsettiği fark hariç, aynı şeyi yapıyorlar. İşte bu doğru cevap.
Andy

1
Somut bir algoritma her iki desen için de aynı şekilde seçilir. Seçim, new ConcreteAlgorithm1()karşı çağrılarak yapılır new ConcreteAlgorithm2(). Açıkçası seçim çalışma zamanında gerçekleşir (derleme zamanında bir algoritma seçimi yapmak zor kodlama anlamına gelir). İkisi arasındaki temel fark, somut algoritmanın nasıl uygulandığıdır. Bir alt sınıf olarak mı yoksa ayrı bir arayüz olarak mı uygulanıyor? İlki bir Şablon. İkincisi bir stratejidir. Fark, GoF kitabının ortak bir teması olan kompozisyon ve miras olarak özetlenebilir.
jaco0646

138

Şablon deseni, belirli bir işlemin diğer değişken ilkel davranışlar açısından tanımlanabilecek bazı değişmez davranış (lar) ı olduğunda kullanılır. Soyut sınıf değişmez davranış (lar) ı tanımlarken, uygulayıcı sınıflar bağımlı yöntemleri tanımlamıştır.

Bir stratejide, davranış uygulamaları bağımsızdır - her uygulayıcı sınıf davranışı tanımlar ve aralarında paylaşılan kod yoktur. Her ikisi de davranış kalıplarıdır ve bu nedenle müşteriler tarafından aynı şekilde tüketilir. Tipik olarak stratejilerin tek bir genel yöntemi vardır - execute()yöntem, oysa şablonlar bir dizi genel yöntem ve alt sınıfların uygulaması gereken bir dizi destekleyici özel ilkel tanımlayabilir.

İki desen birlikte kolayca kullanılabilir. Birkaç uygulamanın şablon kalıbı kullanılarak uygulanan bir strateji ailesine ait olduğu bir strateji kalıbınız olabilir.


Bu bana doğru geliyor, ancak WikiPedia neden "strateji modelinin çalışma zamanında bir algoritmanın davranışı için seçildiğini" belirtiyor? Aynı şablon yöntemi gibi derleme zamanında algoritma davranışını seçmek için de kullanılabilir? Bir şey mi kaçırıyorum?
BornToCode

2
@BornToCode Ne hakkında konuştuklarını çalışma zamanında belirli bir strateji seçmek olduğunu varsayacağım. Örneğin, bir denklemin köklerini sayısal olarak bulmanın birkaç yolu vardır. Problem alanına veya verilere bağlı olarak, Newton-Raphson, Euler veya denklemi çözmek için başka bir strateji seçebilirsiniz. Bunların her biri bir stratejidir. Denklemi çözmenin bir parçası olduğu daha büyük algoritma, sorunun bazı kalitesine göre kullanılacak stratejiyi seçer.
tvanfosson

Evet, ama sadece bu durumlar için strateji modelinin kullanılması gerektiği gibi değil mi? Demek istediğim sadece derleme zamanında algoritmanın davranışını seçmem gerekiyorsa, hala strateji modelini kullanmalı mıyım yoksa bu şekilde mi kullanılmayacaktı?
BornToCode

1
@BornToCode Seçim dinamik olduğunda bir stratejinin en yararlı olduğunu söyleyebilirim. Şablon temel olarak bilinen farklı davranışlar oluşturmanın bir yoludur. Hangi şablonlaştırılmış davranışın kullanılacağını seçmek için bazı strateji (strateji modeli olmasa da) kullanırsınız. Örneğin, ürün devralma - temel bir ürün yaratacak, farklı ürünler için özellikler ekleyeceksiniz. Hangi ürün türünün (sınıf) somutlaştırılacağını seçmek, hangi tablolardan / görünümlerden yüklendiğine bağlı olabilir. Strateji modeli orada gerçekten devreye girmiyor.
tvanfosson

2
@BornToCode bu bir / veya şey değil, evet-ve. Deseni uygun olan yere uygulayın, desenleri kullanışlı olduğu yerde birleştirin.
tvanfosson


24

Muhtemelen şablon yöntemi kalıbı demek istediniz. Haklısın, çok benzer ihtiyaçlara hizmet ediyorlar. Alt sınıfların bazı ayrıntıları değiştirmek için bu adımları geçersiz kıldığı bir "şablon" algoritması olduğu durumlarda şablon yöntemini kullanmanın daha iyi olduğunu söyleyebilirim. Strateji durumunda, bir arayüz oluşturmanız gerekir ve devralma yerine yetki devri kullanırsınız. Biraz daha güçlü bir model olduğunu ve belki de DIP bağımlılık tersine çevirme ilkelerine göre daha iyi olduğunu söyleyebilirim. Daha güçlüdür, çünkü açıkça yeni bir strateji soyutlaması tanımlarsınız - şablon yöntemi için geçerli olmayan bir şey yapmanın bir yolu. Yani, bu soyutlama mantıklıysa - kullanın. Bununla birlikte, şablon yöntemini kullanmak basit durumlarda daha basit tasarımlar verebilir, bu da önemlidir. Hangi kelimelerin daha uygun olduğunu düşünün: şablon algoritmanız var mı? Ya da burada strateji soyutlamanız olan anahtar şey - bir şey yapmanın yeni yolu

Şablon yöntemi örneği:

Application.main()
{
Init();
Run();
Done();
}

Burada uygulamadan miras alırsınız ve init, run ve done üzerinde tam olarak ne yapılacağını yerine koyabilirsiniz.

Bir strateji örneği:

array.sort (IComparer<T> comparer)

Burada, karşılaştırıcı yazarken bir diziden miras almazsınız. Dizi karşılaştırma algoritmasını bir karşılaştırıcıya devreder.


3
Bence bu harika bir cevap
Calanus

23

Strateji ve Şablon Yöntemi Arasındaki Fark Model Paterni ve Şablon Yöntemi


benzerlikler

Strateji ve Şablon yöntem kalıpları arasında çok fazla benzerlik vardır. Hem Strateji hem de Şablon yöntem kalıpları Açık-Kapalı Prensibi'ni karşılamak ve yazılım modülünü kodunu değiştirmeden genişletmeyi kolaylaştırmak için kullanılabilir. Her iki örüntü de, genel işlevselliğin bu işlevin ayrıntılı uygulamasından ayrılmasını temsil eder. Bununla birlikte, sundukları ayrıntı düzeyi açısından biraz farklılık gösterirler.


farklılıklar

İşte bu iki modeli incelerken gözlemlediğim bazı farklar:

  1. Strateji'de, müşteri ve strateji arasındaki bağlantı daha gevşekken, Şablon Yöntemi'nde iki modül daha sıkı bir şekilde birleştirilir.
  2. Stratejide, duruma bağlı olarak soyut sınıf da kullanılabilmekle birlikte çoğunlukla bir arayüz kullanılır ve beton sınıfı kullanılmazken, Template yönteminde çoğunlukla soyut sınıf veya beton sınıfı kullanılırken arayüz kullanılmaz.
  3. Strateji modelinde, genellikle sınıfın tüm davranışı bir arabirim olarak temsil edilirken, diğer yandan, kod çoğaltımını azaltmak için Şablon yöntemi kullanılır ve taban plakası kodu temel çerçevede veya soyut sınıfta tanımlanır. Şablon Yöntemi'nde, varsayılan uygulamaya sahip somut bir sınıf bile olabilir.
  4. Basit bir deyişle, Strateji modelindeki tüm stratejiyi (algoritmayı) değiştirebilirsiniz, ancak Şablon yönteminde yalnızca bazı şeyler değişir (algoritmanın parçaları) ve geri kalanı değişmeden kalır. Şablon Yöntemi'nde, değişmez adımlar soyut bir temel sınıfta uygulanırken, varyant adımlarına varsayılan bir uygulama verilir veya hiç uygulama verilmez. Şablon yönteminde, bileşen tasarımcısı bir algoritmanın gerekli adımlarını ve adımların sırasını zorunlu kılar, ancak bileşen istemcisinin bu adımların bir kısmını genişletmesine veya değiştirmesine izin verir.

Görüntü ısırılmış blogdan alınmıştır .


19

Toplamaya karşı kalıtım (bir-has'e karşı-a). Aynı hedefe ulaşmak için iki yol var.

Bu soru, seçenekler arasındaki bazı ödünleşimleri göstermektedir: Miras ve Toplama


11

Her ikisi de çok benzer ve her ikisi de istemci kodu tarafından benzer şekilde kullanılır. Yukarıdaki en popüler cevabın aksine, her ikisi de çalışma zamanında algoritma seçimine izin verir .

İkisi arasındaki fark, strateji paterninin farklı uygulamaların istenen sonuca ulaşmanın tamamen farklı yollarını kullanmasına izin vermesine rağmen, şablon yöntemi paterninin , sonucu elde etmek için kullanılan kapsayıcı bir algoritmayı ("şablon" yöntemi) belirlemesi - - belirli uygulamalara (alt sınıflara) kalan tek seçenek, söz konusu şablon yönteminin belirli detaylarıdır. Bu, şablon yönteminin, kendisi soyut olmayan ve alt sınıflar tarafından geçersiz kılınmayan şablon yönteminin aksine, alt sınıflar tarafından geçersiz kılınan (yani uygulanan) bir veya daha fazla soyut yönteme çağrı yapmasıyla yapılır. .

İstemci kodu, tıpkı Strateji Kalıbı kullanılırken olduğu gibi çalışma zamanında belirlenebilen somut alt sınıflardan birinin örneğine işaret eden soyut sınıf tipinin bir referans / işaretçisi kullanarak şablon yöntemine bir çağrı yapar.


9

Şablon Yöntemi:

  1. Kalıtım üzerine kuruludur
  2. Alt sınıflar tarafından değiştirilemeyen algoritma iskeletini tanımlar. Alt sınıflarda yalnızca belirli işlemler geçersiz kılınabilir
  3. Üst sınıf algoritmayı tamamen kontrol eder ve yalnızca belirli adımları somut sınıflara ayırır
  4. Ciltleme derleme zamanında yapılır

Şablon_ yöntem yapısı:

resim açıklamasını buraya girin

Strateji:

  1. Delegasyona / kompozisyona dayanıyor
  2. Yöntem davranışını değiştirerek nesnenin bağırsaklarını değiştirir
  3. Algoritmalar ailesi arasında geçiş yapmak için kullanılır
  4. Çalışma zamanında bir algoritmayı diğer algoritma ile tamamen değiştirerek çalışma zamanında nesnenin davranışını değiştirir
  5. Bağlama çalışma zamanında yapılır

Strateji yapısı:

resim açıklamasını buraya girin

Daha iyi anlamak için Şablon yöntemi ve Strateji makalelerine göz atın .

İlgili Mesajlar:

JDK'da şablon tasarım deseni, sırayla yürütülecek yöntem kümesini tanımlayan bir yöntem bulamadı

Strateji Modelinin Gerçek Dünya Örneği


3

Hayır, mutlaka aynı şekilde tüketilmezler. "Şablon yöntemi" düzeni, gelecekteki uygulayıcılara "rehberlik" sağlamanın bir yoludur. Onlara "Tüm Kişi nesnelerinin bir Sosyal Güvenlik Numarası olması gerekir" diyorsunuz (bu önemsiz bir örnek, ancak fikri doğru bir şekilde karşılıyor).

Strateji modeli, birden fazla olası uygulamanın açılıp kapatılmasını sağlar. (Genellikle) kalıtım yoluyla değil, arayan kişinin istenen uygulamadan geçmesine izin vererek uygulanır. Bir örnek, bir ShippingCalculator'a vergileri hesaplamanın birkaç farklı yolundan (bir NoSalesTax uygulaması ve belki de PercentBasedSalesTax uygulaması) sağlanmasına izin vermek olabilir.

Yani, bazen, müşteri nesneye hangi stratejiyi kullanacağını söyler. De olduğu gibi

myShippingCalculator.CalculateTaxes(myCaliforniaSalesTaxImpl);

Ancak istemci bunu Şablon Yöntemi'ne dayalı bir nesne için asla yapmaz. Aslında, istemci bir nesnenin Şablon Yöntemine dayandığını bile bilmiyor olabilir. Şablon Yöntemi modelindeki bu soyut yöntemler korunabilir, bu durumda istemci var olduğunu bile bilemez.


3

Bu makaleyi okumanızı öneririm . Gerçek bir vaka örneğindeki farklılıkları açıklar.

Makaleden alıntı

" Görüldüğü gibi, uygulama sınıfları da şablon yöntemi sınıfına bağlıdır. Bu bağımlılık, algoritmanın bazı adımlarını değiştirmek istiyorsa, şablon yöntemini değiştirmeye neden olur. Diğer tarafta strateji algoritmayı tamamen içine alır. Bu nedenle, herhangi bir değişiklik gelirse önceden yazılmış sınıflar için kodun değiştirilmesi gerekir.Bu sınıfları tasarlamak için strateji seçmek için birincil nedeni oldu.

Şablon yönteminin bir özelliği, şablon yönteminin algoritmayı kontrol etmesidir. Bu başka bir durumda iyi bir şey olabilir ama benim sorunumda bu dersleri tasarlamamı kısıtlıyordu. Diğer tarafta strateji, tamamen farklı dönüşüm yöntemleri eklememi sağlayan bir algoritmanın adımlarını kontrol etmiyor. Dolayısıyla benim durum stratejim uygulama için bana yardımcı oluyor.

Stratejinin bir dezavantajı, çok fazla kod yedekliliği ve daha az kod paylaşımı olmasıdır. Bu makalenin sunulan örnekte açık olduğu gibi, aynı kodu dört sınıfta tekrar tekrar tekrarlamak zorunda. Bu nedenle bakımı zordur, çünkü sistemimizin herkes için ortak olan adım 4 gibi uygulaması değiştirilirse, bunu tüm 5 sınıfta güncellemem gerekecek. Diğer tarafta, şablon yönteminde yalnızca üst sınıfı değiştirebilirim ve değişiklikler alt sınıflara yansıtılır. Bu nedenle şablon yöntemi, sınıflar arasında çok düşük miktarda yedeklilik ve yüksek miktarda kod paylaşımı sağlar.

Strateji ayrıca algoritmanın çalışma zamanında değiştirilmesine izin verir. Şablon yönteminde, nesnenin yeniden başlatılması gerekecektir. Stratejinin bu özelliği büyük miktarda esneklik sağlar. Tasarım açısından, kalıtım yerine kompozisyonu tercih etmek gerekir. Bu nedenle strateji modelini kullanmak da kalkınma için birincil tercih oldu. "


2

Şablon kalıbı, Strateji kalıbına benzer. Bu iki örüntü kapsam ve metodolojide farklılık gösterir.

Strateji, arayanların farklı vergi türlerinin nasıl hesaplanacağı gibi bir algoritmanın tamamını değiştirmesine izin verirken, Şablon Yöntemi bir algoritmadaki adımları değiştirmek için kullanılır. Bu nedenle, Strateji daha kaba tanelidir. Şablon, işlemler sırasında daha ayrıntılı denetimlere izin verir ve yine de bu ayrıntıların uygulamalarının değişmesine izin verir.

Diğer önemli fark, Şablon Yöntemi miras kullanırken Strateji'nin temsilci seçme kullanmasıdır. Strateji'de algoritma, öznenin başvuruda bulunacağı başka bir xxxStrategy sınıfına devredilir, ancak Şablonla tabanı alt sınıflar ve değişiklikler yapmak için yöntemleri geçersiz kılarsınız.

dan http://cyruscrypt.blogspot.com/2005/07/template-vs-strategy-patterns.html


2

Strateji modelinde alt sınıflar şovu çalıştırıyor ve algoritmayı kontrol ediyorlar. Burada kod alt sınıflar arasında çoğaltılır. Algoritmanın bilgisi ve nasıl uygulanacağı birçok sınıfa dağıtılır.

Şablon modelinde temel sınıf algoritmaya sahiptir. Alt sınıflar arasında yeniden kullanımı maksimuma çıkarır. Algoritma tek bir yerde bulunduğundan, temel sınıf onu korur.


2

Strateji Tasarım Deseni

  • Kompozisyonu destekler.
  • Çalışma zamanında nesnenin davranışını değiştirme esnekliği sağlar.
  • İstemci kodu ile çözüm / algoritma kodu arasında daha az bağlantı.

Şablon Yöntemi Tasarım Deseni

  • Kompozisyona göre kalıtımı destekler
  • Temel sınıfınızda algoritmayı tanımlayın. Alt sınıflarda bireysel algoritma parçaları özelleştirilebilir.

1

Şablon Deseni:

Şablon yöntemi, alt sınıfların, temel sınıfta tanımlanan algoritmanın ana yapısını ve adımlarını değiştirmeden algoritmanın belirli adımlarını yeniden tanımlamasına izin vermekle ilgilidir. Şablon kalıbı genellikle kalıtım kullanır, bu nedenle alt sınıfın gerekirse geçersiz kılmayı seçebileceği temel sınıfta genel bir algoritma uygulaması sağlanabilir.

public abstract class RobotTemplate {
    /* This method can be overridden by a subclass if required */
    public void start() {
        System.out.println("Starting....");
    }

    /* This method can be overridden by a subclass if required */
    public void getParts() {
        System.out.println("Getting parts....");
    }

    /* This method can be overridden by a subclass if required */
    public void assemble() {
        System.out.println("Assembling....");
    }

    /* This method can be overridden by a subclass if required */
    public void test() {
        System.out.println("Testing....");
    }

    /* This method can be overridden by a subclass if required */
    public void stop() {
        System.out.println("Stopping....");
    }

    /*
     * Template algorithm method made up of multiple steps, whose structure and
     * order of steps will not be changed by subclasses.
     */
    public final void go() {
        start();
        getParts();
        assemble();
        test();
        stop();
    }
}


/* Concrete subclass overrides template step methods as required for its use */
public class CookieRobot extends RobotTemplate {
    private String name;

    public CookieRobot(String n) {
        name = n;
    }

    @Override
    public void getParts() {
        System.out.println("Getting a flour and sugar....");
    }

    @Override
    public void assemble() {
        System.out.println("Baking a cookie....");
    }

    @Override
    public void test() {
        System.out.println("Crunching a cookie....");
    }

    public String getName() {
        return name;
    }
}

Yukarıdaki kodda, go () algoritması adımlarının her zaman aynı olacağına dikkat edin, ancak alt sınıflar belirli bir adımı gerçekleştirmek için farklı bir tarif tanımlayabilir.

Strateji Düzeni:

Strateji modeli, istemcinin çalışma zamanında somut algoritmalar uygulamasını seçmesine izin vermekle ilgilidir. Tüm algoritmalar izole ve bağımsızdır, ancak ortak bir arayüz uygular ve algoritma içindeki belirli adımları tanımlama fikri yoktur.

/**
 * This Strategy interface is implemented by all concrete objects representing an
 * algorithm(strategy), which lets us define a family of algorithms.
 */
public interface Logging {
    void write(String message);
}

/**
 * Concrete strategy class representing a particular algorithm.
 */
public class ConsoleLogging implements Logging {

    @Override
    public void write(String message) {
        System.out.println(message); 
    }

}

/**
 * Concrete strategy class representing a particular algorithm.
 */
public class FileLogging implements Logging {

    private final File toWrite;

    public FileLogging(final File toWrite) {
        this.toWrite = toWrite;
    }

    @Override
    public void write(String message) {
        try {
            final FileWriter fos = new FileWriter(toWrite);
            fos.write(message);
            fos.close();
        } catch (IOException e) {
            System.out.println(e);
        }
    }

}

Tam kaynak kodu için github veri havuzuma göz atın .


0

Strateji, Soyut Sınıf olarak bir Arayüz ve şablon yöntemi olarak ortaya çıkar. Bu genellikle çerçevelerde çok kullanılır. Örneğin Spring framework'ün MessageSource sınıfı, mesajları çözmek için bir strateji arabirimidir. Müşteri, bu arayüzün özel uygulamasını (stratejisini) kullanır.

Ve aynı arabirimin soyut uygulaması olan ve iletileri çözme konusunda ortak bir uygulamaya sahip olan ve resolcode () soyut yöntemini ortaya koyan AbstractMessageSource, alt sınıfların bunları kendi yollarıyla uygulayabilmesini sağlar. AbstractMessageSource, şablon yöntemine bir örnektir.

http://docs.spring.io/spring/docs/4.1.7.RELEASE/javadoc-api/org/springframework/context/support/AbstractMessageSource.html


0

Bu tasarım modelinin şablon yönteminde, kapsayıcı algoritmanın hala takip edildiğinden emin olmak için farklı davranışlara izin vermek için bir veya daha fazla algoritma adımı alt sınıflar tarafından geçersiz kılınabilir (Wiki).

Desen adı Şablon yöntemi ne olduğu anlamına gelir. CalculateSomething () yöntemimiz olduğunu ve bu yöntemi şablonlamak istediğimizi varsayalım. Bu yöntem temel sınıfta sanal olmayan bir yöntem olarak ilan edilecektir. Diyelim ki yöntem böyle görünüyor.

CalculateSomething(){
    int i = 0;
    i = Step1(i);
    i++;
    if (i> 10) i = 5;
    i = Step2(i);
    return i;

} Adım1 ve Adım2 yönteminin uygulanması türetilmiş sınıflar tarafından verilebilir.

Strateji Deseni'nde, taban tarafından sağlanan bir uygulama yoktur (Bu, tabanın gerçekten sınıf diyagramında bir arayüz olmasının sebebidir)

Klasik örnek sıralamadır. Nesnelerin sıralanmasına bağlı olarak uygun algoritma sınıfı (birleştirme, kabarcık, hızlı vb.) Oluşturulur ve tüm algoritma her sınıfta kapsüllenir.

Şimdi sıralamayı şablon yöntemi olarak uygulayabilir miyiz? Kesinlikle yapabilirsiniz, ancak soyutlanacak ve temel uygulamaya yerleştirilecek çok fazla / herhangi bir ortaklık bulamazsınız. Böylece şablon yöntemi modelinin amacını yener.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.