Birinci sınıf işlevler Strateji modelinin yerine geçiyor mu?

Strateji tasarım deseni sık sık yoksun dilde birinci sınıf işlevleri için bir yedek olarak kabul edilir.

Örneğin, işlevselliği bir nesneye geçirmek istediğinizi varsayalım. Java'da, istenen davranışı kapsayan başka bir nesneyi nesneye iletmeniz gerekir. Ruby gibi bir dilde, işlevselliğin kendisini anonim bir işlev biçiminde geçirirsiniz.

Ancak bunu düşünüyordum ve belki de Strateji'nin basit bir anonim işlevden fazlasını sunduğuna karar verdim.

Bunun nedeni, bir nesnenin, yöntemin çalıştığı dönemden bağımsız olarak var olan durumu tutabilmesidir. Ancak anonim bir işlev, yalnızca işlevin yürütülmesi bittiğinde varolmayan durumu tutabilir.

Birinci sınıf işlevleri destekleyen nesne yönelimli bir dilde, strateji modelinin işlevleri kullanmaya göre herhangi bir avantajı var mı?

Dil işleve referansları desteklediğinde ( Java sürüm 8'den bu yana ), bunlar genellikle stratejiler için iyi bir alternatiftir, çünkü genellikle aynı şeyi daha az sözdizimi ile ifade ederler. Bununla birlikte, gerçek bir nesnenin yararlı olabileceği bazı durumlar vardır.

Bir Strateji arabiriminin birden çok yöntemi olabilir. RouteFindingStragegyÖrnek olarak, farklı rota bulma algoritmalarını kapsayan bir arayüz alalım . Gibi yöntemler ilan edebilir

• Route findShortestRoute(Node start, Node destination)
• boolean doesRouteExist(Node start, Node destination)
• Route[] findAllPossibleRoutes(Node start, Node destination)
• Route findShortestRouteToClosestDestination(Node start, Node[] destinations)
• Route findTravelingSalesmanRoute(Node[] stations)

bu da hepsi strateji tarafından uygulanacaktı. Bazı rota bulma algoritmaları, bu kullanım senaryolarının bazıları için dahili optimizasyonlara izin verebilir ve bazıları olmayabilir, bu nedenle uygulayıcı bu yöntemlerin her birinin nasıl uygulanacağına karar verebilir.

Diğer bir durum, stratejinin içsel bir durumu olduğu zamandır. Elbette, bazı dillerde kapaklar içsel duruma sahip olabilir, ancak bu iç durum çok karmaşıklaştığında, tam teşekküllü bir sınıfa kapanmayı teşvik etmek genellikle daha zarif hale gelir.

Anonim bir işlevin yalnızca işlev yürütmeyi bitirdiğinde sona eren durumu tutabileceği doğru değildir.

Common Lisp'de aşağıdaki örneği alın:

(defun number-strings (ss)
  (let ((counter 0))
    (mapcar #'(lambda (s) (format nil "~a: ~a" (incf counter) s)) ss)))

Bu işlev bir dize listesi alır ve listenin her öğesine bir sayaç ekler. Yani, örneğin,

(number-strings '("a" "b" "c"))

verir

("1: a" "2: b" "3: c")

İşlev number-stringsdahili olarak counter, işlev her çağrıldığında yeniden kullanılan durumu (sayacın geçerli değeri) tutan bir değişkenle anonim bir işlev kullanır .

Genel olarak, kapatmayı tek bir yöntemle bir nesne olarak düşünebilirsiniz. Alternatif olarak, bir nesne aynı kapalı değişkenleri paylaşan bir kapak koleksiyonudur. Bu yüzden, kapanış yerine bir nesneyi kullanmanız gereken durumlar olup olmadığından emin değilim: Her ikisinin de aynı kalıba farklı bakış açılarından bakmanın yolları olduğunu iddia ediyorum.

Özellikle, strateji modeli yalnızca bir yöntemle bir nesne gerektirir, bu nedenle bir kapatma işi yapmalıdır. Ancak, Philipp'in cevabında gözlemlediği gibi, koşullara (karmaşık durum) ve programlama dillerine bağlı olarak nesneleri kullanarak daha zarif bir çözüm elde edebilirsiniz.

İki tasarımın aynı sorunu çözebilmesi, birbirlerinin doğrudan ikameleri oldukları anlamına gelmez.

İşlevsel bir programdaki durumu izlemeniz gerekiyorsa, dil izin verse bile kapalı bir değişkeni değiştirmezsiniz. Bir durumu bağımsız değişken olarak alan ve yeni durumu döndürme değeri olarak döndüren bir işlevi çağırmayı ayarlarsınız.

Mimariniz çok farklı görünecek, ancak aynı hedefe ulaşacaksınız. Bir paradigmanın desenlerini doğrudan diğerine zorlamaya çalışmayın.

Strateji bir kavram , belirli ve tekrar eden bir sorunu çözmek için kullanışlı bir reçetedir. Bu bir dil kurumu değil, herhangi bir uygulama şekliyle de ilgili değildir . Kapatma, bir gün Strateji ve ertesi gün Gözlemci uygulamak için kullanılabilir.

Terim Strateji kısaca sizin niyet ifade etmek diğer programcılar ile konuşmaları çoğunlukla yararlıdır. Bunda büyülü bir şey yok.