Strateji modelinde bağlam sınıfı

10

Strateji modelini anlamaya çalışıyorum ve kendime şu soruyu soruyorum: bağlam sınıfı olmalı mı yoksa kalıbın amacından ödün vermeden dışarıda bırakabilir miyim?

Ben farklı dosya türlerini okumak için bir tür anahtar gerekli izlenim altındaydı ama sadece bir şey kesmek ve daha sonra yeniden düzenleme ile uğraşmak istemiyordu (tabii ki, her zaman her zaman kod yeniden düzenlenebilir olabilir ama fikir oldu: deneyin tasarımda mümkün olduğunca akıllı olmak ...):

resim açıklamasını buraya girin

Wikimedia'dan alınan görüntü

Müşteri doğrudan Strateji arayüzüne devredebilir mi veya bağlam sınıfı hakkında az önce özlediğim bir şey var mı?

interface Reader {
    // read information from file and fill data list field of Client
    readFile();
}
class ExcelReader implements Reader{ /* */ }
class PdfReader implements Reader{ /* */}

class Client{
    // strategic choice
    Reader r;

    // data list field
    List<Data> data;

    // Client Constructor
    public Client(){
        if(<file ends in .xls>)
            r = new ExcelReader();
        else
            r = new PdfReader();
        r.readFile();
    }
}

Yani, yukarıda tasvir edilen bağlam sınıfı eksiktir. Kod strateji modeline uyuyor mu?

design-patterns strategy

— Panny
kaynak

1

Bir başka ilginç / önemli nokta olarak, işlevsel dillerdeki tür sınıfları kavramının en.wikipedia.org/wiki/Kind_(type_theory türleriyle strateji örüntüsü "olduğuna dikkatinizi çekmek isterim ). Her ikisi de sadece geçici polimorfizm için bir uygulama mekanizmasıdır.

— AndreasScheinert

Bu (çok veya az) Java 8 Project Lambda ile ilişkili mi? Wikipedia makalesi bir kerede anlayamayacak kadar yoğun, ancak bunlar Java'nın (veya genel olarak programlamanın) gelecek özelliklerini verimli bir şekilde kullanmak için teorik arka planın bir parçasıysa, buna daha fazla zaman ayıracağım.

— panny

1

Çok uzak ama evet, tip sınıfların ihtiyacı olduğunu iddia ediyorum. Daha yüksek türleri destekleyen bir programlama dili. Scala ve Haskell için durum böyledir. Burada benim açımdan (ad hoc) polimorfizm farklı şekilde uygulandı ve geri adım atarsanız genel olarak polimorfizm hakkında bazı bilgiler edinebilirsiniz.

— AndreasScheinert

13

Örneğin, kod çağrısı readFileClient yapıcısının bir parçasıdır. Bu yöntem, aradığınız "bağlam" dır . Strateji modelinin kelimenin tam anlamıyla bir "bağlam sınıfına" ihtiyacı yoktur ve kodunuzun ilk sürümünde strateji nesnesi (sizin durumunuzdaki "Okuyucu") yalnızca yerel bir değişkente bulunabilir. Özellikle sadece bir "stratejik yöntem" ("readFile") çağrıldığında.

Bununla birlikte, kod tabanınız bir sürümden diğerine büyürse, daha fazla "stratejik" yöntem çağrılması pek olası değildir ve hangi stratejinin uygulanacağı ve "stratejik yöntemlerin" uygulanması farklı zamanlarda gerçekleşecektir. ve kodunuzun farklı yerlerinde. Böylece mantığı tek bir yerde tutmak için onları yeniden düzenlemeye başlarsınız. Bu, doğrudan sorunuzdaki şemaya benzeyen bir uygulamaya yönlendirecektir.

— Doc Brown
kaynak

5

Kesinlikle. Desenler sadece kılavuzdur. Yine de eldeki sorun için bunları doğru şekilde uyarlamanız ve uygulamanız gerekecektir. Şahsen, nadiren stratejinin çalışma zamanında belirlenmesine izin veriyorum; daha sık inşaatta belirtilir veya bir fabrikada döndürülür.

Yine de setStrategyözel olduğu ve enjeksiyonumun sadece gösterildiği gibi deseni kullandığını iddia edilebilir.

— Telastyn
kaynak

Bu tasvir edilen Context sınıfının kalıptan ödün vermeden bırakılabileceği anlamına mı geliyor? Müvekkilim sınıfı Veya başka bir deyişle, o ok olduğunu tasvir eder Sınıf?

— panny

6

@panny - Soruyu cevaplamaktan çekinmeyin, çünkü cevabın noktasını ve gerçekten de kalıpları kaçırdığınızı gösterir. Strateji modeli, bir arayüzün arkasında farklı somut uygulamalar sağlayarak davranışı değiştirmenize olanak tanır. Bu bir kavram , formül değil .

— Telastyn