Mengapa saya melihat begitu banyak kelas instantiable tanpa negara?

Saya melihat banyak kelas instantiable di dunia C ++ dan Java yang tidak memiliki status apa pun.

Saya benar-benar tidak tahu mengapa orang melakukan itu, mereka hanya bisa menggunakan namespace dengan fungsi bebas di C ++, atau kelas dengan konstruktor pribadi dan hanya metode statis di Jawa.

Satu-satunya keuntungan yang dapat saya pikirkan adalah bahwa Anda tidak perlu mengubah sebagian besar kode Anda jika nanti Anda memutuskan bahwa Anda menginginkan implementasi yang berbeda dalam situasi tertentu. Tapi bukankah itu kasus desain prematur? Itu bisa diubah menjadi kelas nanti, ketika / jika itu menjadi tepat.

Apakah saya salah? Apakah ini bukan OOP jika saya tidak memasukkan semuanya ke objek (yaitu kelas yang dipakai)? Lalu mengapa ada begitu banyak ruang nama dan kelas utilitas di pustaka standar C ++ dan Java?

Pembaruan: Saya sudah pasti melihat banyak contoh tentang ini di pekerjaan saya sebelumnya, tetapi saya berjuang untuk menemukan contoh sumber terbuka, jadi mungkin itu tidak terlalu umum. Tetap saja, saya bertanya-tanya mengapa orang melakukannya, dan seberapa umum itu.

Saya melihat banyak kelas instantiable di dunia C ++ dan Java yang tidak memiliki status apa pun.

Beberapa kemungkinan alasan untuk membuat kelas tanpa ivar sendiri:

• Negara adalah atau dapat dimuat dalam superclass.

• Kelas mengimplementasikan beberapa antarmuka dan perlu instantiable sehingga instance dapat diteruskan ke objek lain.

• Kelas dimaksudkan untuk subkelas.

• Cara praktis untuk mengelompokkan fungsi terkait. (Ya, mungkin ada cara yang lebih baik atau berbeda untuk melakukan hal yang sama.)

Apakah saya salah? Apakah ini bukan OOP jika saya tidak memasukkan semuanya ke objek (yaitu kelas yang dipakai)?

OOP adalah paradigma, bukan hukum alam. Ada beberapa bahasa di mana semuanya adalah objek, jadi Anda benar-benar tidak punya pilihan. Bahasa lain (mis. C) sama sekali tidak menyediakan dukungan untuk OOP, tetapi Anda masih bisa memprogram dengan gaya berorientasi objek. Saya akan mengatakan Anda dapat memiliki OOP jika Anda tidak melakukan semuanya di kelas ... Anda mungkin mengatakan bahwa Anda hanya memiliki lebih sedikit OOP dalam kasus itu.

Caleb dan Robert Harvey telah menunjukkan apa kelas utilitas, dan beberapa alasan yang sah untuk memiliki kelas "data-kurang". Deskripsi itu tepat, tetapi berurusan dengan aspek positif.

Saya hanya ingin menyebutkan bahwa penyalahgunaan kelas utilitas pasti dapat menjadi anti-pola OO (lihat deskripsi c2wiki ). Kutipan ini merangkumnya dengan baik:

Sejumlah besar kelas tersebut (terutama yang hanya memiliki satu metode) menunjukkan bahwa perancang berpikir terbalik, yaitu. memikirkan apa yang dapat dilakukan untuk suatu objek daripada apa yang dapat dilakukan oleh objek.

Jika Anda mengaku mempraktikkan desain berorientasi objek, tetapi basis kode Anda hampir seluruhnya terdiri dari kelas utilitas, saya akan mengatakan bahwa Anda pasti melakukan sesuatu yang salah. Karena itu, pendekatan fungsional memiliki banyak kelebihan, dan dapat menjadi sangat baik untuk dikerjakan. Hanya saja, jangan mengaku mengikuti yang satu, sementara setengah hati menerapkan yang lain.

Kelas utilitas di Java dan C ++ digunakan untuk memelihara pustaka metode yang mengambil satu atau lebih parameter input, dan mengembalikan hasilnya. Mereka tidak perlu memegang status, jika mereka hanya mengembalikan nilai. Dalam hal itu, metode ini dapat dianggap sebagai bentuk kasar dari pemrograman fungsional, dengan semua kelebihannya (tidak ada masalah dengan konkurensi, untuk satu hal).

Bagaimanapun, kelas-kelas ini hanya berfungsi untuk mengelompokkan metode terkait dalam satu wadah, metode yang tidak memerlukan instantiasi objek untuk bekerja dengan benar. Contoh dari kelas semacam itu adalah kelas Matematika yang berisi fungsi SINE dan COSINE (dan matematika lainnya).

Banyak dari kelas-kelas itu berinteraksi dengan data, bahkan jika mereka tidak secara eksplisit mengandungnya, dan perlu melakukannya dengan cara yang memerlukan beberapa instance simultan untuk menjadi aktif. Misalnya sesi kacang stateless yang berinteraksi dengan prosedur tersimpan basis data, meneruskan data yang masuk ke beberapa paket PL / SQL dan meneruskan hasilnya kembali ke aplikasi panggilan. Hal itu perlu ada dalam beberapa kejadian, tetapi tidak dengan sendirinya berisi bidang data apa pun.

Dalam bahasa berorientasi objek di mana kelas bukan objek, Anda dapat melakukan lebih banyak hal dengan objek daripada kelas.

Anda dapat melewatkan objek sebagai parameter, Anda dapat mengganti objek yang kompatibel tipe, Anda dapat mengimplementasikan antarmuka (Saya membayangkan ada bahasa di mana kelas adalah objek tetapi Anda dapat melakukan beberapa hal ini, tetapi dalam hal apa pun ...) . Semua hal ini cukup penting sehingga keputusan default biasanya adalah membuat kelas menjadi instantiable.

Untuk beberapa kelas kemampuan yang diberikan oleh Instansiasi tampaknya tidak diperlukan. Anda mungkin tidak perlu mengganti satu implementasi Cosine dengan yang lain, misalnya. Ternyata sebagian besar fungsi utilitas yang tidak memerlukan kemampuan ini, jadi sebagian besar fungsi utilitas yang memiliki kelas yang tidak instantiable.