İndirim modellerine uygulanacak bir tasarım deseni var mı?

İndirim modellerini uygulamak için bilinen herhangi bir tasarım deseni var mı?

İndirim modelleriyle şunu kastediyorum:

1. Bir müşteri Ürün X, Ürün Y ve Ürün Z'yi satın alırsa,% 10 veya 100 $ indirim alır.

2. Bir müşteri 100 adet X Ürün satın alırsa,% 15 veya 500 $ indirim alır.

3. Bir müşteri geçen yıl 100.000 ABD Dolarından fazla gelirse,% 20'lik sabit bir indirim alır.

4. Bir müşteri 2 adet Ürün X satın aldıysa, 1 adet Ürün X (veya Ürün Y) ücretsiz alır.

5. ...

Yukarıdaki senaryoların tümünü işlemek için uygulanabilecek genel bir kalıp var mı? Birkaç model düşünüyorum, ancak genel bir rastlamak mümkün değil.

Mesele, birden fazla indirim uygulamanız gerektiğinde, belirli koşullar altında, Sorumluluk Zinciri modelini göz önünde bulundurmak isteyebilirsiniz .

Özetle, işlemek istediğiniz bilgileri ilk işlemciye iletirsiniz ve sonucu döndürmeden önce diğer işlemcilere iletip iletmemeye karar verir.

Bu sayede çağıran kodu değiştirmeden işlemcilerin yapısını ve sırasını değiştirebilirsiniz.

Strateji, Dekoratör ve Devlet kalıpları bana potansiyel başlangıç ​​noktaları olarak göze çarpıyor. Devlet 2 ya da 3 için özellikle faydalı olabilir, çünkü 2 siparişin durumuna ve 3 ise müşterinin durumuna göre değişir. Strateji ve Dekoratör diğerleri için öne çıkmaktadır, çünkü siparişe yeni indirimler eklemek için çoklu sipariş fiyatı hesaplama algoritmaları ve dekoratör uygulamak için stratejiyi kullanabilirsiniz.

Ancak, tasarım modellerinin sadece model olduğunu unutmayın. Uygulanan tek bir kalıp olmayabilir, daha çok bir kalıp sistemleri olabilir. Ayrıca, çözümünüze daha iyi uymaları için tarif edilen modellerde değişiklikler yapmayı düşünün. İyi bir tasarıma sahip olmak, sadece bir desene sahip olduğunuzu söyleme uğruna mutlaka yardımcı olmayacağı bir desene zorlamaktan daha iyidir.

Eh, "Önkoşul" yöntemlerini içeren bir sınıf olduğu "Önkoşul" ve "İndirim" olarak bir indirim modeli tasarlardım

  bool IsFulfilled(Customer c);

veya / ve

  bool IsFulfilled(Customer c, Order o);

ve İndirim'in bir yöntemi var void ApplyTo(Customer c). Bu size herhangi bir önkoşul türünü herhangi bir iskonto türü ile birleştirme imkanı verir (bence bu bir "köprü deseni" biçimidir).

Sabit sayıda ön koşula sahipseniz, sorunu belirli alt türler (strateji modeli) oluşturarak çözebilirsiniz. Bununla birlikte, ön koşullarınızın çok karmaşık olmasına izin verildiğinde, AND, OR ve NOT gibi mantıksal ifadelerle, koşullar için bir tür kural tercümanı daha iyi uygulayabilirsiniz. Kurallar, basit bir "etki alanına özgü dil" ile yazılmış düz bir metin dizesi olabilir.

Aynısı "İndirim" dersi için de geçerlidir, farklı indirimler için bazı alt tipler veya iskonto kurallarının bazı tercümanlar tarafından değerlendirilen metin biçiminde verildiği genel bir yaklaşım olabilir.

• Muhtemelen bir IDiscount arayüzüne ihtiyaç duyar, çünkü tüm farklı indirimler aynı şeydir ve onlarla kavramsal olarak genel indirimler olarak ilgilenmek isteriz.

• "Bu müşterinin siparişi" sınıfı muhtemelen bir İndirimler koleksiyonuna ihtiyaç duyar. Liste? Hash? Bağlantılı liste? Henüz umrumda değil. İndirimler müşteriye değil satın alma işlemine uygulanır!

• İndirim örneğini Müşteri, Alışveriş Sepeti, Tarih, vb. Gibi ayrı tutun. Bu, jfrankcarr'ın işaret ettiği gibi çok değişecek.

• Her indirim için algoritma ve parametreler çılgınca ve tahmin edilemez şekilde değiştiğinden, muhtemelen her indirim için farklı bir sınıf vardır.

• İndirim hesaplamasının alışveriş sepetindeki değişikliklere yanıt vermesi ve bunun tersi için bir çok olay işleme görüyorum.

Tasarım Deseni Uygulaması

• Bir bakın strategy pattern. IDiscount, farklı indirim algoritmaları uygulamak için kullanılan arayüzdür.

• Bir bakın factory. Kesinlikle tam gelişmiş değil abstract factory pattern, analizde bu noktada tek bir sınıf var. Makul olarak, hangi indirimlerin uygulanacağına karar vermek ve daha sonra bunları oluşturmak için yeterli bağlamın olduğu tek bir yer olmalıdır. Bir sınıf. Bir Pazarlama Departmanı mantar partisi nedeniyle daha sonra indirimlerin uygulanmasıyla ilgili kurallar patlarsa, ilave bir İndirim İnşaatı mantığı hala bu temel fabrika sınıfında birleşmelidir.

• Görebildiğim Chain of Responsibility. Bu, factoryfikre karşılıklı olarak dahil değildir . Bir indirim koleksiyonunu yinelemek yerine, her indirim bir sonraki adamı çağırır. "Müşterinin emri" sınıfı, bu durumda indirim tahsilatı yapmaz.

• Sorumluluk Zinciri'ndeki "hmmmm ...." faktörü, sanırım, her İndirim bir diğerine atıfta bulunuyor. Bunun anlamı, emrin önemli olduğudur. Bu durum böyle değil. Ayrıca, CoR kavramı, bir nesnenin isteği üstesinden gelemediği için "bir sonraki yüksek otoriteye kadar" iletilir. Modelimiz farklı. Tek talep hesaplamaktır. Her indirim bunu yapar. Çıktı veya sonuç null olabilir, ancak her indirim hesaplar. İçgüdüsel olarak daha yüksek gerçek dünya sadakatine dayanırım.

Varsayımlar

• İndirimler mevcut alışveriş sepetine ve / veya satın alma geçmişine dayanmaktadır
• Sıfır veya daha fazla indirim geçerli olabilir. Karşılıklı özel indirim yoktur
• Doğru hesaplama, indirimlerin uygulanma sırasına bağlı değildir.

Ne değişir, ne kalır?

• İndirimler çok farklı. Her kuralı oluşturacak farklı sayı ve tür parametreler.

• Uygun indirimler için argümanlar, alışveriş sepeti değiştikçe değişir.

• Mevcut indirimlerdeki değişiklik sayısı

• Bu müşterinin alışveriş sepeti değiştikçe yaptığı değişikliklerde hak kazandığı indirimler.

• Alışveriş geçmişi bu satın alma bağlamında değişmiyor

• Toplam maliyet, alım hatlarının ve uygulanan indirimlerin bir fonksiyonu olarak dinamik olarak değişmektedir.

• İlk uygulamadan sonra, örneğin satın alma miktarı değiştikçe iskonto oranı değişebilir.

Mantıksal olarak, bir indirim modeli herhangi bir şey olabilir , bu nedenle tüm vakaları önceden programlayabileceğinizi varsayamazsınız. Sorunuzu cevaplayan herhangi biri gerçekte neye ihtiyacınız olduğunu tam olarak bilemez. Ancak, gerçek dünyada bulunan her zamanki indirim türlerini aldığınızı varsayarsak ...

Büyük bir soru, indirimlerin programlanıp programlanmayacağı veya kullanıcıların girmesini isteyip istemediğinizdir. Yukarıda bahsedildiği gibi, hiçbir zaman programlanmalarını sağlayamazsınız , ancak genellikle amaç, hepsini sıralamaktan ziyade, ortak durumlar için daha fazla veri girişi yapmaya çalışmaktır. Bu, tüm indirimleri oluşturmak için programcılar kullanılsa bile bir dereceye kadar geçerlidir.

Martin Fowler, muhasebe sistemleri için "Gönderme Kuralları" nın nasıl uygulanacağının bir parçası olarak "Analiz kalıpları: yeniden kullanılabilir nesne modelleri" bölümünde "Bireysel Örnekleme Yöntemi" nden bahseder, ancak kurallar sizinkilere oldukça benzer görünüyor. Daha fazla detay verirdim ama bu telif hakkı alınmış bir iş ve

Bir kullanıcı arayüzü için, oldukça basit olan kullanım durumları bulmanız veya başka bir tercüman ve sorgu oluşturucu oluşturmanız gerekir. Muhtemelen her ikisi de, basit durumlar için bir tane ve bir tane daha gelişmiş. Bir tercüman yazarsanız, bu, Tercüman modelini kullanmak için oldukça iyi bir durumdur, çünkü ayrıştırıcı oluşturucuya göre kodlamak nispeten kolaydır ve daha yavaş ayrıştırma süresi muhtemelen gerçekten önemli olmaz. (Ayrıştırma jeneratörleri kullanmaktan hoşlanıyorsanız, sizi durdurmama izin vermeyin).

Her şeyi tercümanla yapmaya çalışmayın - bir noktada sadece kendi dilinizde programlama yapabilirsiniz, yani gerçek bir dil de kullanabilirsiniz. Tercüme edilmiş diliniz işlevleri destekliyorsa (muhtemelen onları çağırmayı desteklemeli - onları tanımlamak şüphelidir) bunlar gerçek bir dilde kodlanabilir. Bu yoldan gitmen gerekenden daha ileri gitme.

Ne yaparsanız yapın, sonunda birisi indirimin promosyondan sonraki 30 iş günü içerisinde satın alınıp alınmayacağına dayanmasını ister - iş günleri yalnızca mağazanın posta kodu veya müşterinin belirlediği bölgede tatil yapılmaması durumunda sayılır. posta kodu. Öyleyse, mükemmel sistemi önceden tasarlamaya çalışmayın - bazen yeni indirimler ve buna göre tasarım için kod yazmanız gerekeceğini varsayalım.

Bunun için faydalı bir kalıp olup olmadığını sormanın bir anlamı var mı? Ne tür bir kalıp gereklidir - yapısal mı yoksa davranışsal mı?

İdeal olarak, bunun için bir yazılım yazacak olsaydım, tek gereken bir algoritma . Toplam indirimi şu şekilde hesaplayan basit bir işlev:

cart.calculateDiscount(productVector);

Bundan daha fazlasına ihtiyacınız yok!

Açıklığa kavuşturmak için: Pek çok kuralın olacağını anladım - bu temsili en temel olanı bir rulebase (veri özellikleri kümesi ve buna karşı sonuçta elde edilen indirim) şeklinde olması ve yukarıdaki gibi bir fonksiyonun bunu hesaplamak için yinelemesini gerektiriyor. Kural eklenirse veya kaldırılırsa, kodu değiştirmeye son vermemelisiniz - yalnızca kural tabanını değiştirin.

Desen yalnızca birbirlerinin API'lerine erişmek veya bir görevi yerine getirmek için iletişim kurmak için farklı nesnelere ihtiyaç duyduğumuzda gerekli olacaktır.

Not: Bir güvenlik duvarı paketleri işlediğinde ve paketleri geçerken veya reddettiğinde (veya değiştirdiğinde) düşünün - hangi tasarım desenini kullanıyor? Cevap yukarıda açıklananların YOKTUR!