Apakah ada pola desain yang berlaku untuk model diskon?

35

Apakah ada pola desain yang dikenal untuk menerapkan model diskon?

Dengan model diskon, maksud saya yang berikut:

Jika pelanggan membeli Produk X, Produk Y dan Produk Z ia mendapat diskon 10% atau $ 100.
Jika pelanggan membeli 100 unit Produk X, ia mendapat diskon 15% atau $ 500
Jika pelanggan telah membawa lebih dari $ 100 ribu pada tahun lalu, ia mendapat diskon 20%
Jika pelanggan telah membeli 2 unit Produk X, ia mendapat 1 unit Produk X (atau Produk Y) gratis.
...

Apakah ada pola umum yang dapat diterapkan untuk menangani semua skenario di atas? Saya sedang memikirkan beberapa model, tetapi tidak dapat menemukan model yang umum.

design design-patterns financial

— Kanini
sumber

IIRC semua tutorial yang saya lihat dengan contoh-contoh yang melibatkan diskon (ada banyak) menyarankan pola Strategi

— nyamuk

2

@ Kanini Apakah ini masalah dunia nyata? Dalam kasus seperti itu, apakah sistem ini secara real-time atau deferred-time? Apakah aturan ini disajikan sebagai nilai mesin aturan atau basis data? Apakah pencarian diskon hierarkis berdasarkan prioritas? Pola strategi akan berhasil di sebagian besar kasus tetapi aturan Anda harus diperhitungkan untuk membuatnya berfungsi

— Ubermensch

3

Juga jika seseorang membeli 2 unit Produk X, satu Produk Y, dan satu Produk Z, akan mendapatkan 10% dan produk X tambahan?

— Ubermensch

@gnat beberapa tautan ke beberapa tutorial tersebut, silakan.

— user16764

18

Jika masalahnya adalah Anda perlu menerapkan beberapa diskon, dalam keadaan tertentu, Anda mungkin ingin mempertimbangkan pola Rantai Tanggung Jawab .

Singkatnya, Anda meneruskan informasi yang ingin Anda proses ke prosesor pertama, dan memutuskan dari sana apakah akan meneruskannya ke prosesor lebih lanjut sebelum mengembalikan hasilnya.

Dengan cara ini Anda dapat mengubah struktur dan urutan prosesor tanpa pernah mengubah kode panggilan.

— pdr
sumber

Rantai Tanggung Jawab adalah satu lagi yang baik. Bahkan bisa dibarengi dengan strategi. Dalam kasus di mana hanya satu diskon dapat diterapkan, setiap strategi dirantai dengan yang lain. Setiap rantai menghitung diskonnya (jika pelanggan memenuhi syarat), membandingkannya dengan diskon sebelumnya, dan meneruskan data pelanggan, pesanan, dan diskon ke rantai berikutnya. +1.

— Thomas Owens

1

Hanya pendapat saya, tetapi saya merasa lebih mungkin bahwa "Rantai Tanggung Jawab" dirancang berlebihan untuk kasus ini. Daftar sederhana model diskon (jika perlu, dengan nomor pemesanan) harus melakukannya. Daftar itu sendiri tidak tergantung dari pelanggan dan pesanannya, karena semua pelanggan harus diperlakukan sama. "Rantai tanggung jawab" lebih tepat ketika daftar model diskon sangat sering berubah pada saat dijalankan dengan cara yang sangat dinamis.

— Doc Brown

11

Strategi, Penghias, dan pola Negara menonjol bagi saya sebagai titik awal yang potensial. Status mungkin sangat berguna untuk 2 atau 3, karena 2 tergantung pada status pesanan dan 3 tergantung pada status pelanggan dalam periode waktu. Strategi dan Penghias menonjol untuk yang lain, karena Anda dapat menggunakan strategi untuk menerapkan beberapa algoritma perhitungan harga dan penghias untuk menambahkan diskon baru ke pesanan.

Namun, ingat bahwa pola desain hanyalah model. Mungkin tidak ada pola tunggal yang berlaku, melainkan sistem pola. Juga pertimbangkan untuk membuat modifikasi pada model yang dijelaskan untuk membuatnya lebih sesuai dengan solusi Anda. Lebih baik memiliki desain yang baik daripada memaksakan suatu pola di mana itu tidak selalu membantu hanya untuk dapat mengatakan bahwa Anda memiliki sebuah pola.

— Thomas Owens
sumber

Bukan itu yang sebenarnya dimaksudkan oleh pola negara, bukan?

— pdr

@ pdr Saya tidak mengerti kenapa tidak. Tetapi itu tergantung pada implementasi Anda. Jika objek pelanggan Anda melacak diskon yang bergantung pada pelanggan, maka mungkin ada operasi untuk mengembalikan diskon yang memenuhi syarat untuk pelanggan. Ketika pelanggan membeli sesuatu, atribut berubah dan implementasi metode ini berubah melalui pola keadaan.

— Thomas Owens

1

Hmm, aku mengerti maksudmu. Saya pikir itu tergantung apakah pelanggan adalah objek semi permanen dalam aplikasi, atau hanya sesuatu yang hidup dalam database dan perlu diperbarui. Tidak jelas dari pertanyaan, cukup adil. +1

— pdr

3

Dari pengalaman saya, aturan-aturan bisnis diskon semacam ini dapat dimodifikasi sepanjang waktu oleh departemen pemasaran / penjualan yang berubah-ubah. Ada kebutuhan besar untuk menjadikannya data driven dan pengguna dapat dimodifikasi daripada sepenuhnya didorong oleh kode. Bagaimana ini akan mempengaruhi pilihan model?

— jfrankcarr

@ jfrankcarr Dalam pikiran saya, itu tidak akan terjadi. Saya akan mengisi nilai untuk set item yang mengarah ke diskon, persentase off, dan sebagainya dari beberapa jenis konfigurasi. Semacam secara dinamis membangun transisi mesin negara saya dan atribut dekorator dan strategi saya.

— Thomas Owens

10

Yah, saya akan merancang model diskon sebagai pasangan "Prasyarat" dan "Diskon", di mana "Prekondisi" adalah kelas dengan metode

  bool IsFulfilled(Customer c);

atau dan

  bool IsFulfilled(Customer c, Order o);

dan Diskon memiliki metode void ApplyTo(Customer c). Ini memberi Anda kemampuan untuk menggabungkan segala jenis prasyarat dengan segala jenis diskon (saya pikir ini adalah bentuk "pola jembatan").

Jika Anda memiliki sejumlah prasyarat tetap, maka Anda dapat memecahkan masalah dengan membangun subtipe tertentu (pola strategi). Namun, ketika prasyarat Anda dibiarkan sangat kompleks, dengan pernyataan logis seperti DAN, ATAU dan BUKAN, Anda mungkin lebih baik menerapkan beberapa jenis juru bahasa untuk kondisi tersebut. Aturan dapat berupa string teks biasa yang ditulis dalam "bahasa spesifik domain" yang sederhana.

Hal yang sama berlaku untuk kelas "Diskon", Anda dapat memiliki beberapa subtipe untuk berbagai jenis diskon, atau pendekatan umum di mana aturan diskon diberikan dalam bentuk teks, dievaluasi oleh beberapa penerjemah.

— Doc Brown
sumber

Intuisi saya menyarankan ini bisa menjadi apa yang dia cari dalam konteks pertanyaan

— Ubermensch

4

Mungkin memerlukan antarmuka IDiscount karena semua diskon yang berbeda adalah hal yang sama, dan kami ingin menanganinya secara konseptual sebagai diskon umum.
Kelas "pesanan pelanggan ini" mungkin membutuhkan koleksi Diskon. Daftar? Hash? Daftar Tertaut? Belum peduli. Diskon berlaku untuk pembelian, bukan pelanggan!
Jauhkan bangunan Diskon contoh terpisah dari Pelanggan, Keranjang Belanja, Sejarah, dll. Ini akan banyak berubah - seperti yang ditunjukkan @jfrankcarr.
Mungkin kelas yang berbeda untuk setiap diskon karena algoritma dan parameter untuk setiap diskon sangat bervariasi dan tidak dapat diprediksi.
Saya melihat banyak penanganan acara karena diskon menghitung menanggapi perubahan keranjang belanja, dan sebaliknya.

Aplikasi Pola Desain

Saya melihat strategy pattern. IDiscount adalah antarmuka untuk mengimplementasikan berbagai algoritma diskon.
Saya melihat factory. Tentu saja tidak sepenuhnya abstract factory pattern, tetapi satu kelas pada titik ini dalam analisis. Secara wajar, harus ada satu tempat di mana ada konteks yang cukup untuk memutuskan diskon apa yang berlaku dan kemudian menciptakannya. Satu kelas. Jika aturan untuk menerapkan diskon kemudian meledak karena pihak jamur Departemen Pemasaran, logika Konstruksi Diskon tambahan masih harus menyatu dalam kelas pabrik dasar ini, saya pikir.
Aku bisa melihat Chain of Responsibility. Ini tidak eksklusif untuk factoryide. Alih-alih mengulangi koleksi diskon, masing-masing diskon memanggil orang berikutnya. Kelas "pesanan pelanggan" tidak memiliki koleksi diskon dalam hal ini.
Faktor "hmmmm ...." dalam Chain of Responsibility, saya pikir, adalah bahwa setiap Diskon memiliki referensi ke yang berikutnya. Implikasinya adalah ketertiban itu penting. Yang tidak demikian. Juga, konsep yang diwujudkan oleh COR adalah bahwa satu objek tidak dapat menangani permintaan sehingga diteruskan "ke otoritas selanjutnya yang lebih tinggi." Model kami berbeda. Satu-satunya permintaan adalah menghitung. Setiap diskon melakukan ini. Output atau efek mungkin nol tetapi setiap diskon menghitung. Secara insting saya condong ke arah kesetiaan dunia nyata yang lebih tinggi.

Asumsi

Diskon didasarkan pada keranjang belanja saat ini dan / atau riwayat pembelian
Diskon nol atau lebih mungkin berlaku. Tidak ada diskon yang saling eksklusif
Perhitungan yang tepat tidak tergantung pada urutan penerapan diskon.

Perubahan apa, apa yang tetap sama?

Diskon sangat berbeda. Jumlah dan jenis parameter yang berbeda untuk membuat aturan masing-masing.
Argumen untuk diskon yang memenuhi syarat berubah seiring perubahan keranjang belanja.
Jumlah diskon yang tersedia berubah
Diskon pelanggan ini memenuhi syarat untuk perubahan karena perubahan keranjang belanja.
Riwayat belanja tidak berubah dalam konteks pembelian ini
Total biaya berubah secara dinamis sebagai fungsi dari jalur pembelian dan diskon yang diterapkan.
Setelah aplikasi awal, output diskon dapat berubah, karena perubahan kuantitas pembelian misalnya.

— radarbob
sumber

Jawaban yang bagus dan lengkap ... TETAPI saya hanya memiliki kekhawatiran dan bagian asumsi tidak boleh ada, setidaknya untuk tidak memimpin jawabannya. Seluruh gagasannya adalah bahwa pola ini membantu memberikan kenyamanan dan melupakan "asumsi", aturan umum tidak perlu tahu bagaimana perhitungan dilakukan, dan apa yang digunakan oleh implementasi terperinci dari konteks (Pelanggan, item Keranjang , Siang Hari, Musim, dan sebagainya). Sangat membantu penuh

— le0diaz

Bagian depan peluru dan bagian 'Asumsi' hanyalah alasan "tunjukkan pekerjaan Anda" tentang masalah itu sendiri yang tentu saja memiliki kelemahan pada desain model diskon. Sebagai contoh, asumsi saya tentang urutan eksekusi diskon dan saling ketergantungan membuat saya tidak menekankan Chain of Responsibility. Perhatikan bahwa saya sedang memikirkan maksud pola, bukan kompleksitas seperti yang dilakukan @docbrown. Saya seorang pendukung yang bersemangat untuk mencerminkan niat dalam desain.

— radarbob

1

Secara logis, model diskon dapat berupa apa saja , jadi Anda tidak dapat mengasumsikan Anda dapat memprogram semua kasing terlebih dahulu. Tidak seorang pun yang menjawab pertanyaan Anda akan sepenuhnya yakin apa yang sebenarnya Anda butuhkan. Namun, dengan asumsi Anda mendapatkan jenis diskon yang biasa ditemukan di dunia nyata ...

Pertanyaan besar adalah apakah diskon akan diprogram, atau jika Anda ingin pengguna memasukkannya. Seperti disebutkan di atas, Anda tidak bisa tidak pernah memiliki mereka diprogram, tetapi biasanya tujuannya adalah untuk mencoba untuk membuatnya entri data lebih seperti untuk kasus-kasus umum, daripada pemrograman mereka semua. Ini berlaku sampai batas tertentu bahkan jika programmer digunakan untuk membuat semua diskon.

Martin Fowler menyebutkan "Metode Instance Individu" dalam "Pola analisis: model objek yang dapat digunakan kembali" sebagai bagian dari bagaimana menerapkan "Aturan Posting" untuk sistem akuntansi, tetapi aturan tersebut tampaknya cukup mirip dengan Anda. Saya akan memberikan detail lebih banyak tetapi ini adalah karya berhak cipta dan

Untuk antarmuka pengguna, Anda harus membuat kasus penggunaan yang cukup sederhana, atau membangun penerjemah dan pembuat kueri. Mungkin keduanya, satu untuk kasus-kasus sederhana dan satu lagi tingkat lanjut. Jika Anda menulis interpreter, ini kemungkinan merupakan kasus yang cukup baik untuk menggunakan pola Interpreter, karena relatif mudah untuk dikodekan dibandingkan dengan generator parser, dan waktu parser yang lebih lambat mungkin tidak terlalu masalah. (Jika Anda suka menggunakan generator parser jangan biarkan saya menghentikan Anda).

Jangan mencoba melakukan semuanya dengan seorang juru bahasa - pada titik tertentu Anda hanya memprogram dalam bahasa Anda sendiri yang payah, jadi sebaiknya Anda menggunakan yang asli. Jika bahasa yang Anda tafsirkan mendukung fungsi (mungkin harus mendukung pemanggilan mereka - mendefinisikannya meragukan) yang dapat dikodekan dalam bahasa nyata. Jangan melangkah lebih jauh ke jalan ini daripada yang seharusnya.

Apa pun yang Anda lakukan, pada akhirnya seseorang akan menginginkan diskon didasarkan pada apakah mereka membeli dalam waktu 30 hari kerja setelah promosi - di mana hari kerja hanya dihitung jika tidak ada hari libur di wilayah yang ditentukan oleh kode pos toko atau pelanggan. Kode Pos. Jadi jangan mencoba untuk merancang sistem yang sempurna di muka - anggap Anda kadang-kadang perlu menulis kode untuk jenis diskon baru dan desain yang sesuai.

— psr
sumber

0

Apakah ada gunanya bertanya apakah ada pola yang bermanfaat untuk ini? Apa jenis pola yang diperlukan - struktural atau perilaku?

Idealnya, jika saya menulis perangkat lunak untuk ini, yang diperlukan hanyalah algoritma . Fungsi sederhana yang menghitung total diskon sebagai berikut:

cart.calculateDiscount(productVector);

Anda tidak perlu lebih dari ini!

Untuk memperjelas: Saya mengerti bahwa akan ada banyak aturan - sebagian besar dasar dari representasi tersebut harus dalam bentuk basis aturan (set atribut data dan diskon yang dihasilkan terhadapnya) dan fungsi seperti di atas akan beralih untuk menghitungnya. Jika aturan ditambahkan atau dihapus, Anda tidak seharusnya mengubah kode - cukup ubah basis aturan.

Pola akan diperlukan hanya jika kita membutuhkan objek yang berbeda perlu mengakses API satu sama lain atau berkomunikasi untuk menempatkan tugas di tempat.

PS: Pikirkan tentang hal itu - ketika firewall memproses paket dan meneruskan atau menolak paket (atau memodifikasinya) - pola desain apa yang digunakannya? Jawabannya adalah TIDAK ADA yang dijelaskan di atas!

— Dipan Mehta
sumber

Tentu saja Anda membutuhkan lebih dari itu !!!. Idenya adalah bahwa algoritma tersebut tidak terlalu digabungkan dengan implementasi kode. Jika Anda memeriksa skenario sangat mungkin bahwa lebih banyak skenario akan muncul, juga Anda entah bagaimana menyebutkannya, dia tidak benar-benar bergantung pada 'Peraturan' mana pun. Adalah naif untuk berpikir bahwa suatu aturan hanya akan tergantung pada daftar produk, tetapi pada kenyataannya tergantung pada pelanggan, waktu, musim dan sebagainya. Tidak tahu implementasi Firewall apa yang Anda periksa, tetapi yang sudah saya periksa DO PUNYA banyak pola struktur / desain

— le0diaz