Kelas / Struktur Config: Pola atau Anti-Pola? Alternatif?

10

Jika Anda menambahkan opsi konfigurasi baru ke suatu program, sering kali ada banyak efek riak dalam hal mendapatkan opsi di mana mereka perlu ditindaklanjuti. Ada tiga cara dasar untuk mengatasi hal ini yang saya ketahui:

Lewati semua pengaturan konfigurasi ke bagian-bagian program Anda yang membutuhkannya secara eksplisit sebagai primitif. Ini adalah cara paling eksplisit dan cara yang memisahkan banyak hal. Kelemahannya adalah ini verbose dan rapuh.
Buat pengaturan konfigurasi yang paling sering digunakan global / statis. Ini adalah cara paling sederhana tetapi memperkenalkan aksi pada jarak jauh, menghalangi testability dan mengasumsikan bahwa konfigurasi benar-benar global (bahwa Anda hanya ingin satu konfigurasi pada waktu tertentu).
Buat kelas konfigurasi / struct yang berisi semua opsi konfigurasi untuk seluruh program atau untuk setiap masalah utama dalam program, dan kemudian sampaikan ini secara eksplisit. Ini kurang eksplisit dari (1) tetapi lebih eksplisit dari (2). Jika Anda ingin mengubah pengaturan hanya untuk satu panggilan fungsi, Anda dapat mengkloning objek konfigurasi dan mengubah nilai yang satu ini. Ini berguna dalam pengujian dan dalam praktik. Namun, Anda masih berpotensi mengirimkan banyak info ke fungsi yang tidak diperlukan dan mengubah nilai di kelas config / struct masih dapat menyebabkan tindakan di kejauhan.

Apakah Anda mempertimbangkan (3) pola atau anti-pola? Jika ini anti-pola, apa yang Anda lakukan?

— dsimcha
sumber

Bagaimana variasi pada 3 - memiliki beberapa kelas konfigurasi, melewati yang sesuai ke tempat diperlukan?

— Oded

@Oded: Saya bermaksud menekankan itu sebagai kemungkinan. Diedit.

— dsimcha

4

The terbaik solusi akan membuat beberapa interface konfigurasi dan menerapkan mereka yang Anda inginkan. Ini membatasi aksesibilitas dan menjaga segala sesuatu tetap terlokalisasi. Namun, itu terlalu banyak upaya untuk menjadi layak hanya membuang semua konfigurasi dalam satu kelas dan pindah ke masalah dengan lebih banyak gravitas. Ini adalah konfigurasi, bukan UtterlyCrucialAlwaysChangingClass - ini akan tetap sama. Selama Anda tidak menjadikannya global, dan implementasinya konsisten, saya tidak akan khawatir.

— DeadMG
sumber

4

+1 untuk mengatakan bahwa sesuatu bukanlah desain yang ideal secara teoritis tetapi mungkin masih bagus dalam praktiknya ketika kesederhanaan dan kemungkinan perubahan (atau ketiadaannya) dipertimbangkan.

— dsimcha

Saya hanya membuang empat argumen dan menggantinya dengan kelas Pengaturan. Rasanya seperti hal yang benar.

— Martin Ueding

Saya tidak mengerti yang mana dari 3 opsi yang Anda sarankan. Bisakah Anda sebutkan?

— DBedrenko

1

Saya lebih suka opsi Anda 1 karena decoupling memungkinkan pengujian lebih mudah, dan pengaturan konfigurasi objek tergantung dibuat secara eksplisit. Jika suatu objek memerlukan pengaturan konfigurasi, maka secara eksplisit berikan ke objek dengan argumen konstruktor atau metode penyetel. Kurangi verbositas dengan menggunakan kerangka kerja injeksi ketergantungan untuk menyuntikkan pengaturan konfigurasi tersebut ke objek.

— Jim Huang
sumber

Anda telah berkontradiksi dengan diri Anda sendiri: Anda mengatakan untuk menggunakan Opsi 1, tetapi kemudian mengatakan "Kurangi verbositas dengan menggunakan kerangka kerja injeksi dependensi untuk menyuntikkan pengaturan konfigurasi tersebut ke objek." yaitu Opsi 3: injeksi konstruktor.

— DBedrenko

0

Bayangkan jika file konfigurasi Anda ditulis dalam XML. Anda kemudian bisa meneruskan fragmen XML ini ke masing-masing komponen Anda, sehingga mereka mendapatkan data konfigurasi mereka.

Jika Anda menggunakan .NET, Anda bisa membuat kelas dengan DataContracts yang bisa Anda gunakan XmlSerialiser untuk membuat hierarki objek dari Xml konfigurasi Anda, dan meneruskan objek-objek ini sebagai konfigurasi.

Ini kemudian memperkenalkan Anda pada masalah selanjutnya. Data konfigurasi Anda memiliki tiga bagian berbeda untuk itu. Konfigurasi aplikasi struktural yang mengatur pustaka kode Anda untuk berperilaku sebagai produk khusus ini. Pengaturan konfigurasi situs yang berisi pengaturan khusus instalasi Anda dan data preferensi / pengaturan pengguna yang bervariasi dengan setiap pengguna di sistem Anda.

Mengetahui bagian mana yang mana, dan menjaga pengaturan data ini terpisah akan membuat menginstal pembaruan jauh lebih mudah (tanpa kehilangan pengaturan pelanggan)

— Michael Shaw
sumber

0

Saya akan membuat kelas di opsi # 3 statis. Jadi, bukannya

//create SomeCl
Foo f = new Foo();
f.setConfigInst(cfg);
...
...
//Inside Foo
public void setConfig(MyAppConfig c) { localCfg = c; }
...
//somewhere else:
x = localCfg.getConfigForX();

Anda hanya dapat memiliki:

//Inside Foo
x = MyAppConfig.getConfigForX();

Biarkan detail memuat / menyimpan data konfigurasi terjadi di dalam MyAppConfigkelas. Dan tentu saja Anda dapat memiliki variasi yang lebih kompleks, seperti kelas yang berbeda untuk tujuan yang berbeda.

Satu-satunya kasus di mana pendekatan ini akan menjadi masalah adalah jika Anda karena alasan tertentu perlu bekerja pada beberapa contoh konfigurasi yang berbeda pada saat yang sama , walaupun saya belum menemukan situasi seperti itu.

— FrustratedWithFormsDesigner
sumber

1

Itulah yang cukup banyak terjadi ketika menjalankan tes unit dalam beberapa kerangka pengujian ... Tetapi bahkan tanpa tes unit paralel secara eksplisit, itu akan menjadi sakit di pantat untuk objek tes unit yang tergantung pada keadaan global.

— Péter Török

0

Saya sedang mengerjakan sebuah proyek di mana kami menggunakan pendekatan "3 lapisan (antarmuka, logika bisnis, akses data)". Aplikasi dapat berupa server web multiuser atau server klien.

Kami bekerja dengan 3 konfigurasi berbeda, spesifik pertama untuk PC, apakah pengguna berfungsi. Khusus kedua untuk pengguna saat ini, dan konfigurasi global ketiga untuk semua pengguna & aplikasi klien.

Setiap konfigurasi direpresentasikan dalam setiap instace aplikasi oleh suatu objek.

Pendekatan ini dapat membantu proyek Anda.

— umlcat
sumber