"Jumlah argumen ideal untuk fungsi adalah nol" jelas salah. Jumlah argumen yang ideal adalah persis jumlah yang dibutuhkan untuk memungkinkan fungsi Anda bebas efek samping. Kurang dari itu dan Anda tidak perlu menyebabkan fungsi Anda menjadi tidak murni sehingga memaksa Anda untuk menjauh dari jurang kesuksesan dan menaiki kemiringan rasa sakit. Terkadang "Paman Bob" tepat dengan sarannya. Terkadang dia salah besar. Saran nol argumennya adalah contoh yang terakhir
( Sumber: komentar oleh @ David Arno di bawah pertanyaan lain di situs ini )
Komentar telah memperoleh 133 suara yang spektakuler, itulah sebabnya saya ingin lebih memperhatikan manfaatnya.
Sejauh yang saya ketahui, ada dua cara terpisah dalam pemrograman: pemrograman fungsional murni (apa komentar ini mendorong) dan katakan, jangan tanya (yang dari waktu ke waktu direkomendasikan di situs web ini juga). AFAIK kedua prinsip ini pada dasarnya tidak kompatibel, hampir saling bertentangan: fungsional murni dapat diringkas sebagai "hanya mengembalikan nilai, tidak memiliki efek samping" sementara mengatakan, jangan tanya dapat diringkas sebagai "jangan mengembalikan apa pun, hanya memiliki efek samping ". Juga, saya agak bingung karena saya pikir itu memberitahu, jangan tanya dianggap sebagai inti dari paradigma OO sementara fungsi murni dianggap sebagai inti dari paradigma fungsional - sekarang saya melihat fungsi murni yang direkomendasikan dalam OO!
Saya kira para pengembang seharusnya memilih salah satu dari paradigma ini dan berpegang teguh pada itu? Yah saya harus mengakui bahwa saya tidak akan pernah bisa mengikuti saya. Seringkali terasa nyaman bagi saya untuk mengembalikan nilai dan saya tidak dapat benar-benar melihat bagaimana saya dapat mencapai apa yang ingin saya capai hanya dengan efek samping. Seringkali terasa nyaman bagi saya untuk memiliki efek samping dan saya tidak dapat benar-benar melihat bagaimana saya dapat mencapai apa yang ingin saya capai hanya dengan mengembalikan nilai. Juga, seringkali (saya kira ini mengerikan) Saya punya metode yang melakukan keduanya.
Namun, dari 133 upvotes ini saya beralasan bahwa saat ini pemrograman fungsional murni "menang" karena menjadi konsensus yang lebih baik untuk diceritakan, jangan ditanya. Apakah ini benar?
Oleh karena itu, pada contoh dari game yang sarat antiputern ini, saya mencoba untuk membuat : Jika saya ingin membuatnya sesuai dengan paradigma fungsional murni - BAGAIMANA ?!
Tampaknya masuk akal bagi saya untuk memiliki keadaan pertempuran. Karena ini adalah permainan berbasis giliran, saya menyimpan status pertempuran dalam kamus (multipemain - mungkin ada banyak pertempuran yang dimainkan oleh banyak pemain secara bersamaan). Setiap kali seorang pemain melakukan giliran mereka, saya memanggil metode yang tepat pada keadaan pertempuran yang (a) memodifikasi negara sesuai dan (b) mengembalikan pembaruan kepada para pemain, yang mendapatkan serial ke dalam JSON dan pada dasarnya hanya memberi tahu mereka apa yang baru saja terjadi pada naik. Ini, saya kira, adalah pelanggaran mencolok prinsip KEDUA dan pada saat yang sama.
OK - saya bisa membuat metode KEMBALI keadaan pertempuran daripada mengubahnya di tempat jika saya benar-benar ingin. Tapi! Maka apakah saya harus menyalin segala sesuatu dalam keadaan pertempuran hanya untuk mengembalikan keadaan yang sama sekali baru alih-alih mengubahnya di tempat?
Sekarang mungkin jika langkah itu adalah serangan saya hanya bisa mengembalikan karakter yang diperbarui HP? Masalahnya, itu tidak sesederhana itu: aturan permainan, satu gerakan dapat dan seringkali akan memiliki banyak efek lebih dari sekadar melepas sebagian dari HP pemain. Misalnya, ini dapat meningkatkan jarak antar karakter, menerapkan efek khusus, dll.
Tampaknya jauh lebih sederhana bagi saya untuk hanya memodifikasi keadaan dan mengembalikan pembaruan ...
Tetapi bagaimana seorang insinyur yang berpengalaman menangani ini?