Yang paling penting untuk diingat adalah bahwa itu adalah pedoman, bukan aturan.
Ada kasus di mana suatu metode harus mengambil argumen. Pikirkan tentang +metode angka, misalnya. Atau addmetode untuk koleksi.
Bahkan, orang mungkin bahkan berpendapat bahwa apa artinya menambahkan dua angka tergantung pada konteks, misalnya dalam ℤ 3 + 3 == 6, tetapi dalam ℤ | 5 3 + 3 == 2 , jadi benar-benar operator tambahan harus menjadi metode pada objek konteks yang mengambil dua argumen alih-alih sebuah metode pada angka yang mengambil satu argumen.
Demikian juga, metode untuk membandingkan dua objek harus berupa metode dari satu objek mengambil yang lain sebagai argumen, atau metode konteks, mengambil dua objek sebagai argumen, sehingga tidak masuk akal untuk memiliki metode perbandingan dengan kurang dari satu argumen.
Yang mengatakan, ada beberapa hal yang dapat dilakukan untuk mengurangi jumlah argumen untuk suatu metode:
- Buat metode itu sendiri lebih kecil : Mungkin, jika metode itu membutuhkan banyak argumen, itu terlalu banyak?
- Abstraksi yang hilang : Jika argumen berkorelasi erat, mungkin mereka bersatu, dan ada abstraksi yang Anda lewatkan? (Contoh buku teks Canonical: alih-alih dua koordinat, meneruskan
Pointobjek, atau alih-alih mengirimkan nama pengguna dan email, kirimkan IdCardobjek.)
- Status objek : Jika argumen diperlukan oleh beberapa metode, mungkin argumen tersebut harus menjadi bagian dari status objek. Jika hanya diperlukan oleh beberapa metode tetapi tidak yang lain, mungkin objek melakukan terlalu banyak dan harus benar-benar menjadi dua objek.
Salah satu caranya adalah mengekstraksi argumen ke dalam kelas baru, tetapi itu pasti akan menyebabkan ledakan kelas?
Jika model domain Anda memiliki berbagai jenis hal, maka kode Anda akan berakhir dengan berbagai jenis objek. Tidak ada yang salah dengan itu.
Dan kelas-kelas itu cenderung berakhir dengan nama yang melanggar beberapa aturan penamaan (diakhiri dengan "Data" atau "Info" dll)?
Jika Anda tidak dapat menemukan nama yang tepat, mungkin Anda mengelompokkan terlalu banyak argumen bersama atau terlalu sedikit. Jadi, Anda hanya memiliki sebuah fragmen kelas atau Anda memiliki lebih dari satu kelas.
Teknik lain adalah membuat variabel yang digunakan oleh banyak fungsi sebagai variabel anggota pribadi untuk menghindari melewatinya, tetapi itu memperluas ruang lingkup variabel, mungkin sedemikian sehingga terbuka untuk fungsi yang sebenarnya tidak membutuhkannya.
Jika Anda memiliki sekelompok metode yang semuanya beroperasi pada argumen yang sama, dan kelompok metode lain yang tidak, mungkin mereka termasuk dalam kelas yang berbeda.
Perhatikan seberapa sering saya menggunakan kata "mungkin"? Itu sebabnya itu adalah pedoman, bukan aturan. Mungkin metode Anda dengan 4 parameter baik-baik saja!