1. Statis vs contoh
Saya pikir ada pedoman yang sangat jelas tentang apa yang desain OO baik dan apa yang tidak. Masalahnya adalah bahwa blogosphere membuatnya sulit untuk memisahkan yang baik dari yang buruk dan yang buruk. Anda dapat menemukan beberapa jenis referensi yang mendukung bahkan praktek terburuk yang dapat Anda pikirkan.
Dan praktik terburuk yang dapat saya pikirkan adalah Global State, termasuk statika yang Anda sebutkan dan Singleton favorit semua orang. Beberapa kutipan dari artikel klasik Misko Hevery tentang masalah ini .
Untuk benar-benar memahami dependensi, pengembang harus membaca setiap baris kode. Ini menyebabkan Aksi Seram pada Jarak: ketika menjalankan test suite, keadaan global yang dimutasi dalam satu tes dapat menyebabkan tes berikutnya atau paralel gagal secara tak terduga. Hentikan ketergantungan statis menggunakan injeksi ketergantungan manual atau Guice.
Aksi seram di kejauhan adalah ketika kita menjalankan satu hal yang kita yakini terisolasi (karena kita tidak memberikan referensi), tetapi interaksi tak terduga dan perubahan keadaan terjadi di lokasi yang jauh dari sistem yang tidak kita beri tahu objeknya. Ini hanya dapat terjadi melalui negara global.
Anda mungkin tidak pernah berpikir seperti ini sebelumnya, tetapi setiap kali Anda menggunakan keadaan statis, Anda membuat saluran komunikasi rahasia dan tidak membuatnya jelas di API. Aksi Seram di Jarak memaksa pengembang untuk membaca setiap baris kode untuk memahami interaksi potensial, menurunkan produktivitas pengembang, dan membingungkan anggota tim baru.
Apa intinya adalah bahwa Anda tidak boleh memberikan referensi statis untuk apa pun yang memiliki semacam keadaan tersimpan. Satu-satunya tempat saya menggunakan statika adalah untuk konstanta yang disebutkan, dan saya memiliki keraguan tentang hal itu.
2. Metode dengan parameter input dan nilai balik vs. metode tanpa metode
Hal yang perlu Anda sadari adalah bahwa metode yang tidak memiliki parameter input dan parameter output tidak cukup dijamin untuk beroperasi pada semacam keadaan yang disimpan secara internal (jika tidak, apa yang mereka lakukan?). Ada seluruh bahasa yang dibangun berdasarkan gagasan untuk menghindari keadaan tersimpan.
Setiap kali Anda menyimpan status, Anda memiliki kemungkinan untuk efek samping, jadi pastikan Anda selalu menggunakannya dengan penuh pertimbangan. Ini menyiratkan bahwa Anda harus memilih fungsi dengan input dan / atau output yang ditentukan.
Dan, pada kenyataannya, fungsi yang telah menentukan input dan output jauh lebih mudah untuk diuji - Anda tidak harus menjalankan fungsi di sini dan melihat ke sana untuk melihat apa yang terjadi, dan Anda tidak perlu mengatur properti di suatu tempat lain sebelum Anda menjalankan fungsi yang sedang diuji.
Anda juga dapat menggunakan fungsi jenis ini dengan aman sebagai statika. Namun, saya tidak akan melakukannya, karena jika saya kemudian ingin menggunakan implementasi yang sedikit berbeda dari fungsi itu di suatu tempat, daripada memberikan contoh yang berbeda dengan implementasi baru, saya terjebak dengan tidak ada cara untuk mengganti fungsi.
3. Tumpang tindih vs Berbeda
Saya tidak mengerti pertanyaannya. Apa keuntungannya dalam 2 metode yang tumpang tindih?
4. Pribadi vs. Publik
Jangan memaparkan apa pun yang tidak perlu Anda ungkapkan. Namun, saya juga bukan penggemar pribadi. Saya bukan pengembang C #, tetapi pengembang ActionScript. Saya telah menghabiskan banyak waktu dalam kode Kerangka Flex Adobe, yang ditulis sekitar tahun 2007. Dan mereka membuat beberapa pilihan yang sangat buruk tentang apa yang harus dijadikan pribadi, yang membuatnya menjadi semacam mimpi buruk ketika mencoba memperluas Kelas mereka.
Jadi, kecuali jika Anda berpikir Anda adalah arsitek yang lebih baik daripada pengembang Adobe sekitar tahun 2007 (dari pertanyaan Anda, saya akan mengatakan Anda memiliki beberapa tahun lagi sebelum Anda memiliki kesempatan untuk membuat klaim itu), Anda mungkin ingin secara default dilindungi saja. .
Ada beberapa masalah dengan contoh kode Anda yang berarti bahwa mereka tidak dirancang dengan baik, sehingga tidak mungkin untuk memilih A atau B.
Untuk satu hal, Anda mungkin harus memisahkan pembuatan objek dari penggunaannya . Jadi Anda biasanya tidak akan memiliki new XMLReader()hak di sebelah tempat itu digunakan.
Juga, seperti yang dikatakan @djna, Anda harus merangkum metode yang digunakan dalam penggunaan Pustaka XML Anda, sehingga API Anda (contoh instance) mungkin disederhanakan menjadi:
_document Document = reader.read(info);
Saya tidak tahu cara kerja C #, tetapi karena saya telah bekerja dengan sejumlah teknologi web, saya akan curiga bahwa Anda tidak akan selalu dapat langsung mengembalikan dokumen XML (kecuali mungkin sebagai janji atau jenis yang akan datang) objek), tapi saya tidak bisa memberi Anda saran tentang cara menangani beban Asynchronous di C #.
Perhatikan bahwa dengan pendekatan ini, Anda bisa membuat beberapa implementasi yang dapat mengambil parameter yang memberi tahu mereka di mana / apa yang harus dibaca dan mengembalikan objek XML, dan menukar mereka berdasarkan kebutuhan proyek Anda. Misalnya, Anda mungkin membaca langsung dari database, dari toko lokal, atau, seperti dalam contoh asli Anda, dari URL. Anda tidak dapat melakukannya jika menggunakan metode statis.