Lebih suka anggota kelas atau lewat argumen antara metode internal?


39

Misalkan dalam bagian pribadi kelas ada nilai yang digunakan oleh beberapa metode pribadi. Apakah orang lebih suka mendefinisikan ini sebagai variabel anggota untuk kelas atau meneruskannya sebagai argumen untuk masing-masing metode - dan mengapa?

Di satu sisi saya bisa melihat argumen yang dibuat bahwa mengurangi keadaan (yaitu variabel anggota) di kelas umumnya adalah hal yang baik, meskipun jika nilai yang sama digunakan berulang kali di seluruh metode kelas 'sepertinya itu akan menjadi ideal kandidat untuk representasi sebagai negara untuk kelas untuk membuat kode terlihat lebih bersih jika tidak ada yang lain.

Edit:

Untuk mengklarifikasi beberapa komentar / pertanyaan yang diajukan, saya tidak berbicara tentang konstanta dan ini tidak berkaitan dengan kasus tertentu melainkan hanya hipotesis yang saya bicarakan dengan orang lain.

Mengabaikan sudut OOP sejenak, kasus penggunaan tertentu yang ada dalam pikiran saya adalah sebagai berikut (menganggap lulus dengan referensi hanya untuk membuat pseudocode lebih bersih)

int x
doSomething(x)
doAnotherThing(x)
doYetAnotherThing(x)
doSomethingElse(x)

Jadi yang saya maksud adalah bahwa ada beberapa variabel yang umum di antara beberapa fungsi - dalam kasus yang ada dalam pikiran saya itu adalah karena rantai fungsi yang lebih kecil. Dalam sistem OOP, jika ini semua metode kelas (katakanlah karena refactoring melalui metode ekstraksi dari metode besar), variabel itu bisa dilewatkan di sekitar mereka semua atau itu bisa menjadi anggota kelas.


1
Bagaimana nilai ini digunakan? Itu konstan? Apakah itu berubah? Apakah ada perubahan di antara kompilasi?
Oded

Ketika semuanya secara otomatis menentukan semuanya sama, lebih mudah untuk berpikir bahwa itu tidak masalah. Bagaimana jika Anda memiliki fungsi yang membutuhkan nilai (x) yang disesuaikan seperti x-1?
JeffO

Jawaban:


15

Jika nilai adalah properti kelas, simpan di kelas, jika tidak, simpan di luar. Anda tidak merancang metode kelas Anda-pertama, Anda merancang sifat-sifatnya terlebih dahulu. Jika Anda tidak berpikir untuk menempatkan properti itu di dalam kelas, mungkin ada alasan untuk itu.

Hal terburuk yang dapat Anda lakukan, dalam hal skalabilitas, adalah mengubah kode Anda untuk kenyamanan. Lebih cepat daripada nanti Anda akan menemukan kode Anda membengkak dan digandakan. Namun saya harus mengakui kadang-kadang saya melanggar aturan ini ... Kenyamanan sangat menarik.


1
Saya setuju - desain / tujuan asli kelas harus memberi tahu Anda apakah itu harus variabel anggota atau argumen. Juga layak untuk dipikirkan tentang sudut injeksi ketergantungan.
Martijn Verburg

14

Jika Anda tidak benar-benar perlu menjaga keadaan di antara doa (dan ternyata Anda tidak melakukannya, atau Anda tidak akan mengajukan pertanyaan) maka saya lebih suka nilai menjadi argumen, daripada variabel anggota, karena pandangan sekilas di tanda tangan metode memberitahu Anda bahwa ia menggunakan argumen, sementara itu sedikit lebih sulit untuk langsung tahu apa variabel anggota yang digunakan oleh metode. Juga tidak selalu cepat untuk menentukan untuk apa variabel anggota pribadi.

Jadi biasanya saya tidak akan setuju bahwa kode menggunakan variabel anggota terlihat lebih bersih, tetapi jika tanda tangan metode keluar dari tangan saya mungkin membuat pengecualian. Ini adalah pertanyaan yang bermanfaat, tetapi bukan sesuatu yang akan menjadi pegangan proyek ini.


10

Terima kasih telah mengajukan pertanyaan, saya juga ingin menanyakan hal ini.

Ketika saya memikirkan hal ini, ada beberapa keuntungan mengapa saya harus menyebutnya sebagai argumen

  • lebih mudah untuk diuji -> lebih mudah untuk mempertahankan (terkait dengan poin terakhir)
  • tidak memiliki efek samping
  • lebih mudah dimengerti

Saya jelas melihat poin Anda misalnya - seseorang mem-parsing dokumen Excel (menggunakan perpustakaan POI misalnya) dan alih-alih memberikan contoh baris untuk setiap metode yang perlu bekerja dengan baris itu, penulis memiliki variabel anggota currentRowdan bekerja dengannya.

Saya akan mengatakan harus ada nama untuk pola-anti ini, bukan? (tidak tercantum di sini )


Anti-Pola mana yang Anda maksud?
Vahid Ghadiri

Singkatnya, untuk memiliki variabel anggota hanya untuk berbagi parameter antara dua (atau lebih) panggilan fungsi ...
Betlista

1

Mungkin Anda harus mengekstrak kelas baru yang berisi semua metode yang membagikan nilai itu. Tentu saja metode level tertinggi akan menjadi publik di kelas baru. Mungkin bermanfaat untuk mengekspos metode itu untuk pengujian.

Jika Anda memiliki dua temporer atau lebih yang selalu disatukan, maka Anda harus mengekstraksi kelas baru.


1

Apakah orang lebih suka mendefinisikan ini sebagai variabel anggota untuk kelas atau meneruskannya sebagai argumen untuk masing-masing metode - dan mengapa?

Jika saya mengerti apa yang Anda tanyakan: Metode-metode dalam sebuah kelas menurut definisi termasuk rincian implementasi, jadi saya tidak akan ragu untuk menggunakan anggota mana pun secara langsung dari metode apa pun.

Di satu sisi saya bisa melihat argumen yang dibuat yang mengurangi keadaan (yaitu variabel anggota) di kelas umumnya adalah hal yang baik ...

Tidak ada yang salah dengan mendeklarasikan private static finaluntuk mendefinisikan konstanta. Kompiler akan dapat menggunakan nilai dalam mempertimbangkan beberapa optimasi, dan sebagai konstanta, mereka tidak benar-benar menambah status ke kelas.

meskipun jika nilai yang sama digunakan berulang kali di seluruh metode kelas ...

Mampu merujuknya secara simbolis (mis. BLRFL_DURATION) Dan tidak harus menambahkan argumen tambahan ke metode Anda akan membuat kode Anda lebih mudah dibaca dan karenanya lebih mudah dikelola.


0

jika nilainya tidak berubah, itu adalah definisi yang konstan dan harus dienkapsulasi di dalam kelas. Dalam kasus seperti itu, itu tidak dianggap mempengaruhi keadaan suatu objek. Saya tidak tahu kasus Anda, tetapi saya memikirkan sesuatu seperti PI dalam trigonometri. Jika Anda mencoba untuk meneruskan argumen dengan konstanta seperti itu, Anda bisa mengekspos hasil kesalahan jika klien melewati nilai yang salah atau nilai yang tidak dengan akurasi yang sama seperti metode yang diharapkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.