Betapa salahnya berbicara tentang "metode" C ++ (versus "fungsi anggota")?

Saya mengerti bahwa menurut spesifikasi C ++ tidak ada yang namanya "metode", dan beberapa (banyak? Kebanyakan?) Programmer C ++ menganggap "metode" sebagai Java-isme. Di sisi lain, bahkan di forum C ++ orang-orang tampaknya berbicara tentang metode tanpa kedutan. Saya mencari konvensi yang diketahui atau praktik umum mengenai terminologi ini.

Saya mendokumentasikan API yang memiliki versi C ++ dan Java. Para pengembang benar-benar menjaga nama kelas dan metode / anggota-fungsi yang sama antara keduanya, mungkin untuk kelayakan dalam porting dan pengujian. Karena itu, beberapa dari apa yang perlu didokumentasikan tentang API ini berada "di atas" pilihan bahasa; Saya harus dapat berbicara secara umum tentang Foos and Bars, dengan metode baz () dan mumble () ...?

Jika saya berbicara tentang metode, pemrogram Java akan menganggapnya alami dan, tampaknya, pemrogram C ++ mungkin akan mengerti tetapi beberapa akan menganggapnya tidak benar. Pertanyaan saya adalah: seberapa serakah ini dalam praktek ? Bagaimana fungsi anggota C ++ secara konvensional dibicarakan dalam konteks "OOP umum", yang bertentangan dengan fungsi khusus C ++? Apakah ada cara yang lebih baik untuk berbicara tentang fungsi anggota dengan cara yang tidak salah untuk kedua bahasa? ("Fungsi anggota" sedikit bertele-tele.)

Ini bukan survei opini; Saya mencoba menentukan apakah ada konvensi aktual atau praktik umum untuk mengatasi masalah ini.

Saya mengetahui pertanyaan ini , tetapi ini tentang OOP secara umum dan tidak bertanya tentang bahasa tertentu.

object-oriented c++ terminology

— Monica Cellio
sumber

Saya memang membaca pusat bantuan dan meninjau daftar tag sebelum menanyakan hal ini. Apakah saya melakukan sesuatu yang salah dengan menanyakan ini di sini?

— Monica Cellio

Pemungutan suara dekat yang Anda miliki terutama didasarkan pada pendapat yang mungkin seperti ini .. Tidak yakin seberapa baik ini dapat bekerja di situs SE apa pun hanya karena sulit untuk secara otoritatif mengatakan apakah orang akan kesal pada Anda dan seberapa besar mereka akan jadilah .. Satu orang mungkin berpikir itu baik-baik saja dan orang lain akan berpikir itu adalah pelanggaran terminologi yang mengerikan, sama seperti yang Anda jelaskan dalam Q- karena ini hal yang relatif hanya pendapat saja

— Jimmy Hoffa

Konsep metode OOP akan memetakan paling bersih ke "fungsi anggota virtual" di C ++, tetapi hal yang sama. Ada istilah yang lebih buruk di sisi Java, seperti "metode statis" yang bukan metode tetapi berfungsi. Tetap gunakan kata "metode" yang tidak tergantung pada bahasa, dan semua orang akan mengerti apa yang Anda maksud. Jika seseorang bersikeras bahwa C ++ tidak memiliki metode, itu hanya fakta salah dan sangat menjengkelkan sepeda shedding.

— amon

@JimmyHoffa apakah ini lebih baik?

— Monica Cellio

Sebut saja metode di dalam API API lintas-bahasa Anda. Anda dapat memasukkan frasa dalam teks intro seperti "Untuk mencoba tetap menggunakan bahasa pemrograman agnostik, dokumentasi API ini akan menggunakan metode istilah untuk merujuk ke fungsi anggota C ++."

— Brandin

Jawaban:

Mengapa Anda tidak memasukkan penjelasan (seperti yang Anda lakukan dalam pertanyaan) di bagian pengantar dokumentasi, misalnya bagian Konvensi ? Kemudian Anda dapat menjelaskan bahwa istilah "metode", seperti yang digunakan dalam dokumentasi Anda, dimaksudkan dalam arti umum metode (Java), fungsi anggota (C ++), ... karena dokumentasi berlaku untuk semua implementasi.

— sceaj
sumber

Inilah yang saya lakukan, dan sejauh ini orang-orang tampaknya baik-baik saja dengan itu. Terima kasih untuk sarannya.

— Monica Cellio

Nah, Anda tidak akan dieksekusi karenanya.

Keluhan di dunia C ++ bukan salah benar benar: itu salah satu ambiguitas. Ada begitu banyak jenis "metode" di luar sana di hutan belantara tergantung pada domain apa yang Anda bicarakan, sehingga banyak dari kita lebih suka berpegang pada terminologi standar untuk menghindari kesalahpahaman nantinya. Itu berarti, secara umum, "fungsi statis / [non-statis] [murni] virtual / [non-virtual]".

Jika Anda menulis "metode" dalam dokumentasi Anda, bukan, beberapa C ++ programmer mungkin mengeluh bahwa itu tidak benar-benar jelas apa yang Anda bicarakan, atau khawatir bahwa jika Anda tidak terbiasa dengan ini C ++ konvensi, apa yang orang lain Anda hilang?

Tapi saya yakin ada jutaan programmer C ++ profesional yang mereka sendiri tidak tahu bahwa ini adalah suatu hal. Ini dunia yang besar.

Anda tidak akan dieksekusi karenanya.

— Lightness Races with Monica
sumber

Eiffel menyebutnya Rutinitas atau Fitur , C ++ menyebutnya Fungsi Anggota , dan (hampir) setiap bahasa OO lainnya yang pernah dibuat dalam seluruh sejarah komputasi, baik sebelum maupun setelah C ++ menyebutnya sebagai Metode , sehingga istilah yang terakhir umumnya harus dipahami bahkan oleh Pemrogram C ++ (dan Eiffel), kecuali mereka benar - benar belum pernah mendengar tentang Simula, Smalltalk, Self, Objective-C, Newspeak, Java, C #, VB.NET, PHP, Python, Ruby, ECMAScript / JavaScript, Scala, CoffeeScript,…

— Jörg W Mittag
sumber

Kecuali intinya adalah bahwa mereka sering berarti hal-hal yang agak berbeda di seluruh domain tersebut. Itu sebabnya OP bertanya apakah lebih baik tetap berpegang pada terminologi khusus-domain, dan mengapa jawaban yang benar adalah "ya" ...

— Lightness Races with Monica

Baru sadar Anda membuktikan maksud saya dengan mengutip JavaScript, yang bahkan tidak memiliki kelas (OO-nya berbasis prototipe). Jadi bagaimana bisa metode JavaScript sama dengan metode di tempat lain? Kecerdasan mutual yang Anda klaim sebenarnya tidak ada.

— Lightness Races dengan Monica

OOP berbasis prototipe tidak membuat perbedaan. OOP didasarkan pada gagasan bahwa objek berkomunikasi melalui pesan (seperti server mengirim permintaan satu sama lain), dan metode merujuk pada cara (metode) di mana objek tertentu merespons pesan yang diberikan. Prototipe OO hanya membuat perbedaan berkaitan dengan bagaimana metode dapat diwarisi. Apa yang membuat perbedaan lebih besar akan berbasis slot (seperti Python) vs berbasis pesan (seperti Ruby) OOP, dan apakah Anda memiliki ikatan yang terlambat atau awal.

— Saolof