Memiliki metode kelebihan beban yang menggunakan wadah IoC

Saya sedang menulis API di atas objek COM dan Anda harus meneruskan objek COM ke hampir semua jenis dan metode statis yang saya tulis sehingga saya dapat menguji setiap bagian API saya.

Sekarang pertanyaan saya adalah apakah saya memiliki metode kelebihan beban untuk metode yang mengambil objek COM tetapi meneruskan IoC yang terselesaikan ke metode lainnya, sehingga pengguna API tidak perlu khawatir meneruskan objek COM atau haruskah saya menghapus metode yang kelebihan beban dan menyelesaikannya tanpa opsi untuk meneruskannya.

Agak sulit untuk dijelaskan, jadi berikut ini contohnya;

Contoh Konstruktor;

FooType(IComObject obj,string table) {}
FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {}

atau hanya

FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {}

Contoh metode statis;

public static SomeType Create(IComObject obj,string table) 
{ // Do some work with obj}

public static SomeType Create(string table) 
{ 
   return MyClass.Create(Ioc.Resolve<IComObject>(),table);
}

atau hanya

public static SomeType Create(string table) 
{ 
   IComObject obj = Ioc.Resolve<IComObject>();
   return MyClass.Create(Ioc.Resolve<IComObject>(),table);
}

Kekhawatiran terbesar saya dengan kelebihan beban adalah bahwa hal itu akan menciptakan banyak metode yang hanya meneruskan panggilan. Pilihan lain apa yang saya miliki di sini atau apakah ini cara yang benar untuk mengatasi hal ini?

P.S Saya benar-benar tidak ingin membebani pengguna karena harus meneruskan instance IComObject ke seluruh aplikasi mereka.


person Nathan W    schedule 04.06.2009    source sumber
comment
Ini terlihat seperti kelanjutan dari pertanyaan di: stackoverflow.com/questions/947378/ kepada saya?   -  person jerryjvl    schedule 04.06.2009
comment
ya, semacam itu, lebih khawatir tentang noda dan kemudahan untuk ditemukan dalam hal ini.   -  person Nathan W    schedule 04.06.2009
comment
dan apakah benar melakukan apa yang saya lakukan.   -  person Nathan W    schedule 04.06.2009
comment
Tidak dapat memberi tahu Anda, perlu menggali lebih dalam tentang IoC sebelum saya dapat memberikan jawaban yang bagus;)   -  person jerryjvl    schedule 04.06.2009


Jawaban (4)


Salah satu prinsip Injeksi Ketergantungan adalah ketergantungan suatu kelas harus dibuat eksplisit ke dunia luar. Ketika sebuah kelas menyelesaikan ketergantungannya sendiri (seperti pada contoh kedua Anda), kelas tersebut bertentangan dengan prinsip tersebut, dan kembali menggunakan layanan tunggal - meskipun harus diakui Anda agak lebih baik karena Anda memiliki wadah IoC sebagai "pelarian hatch" untuk mengejek objek layanan.

Tentu saja memiliki seluruh parameter dalam konstruktor semua objek Anda agak memberatkan, tapi di situlah Kontainer IoC berperan. Jika mendukung pengkabelan otomatis, dan Anda menggunakannya sesuai rancangannya, biasanya Anda mendapati diri Anda mengalami untuk menyelesaikan sendiri beberapa kasus: Anda mengeluarkan objek pertama, dan objek tersebut sudah siap dikonfigurasi dengan semua dependensinya - dan objek tersebut sudah siap dikonfigurasi dengan semua dependensinya, dan seterusnya. Untuk alasan ini, Joshua Flanagan membuat argumen bahwa Kontainer IoC seharusnya disebut Komposer IoC.

Jika Anda ingin menghindari membebani pengguna API Anda, bagaimana jika memiliki objek fokus yang membungkus wadah IoC Anda dan mengeluarkan instance yang dikonfigurasi untuk dikonsumsi dengan memanggil kode?

person Samuel Jack    schedule 09.06.2009

Dari sudut pandang saya, kecuali Anda memiliki alasan kuat untuk mengizinkan kelebihan beban, memiliki keduanya (kelebihan beban dan resolusi) akan mempersulit API Anda dan menyebabkan terlalu banyak potensi masalah bagi pengguna Anda.

Saya pikir Anda telah menjawab pertanyaan Anda sendiri ketika Anda mengatakan "P.S. Saya benar-benar tidak ingin membebani pengguna".

person Matthew Pelser    schedule 07.06.2009

Dari satu sisi, Anda dapat dengan mudah membatalkan metode seperti

public static SomeType Create(IComObject obj,string table) 

sama sekali karena Anda dapat mendaftarkan objek tiruan bertipe IComObject selama pengujian dan menjalankan pengujian ini dengan mudah.
Namun di sisi lain, ini akan melanggar prinsip SoC dan Terbuka/Tertutup. Metode Anda mengetahui terlalu banyak dalam kasus ini (bahwa ada beberapa DI dan seterusnya). Dari sisi desain (arsitektur) lebih baik menggunakan metode seperti "Buat(IComObject obj,string table)" saja dan refactor kode untuk memperkecil penggunaan Ioc.Resolve() dan menggunakannya hanya di inisialisasi, fabric atau sesuatu seperti ini. Dan sangat sulit untuk menjelaskan cara memfaktorkan ulang ini tanpa melihat semua kodenya.
Jadi jawabannya adalah - tergantung.
EDIT:
Ada postingan yang sangat bagus tentang kasus ini. Coba cek, itu berisi jawabannya =)

person zihotki    schedule 08.06.2009

Jika pengguna peduli dengan instance IComObject maka membuat kelebihan beban adalah cara yang harus dilakukan.

Jika IComObject adalah detail implementasi untuk pengguna Anda, dan Anda satu-satunya yang peduli dengan pengujian, maka Anda sebaiknya mengekspos metode Pabrik sederhana yang digunakan kelas Anda untuk membuat instance/mengakses IComObject secara internal.

Secara umum, jika pengguna peduli dengan IComObject maka tidak akan menjadi beban jika Anda membuat kelebihan beban. Secara pribadi sebagai pengembang saya selalu menginginkan opsi sebanyak yang saya bisa.

person John Weldon    schedule 12.06.2009