Apakah “terlalu banyak parameter” merupakan masalah visual atau logis?

8

menurut Apakah ada pedoman tentang berapa banyak parameter yang harus diterima fungsi? , suatu metode tidak boleh memiliki terlalu banyak parameter. Namun, beberapa jawaban menyarankan masalah ini dapat diselesaikan dengan pola builder:

Builder b=new Builder();
b.setParm1("a");
b.setParm2("b");
.
.
.
Obj obj=b.createObj();

atau merangkum parameter dalam satu objek.

ObjectParam op=new ObjectParam();
op.param1="a";
op.param2="b";
.
.
.
obj.f(op);

Tapi saya ragu apakah ini menyelesaikan masalah, karena saya pikir metode tentang hanya menyelaraskan parameter dengan cara yang lebih baik (yaitu: dari horizontal ke vertikal), tetapi tidak mengubah sifat bahwa tugas tergantung pada terlalu banyak parameter. Dan jika saya ingin rantai parameter terlihat lebih baik, saya dapat menggunakan baris baru untuk setiap parameter seperti itu:

https://softwareengineering.stackexchange.com/a/331680/248528

jadi pertanyaan saya adalah, apakah "terlalu banyak parameter" masalah visual (sulit untuk membaca satu baris kode), atau masalah logis (sifat tugas tergantung pada terlalu banyak parameter dan kebutuhan rusak)? Jika ini lebih tentang masalah visual, apakah baris baru untuk setiap parameter menyelesaikan masalah?

coding-style parameters

— ocomfd
sumber

3

IMO terlalu banyak parameter lebih merupakan bau kode untuk masalah logis. Terlalu banyak parameter menyiratkan terlalu banyak dependensi => metode ini mungkin melakukan terlalu banyak hal. Tentu saja ada situasi di mana terlalu banyak parameter dapat diterima dari sudut pandang SRP (mis. Anda telah memilih untuk memasukkan daftar parameter yang panjang alih-alih menggunakan daftar), tetapi menunjukkan masalah lain (pilihan yang salah / tidak adanya struktur data )

— potatopeelings

24

Ini adalah masalah logis yang pertama dan terpenting (yang sering kali disertai dengan masalah visual). Solusi yang salah untuk ini adalah dengan mencoba hanya memperbaiki masalah visual dengan

merangkum parameter dalam satu objek [...] hanya menyelaraskan parameter dengan cara yang lebih baik (yaitu: dari horizontal ke vertikal)

Mengenkapsulasi parameter dalam objek tidak berarti menempatkan lima parameter dalam wadah arbitrer dengan beberapa nama yang tidak berarti seperti ObjectParam. Sebagai gantinya, mengenkapsulasi sekelompok parameter dalam objek harus membuat abstraksi baru (atau menggunakan kembali yang sudah ada). Suka

merangkum tiga parameter "X, Y, Z" dalam parameter "posisi tipe Point3D, atau
mengenkapsulasi parameter "startDate, endDate" pada suatu objek DateIntervalatau
mengenkapsulasi parameter documentTitle, documentText, authordalam objek yang Documentmengelompokkan parameter ini bersama-sama

Jika metode yang dipertaruhkan memiliki banyak parameter yang tidak terkait Anda tidak dapat datang dengan nama pengelompokan yang baik, maka mungkin memiliki terlalu banyak parameter dan terlalu banyak tanggung jawab.

— Doc Brown
sumber

6

Poeple juga mencoba untuk memperbaiki masalah visual, dengan memindahkan parameter fungsi ke level kelas, membuatnya kurang berantakan, tetapi kurang jelas, dan dengan kompleksitas logis yang sama. Atau bahkan lebih buruk, pindahkan parameter ke keadaan global, karena Anda tidak ingin menyebarkannya. Itu terjadi ...

— Chris Wohlert

@ ChrisWohlert Ya, ada orang yang percaya bahwa mengikuti banyak "aturan" membuat kode Anda lebih baik - karena mereka tidak tahu apa yang mereka lakukan. Pengembang yang kompeten tahu kapan harus lebih baik mengabaikan aturan daripada membuat kludges hanya untuk mengikuti aturan.

— Ralf Kleberhoff

Daftar parameter, dan parameter "objek", adalah hal yang hampir sama, dalam hal beban mental dan bahkan mungkin sintaksis. Ini jawaban yang bagus.

— Frank Hileman

1

Suatu metode yang mengambil banyak parameter pada dasarnya, sebuah langkah dalam arah yang berlawanan dari konvensi atas pendekatan konfigurasi , yang berpusat pada penyederhanaan panggilan semacam itu tanpa kehilangan kapasitas untuk mengubah nilai-nilai yang diperlukan melalui penggunaan default yang masuk akal .

Dengan kata lain, Anda jelas tidak ingin kehilangan fleksibilitas, tetapi Anda hampir pasti tidak perlu setiap parameter dilewatkan secara dinamis. Banyak parameter yang baik kemungkinan akan diperbaiki / statis. Ambil program zip sebagai contoh. Ya, mungkin Anda mungkin ingin mengubah algoritma kompresi, tingkat kompresi, jumlah core CPU yang didedikasikan untuk tugas, .. apa pun. Intinya adalah bahwa tidak ada yang ingin menentukan semua parameter ini masing-masing dan setiap kali Anda perlu membuat file zip, secara efektif mengurangi panggilan dengan memberikan esensi kosong (yaitu nama file tujuan zip, file untuk ditambahkan ke file zip).

Alasan Anda menggunakan konvensi melalui pendekatan konfigurasi adalah alasan yang sama mengapa Anda tidak harus memiliki metode yang membutuhkan banyak parameter. Singkatnya, kesederhanaan itu baik.

— Neil
sumber