Kita dapat menganggap OOP sebagai pemodelan perilaku suatu sistem. Perhatikan bahwa sistem tidak harus ada di 'dunia nyata', meskipun metafora dunia nyata kadang-kadang bisa berguna (misalnya "jaringan pipa", "pabrik", dll.).
Jika sistem yang kita inginkan terlalu rumit untuk memodelkan sekaligus, kita dapat memecahnya menjadi potongan-potongan kecil dan memodelkan mereka ("domain masalah"), yang mungkin melibatkan penguraian lebih lanjut, dan seterusnya sampai kita menemukan bagian-bagian yang perilakunya cocok (kurang lebih) dari beberapa objek bahasa bawaan seperti angka, string, daftar, dll.
Setelah kita memiliki potongan-potongan sederhana itu, kita dapat menggabungkannya untuk menggambarkan perilaku potongan yang lebih besar, yang dapat kita gabungkan menjadi bagian yang lebih besar, dan seterusnya hingga kita dapat menggambarkan semua komponen domain yang diperlukan untuk keseluruhan sistem.
Ini adalah fase "menggabungkan bersama" di mana kita dapat menulis beberapa kelas. Kami menulis kelas ketika tidak ada objek yang ada yang berperilaku seperti yang kita inginkan. Misalnya, domain kami mungkin berisi "foo", koleksi foo yang disebut "bar", dan koleksi bar yang disebut "bazs". Kami mungkin memperhatikan bahwa foo cukup sederhana untuk dimodelkan dengan string, jadi kami melakukannya. Kami menemukan bahwa bilah memerlukan isinya untuk mematuhi batasan tertentu yang tidak cocok dengan apa pun yang disediakan oleh Python, dalam hal ini kami mungkin menulis kelas baru untuk menegakkan batasan ini. Mungkin baz tidak memiliki kekhasan seperti itu, jadi kita bisa mewakili mereka dengan daftar.
Perhatikan bahwa kita dapat menulis kelas baru untuk setiap komponen itu (foos, bar dan bazs), tetapi kita tidak perlu jika sudah ada sesuatu dengan perilaku yang benar. Secara khusus, agar suatu kelas berguna, ia perlu 'menyediakan' sesuatu (data, metode, konstanta, subkelas, dll.), Jadi bahkan jika kita memiliki banyak lapisan kelas khusus kita pada akhirnya harus menggunakan beberapa fitur bawaan; misalnya, jika kita menulis kelas baru untuk foos mungkin hanya berisi string, jadi mengapa tidak melupakan kelas foo dan minta kelas bar berisi string itu? Perlu diingat bahwa kelas juga merupakan objek bawaan, mereka hanya sangat fleksibel.
Setelah kita memiliki model domain kita, kita dapat mengambil beberapa contoh potongan-potongan itu dan mengaturnya menjadi "simulasi" dari sistem tertentu yang ingin kita model (misalnya "sistem pembelajaran mesin untuk ...").
Setelah kita memiliki simulasi ini, kita dapat menjalankannya dan hei presto, kita memiliki kerja (simulasi a) sistem pembelajaran mesin untuk ... (atau apa pun yang kita pemodelan).
Sekarang, dalam situasi khusus Anda, Anda mencoba memodelkan perilaku komponen "extractor fitur". Pertanyaannya adalah, adakah objek bawaan yang berperilaku seperti "ekstraktor fitur", atau akankah Anda perlu memecahnya menjadi hal-hal yang lebih sederhana? Sepertinya ekstraktor fitur berperilaku sangat mirip dengan objek fungsi, jadi saya pikir Anda akan baik-baik saja menggunakannya sebagai model Anda.
Satu hal yang perlu diingat ketika mempelajari konsep-konsep semacam ini adalah bahwa bahasa yang berbeda dapat menyediakan fitur dan objek bawaan yang berbeda (dan, tentu saja, beberapa bahkan tidak menggunakan terminologi seperti "objek"!). Oleh karena itu solusi yang masuk akal dalam satu bahasa mungkin kurang bermanfaat dalam bahasa lain (ini bahkan dapat berlaku untuk versi berbeda dari bahasa yang sama!).
Secara historis, banyak literatur OOP (terutama "pola desain") telah berfokus pada Jawa, yang sangat berbeda dari Python. Sebagai contoh, kelas Java bukan objek, Java tidak memiliki objek fungsi sampai saat ini, Java memiliki pemeriksaan tipe yang ketat (yang mendorong antarmuka dan subkelas) sementara Python mendorong bebek-mengetik, Java tidak memiliki objek modul, Java integers / mengapung / dll. bukan objek, meta-pemrograman / introspeksi di Jawa membutuhkan "refleksi", dan sebagainya.
Saya tidak mencoba memilih di Jawa (sebagai contoh lain, banyak teori OOP berputar di sekitar Smalltalk, yang sekali lagi sangat berbeda dari Python), saya hanya mencoba menunjukkan bahwa kita harus berpikir dengan sangat hati-hati tentang konteks dan kendala di mana solusi dikembangkan, dan apakah itu cocok dengan situasi kita sekarang.
Dalam kasus Anda, objek fungsi sepertinya merupakan pilihan yang baik. Jika Anda bertanya-tanya mengapa beberapa pedoman "praktik terbaik" tidak menyebutkan objek fungsi sebagai solusi yang mungkin, itu mungkin saja karena pedoman itu ditulis untuk versi Jawa yang lama!