Apakah suatu objek harus mewakili suatu entitas?

Oleh entitas yang saya maksud sesuatu seperti Product, Motor, a ParkingLotdll, fisik, atau bahkan benda konseptual non-fisik yang jelas - sesuatu yang didefinisikan dengan baik, dengan beberapa data inti jelas milik objek, dan beberapa fungsi / metode yang jelas beroperasi pada data inti.

Sebagai contoh, saya bisa memiliki objek dari Demon, suatu entitas dalam dirinya sendiri, satu imajiner mungkin dan bukan fisik tapi sebuah entitas tetap

Bisakah suatu objek hanya kumpulan metode , seperangkat prosedur umum yang terkait dengan tujuan bersama?

Contoh: dapat kelas dipanggil MotorOperationsatau MotorActions, di mana tidak ada entitas, tetapi metode di dalam kelas melakukan hal-hal seperti

• getMotorDataFromHTMLForm ()
• getMotorManufacturers ()
• selectMotorFromUserRequirements ($ persyaratan)
• canMotorCanHandleOperatingConditions ($ conditions)
• computePowerConsumptionForMotor ($ id)

Kelas biasanya didefinisikan sebagai pusat data untuk objek + operasi pada data. Jadi untuk Motormungkin ada beberapa variabel motor yang berkaitan dengan spesifikasi motor, dan mungkin ada operasi yang menggabungkan data tersebut untuk menghasilkan sesuatu.

Dalam kasus saya itu lebih seperti saya memiliki kelas dengan operasi pada data + data yang melewati kelas, tidak ada data sentris untuk "Operasi Motor", selain data sementara pass-through-the-class.

Pertanyaan

Bisakah kelas mewakili objek tanpa entitas? Jika tidak, mengapa mereka buruk / tidak lengkap / non-OOP-sentris? Apakah ada cara mereka perlu diubah / ditingkatkan secara konseptual agar sejalan dengan OOP?

Tidak , suatu objek tidak harus mewakili suatu entitas.

Bahkan, saya berpendapat bahwa ketika Anda berhenti berpikir tentang objek sebagai entitas fisik adalah ketika Anda akhirnya mendapatkan manfaat yang dijanjikan OOP.

Ini bukan contoh terbaik, tetapi desain Pembuat Kopi mungkin di mana cahaya mulai menyala untuk saya.

Objek adalah tentang pesan. Mereka tentang tanggung jawab. Itu bukan tentang Mobil, Pengguna, atau Pesanan.

Saya tahu kita mengajar OO dengan cara ini, tetapi menjadi jelas setelah beberapa kali mencoba betapa frustrasinya itu untuk mencari tahu ke mana perginya ketika Anda mencoba melakukan MVC, MVVM atau MV apa pun. Entah model Anda menjadi kembung sangat konyol atau pengendali Anda melakukannya. Untuk navigasi, senang mengetahui bahwa apa pun yang menyentuh Kendaraan ada dalam file Vehicle.ext, tetapi ketika aplikasi Anda tentang Kendaraan, Anda pasti akan mendapatkan 3000 baris spageti dalam file itu.

Ketika Anda memiliki pesan baru untuk dikirim, Anda memiliki setidaknya satu objek baru, dan mungkin sepasang objek. Jadi, dalam pertanyaan Anda tentang seikat metode, saya berpendapat bahwa Anda berpotensi berbicara tentang seikat pesan. Dan masing-masing bisa menjadi objeknya sendiri, dengan tugasnya sendiri. Dan itu tidak masalah. Ini akan menjadi jelas ketika Anda memisahkan hal-hal mana yang benar-benar perlu disatukan. Dan Anda menyatukannya. Tetapi Anda tidak segera menjatuhkan setiap metode di laci yang samar-samar sesuai untuk kenyamanan jika Anda ingin menikmati OO.

Mari kita bicara tentang sekumpulan fungsi

Objek dapat berupa kumpulan metode dan masih menjadi OO, tetapi "aturan" saya cukup ketat.

1. Koleksinya harus memiliki satu tanggung jawab, dan tanggung jawab itu tidak boleh sebesar generik seperti "Melakukan barang untuk motor". Saya mungkin melakukan hal semacam itu sebagai fasad lapisan layanan, tetapi saya sangat sadar bahwa saya malas untuk alasan navigasi / penemuan, bukan karena saya mencoba menulis kode OO.

2. Semua metode harus pada lapisan abstraksi yang konsisten. Jika satu metode mengambil objek Motor dan yang lain mengembalikan Horsepower, itu mungkin terlalu jauh.

3. Objek harus bekerja pada "jenis" data yang sama. Objek ini melakukan hal-hal untuk motor (mulai / berhenti), yang ini melakukan hal-hal dengan panjang engkol, yang satu ini menangani urutan pengapian, yang ini mengambil bentuk html. Data ini dapat berupa bidang pada objek dan itu akan tampak kohesif.

Saya biasanya membangun objek semacam ini ketika saya melakukan transformasi, komposisi, atau hanya tidak ingin khawatir tentang mutabilitas.

Saya menemukan fokus pada tanggung jawab objek membawa saya ke arah kohesi. Harus ada suatu kohesi untuk menjadi objek, tetapi tidak perlu ada bidang atau perilaku yang terlalu banyak untuk menjadi objek. Jika saya sedang membangun sistem yang membutuhkan 5 metode motor itu, saya akan mulai dengan 5 objek berbeda yang melakukan hal-hal itu. Ketika saya menemukan kesamaan, saya akan mulai menggabungkan hal-hal bersama atau menggunakan benda-benda "pembantu" yang umum. Itu memindahkan saya ke masalah terbuka / tertutup - bagaimana saya bisa mengekstrak sedikit fungsionalitas ini sehingga saya tidak perlu memodifikasi file tertentu lagi tetapi masih menggunakannya di mana diperlukan?

Objek adalah tentang pesan

Bidang nyaris tidak berarti bagi suatu objek - mendapatkan dan mengatur register tidak mengubah dunia di luar program. Berkolaborasi dengan objek lain menyelesaikan pekerjaan. Namun, kekuatan OO adalah kita dapat membuat abstraksi sehingga kita tidak harus memikirkan semua detail individu sekaligus. Abstraksi yang bocor atau tidak masuk akal bermasalah, jadi kami berpikir secara mendalam (terlalu banyak, mungkin) tentang membuat objek yang cocok dengan model mental kita.

Pertanyaan kunci: Mengapa kedua benda ini perlu berbicara satu sama lain?

Pikirkan objek tersebut sebagai organ dalam diri seseorang - ia memiliki tujuan default dan hanya mengubah perilaku ketika menerima pesan tertentu yang ia pedulikan.

Bayangkan sebuah skenario di mana Anda berada di penyeberangan dan sebuah mobil melaju kencang. Sebagai objek otak, saya mendeteksi stresor. Saya memberi tahu hipotalamus untuk mengirim hormon pelepas kortikotropin. Kelenjar hipofisis mendapatkan pesan itu dan melepaskan hormon kortikotrofik adrenal. Kelenjar adrenal mendapatkan pesan itu dan membuat adrenalin. Ketika objek otot mendapatkan pesan adrenalin itu berkontraksi. Ketika hati menerima pesan yang sama, jantung berdetak lebih cepat. Ada seluruh rantai pemain yang terlibat dalam memulai perilaku kompleks berlari di seberang jalan dan itu adalah pesan yang penting. Objek otak tahu bagaimana membuat hipotalamus mengirimkan peringatan, tetapi tidak tahu rantai benda yang pada akhirnya akan membuat perilaku terjadi. Demikian juga hati tidak tahu dari mana adrenalin berasal,

Jadi, dalam contoh ( disederhanakan ) ini, objek kelenjar adrenal hanya perlu tahu cara mengambil ACTH dan membuat adrenalin. Tidak perlu bidang apa pun untuk melakukan itu, namun masih tampak seperti objek bagi saya.

Sekarang jika aplikasi kita dirancang hanya untuk berlari di seberang jalan, aku mungkin tidak membutuhkan kelenjar pituitari dan objek kelenjar adrenal. Atau saya hanya perlu objek kelenjar pituitari yang hanya melakukan sebagian kecil dari apa yang secara konseptual kita lihat sebagai "model kelenjar pituitari". Semua konsep ini ada sebagai entitas konseptual, tetapi merupakan perangkat lunak dan kita dapat membuat AdrenalineSender atau MuscleContractor atau apa pun dan tidak terlalu khawatir tentang "ketidaklengkapan" model kami.

Bisakah kelas mewakili objek tanpa entitas? Jika tidak, mengapa mereka buruk / tidak lengkap / non-OOP-sentris? Apakah ada cara yang perlu diubah / ditingkatkan?

Singkatnya, Anda dapat melakukan apa saja, tetapi skenario khusus ini akan bertentangan dengan prinsip OOP :)

Apa yang Anda gambarkan kadang-kadang disebut kelas "utilitas" - biasanya merupakan tanda dari bau kode. Anda ingin menghindari membuat kelas demi menjaga beberapa metode bersama.

Tidak setiap objek dalam aplikasi Anda harus ditautkan ke entitas kehidupan nyata seperti motor, atau mobil; itu adalah objek bisnis. Dalam aplikasi Anda, Anda cenderung menggunakan banyak objek bisnis Anda, tetapi Anda juga akan memerlukan beberapa pemisahan lagi untuk operasi lain yang bukan bagian dari entitas bisnis, seperti yang Anda daftarkan.

Anda harus melihat pola arsitektur umum - salah satunya adalah MVC (Model-View-Controller) .

Jika saya mendistribusikan metode yang Anda daftarkan menggunakan MVC, berikut adalah apa yang akan saya lakukan:

Lihat Kelas:

• GetMotorDataFromHTMLForm ()

Kelas Model (Terutama Motor):

• GetMotorManufacturer ()
• CanMotorHandleOperationConditions ()
• CalculatePowerConsumption ()

Kelas Pengendali (MotorsController):

• GetAllMotors ()
• GetMotorById ()
• GetMotorByUserRequirements ()

Sepertinya Anda menggunakan PHP; kerangka kerja MVC yang bagus untuk dilihat adalah Laravel . Dalam contoh mereka, mereka menggambarkan dengan baik di mana metode apa milik

Sumber informasi lain yang lebih umum tentang cara memutuskan di mana metode tersebut berada adalah prinsip GRASP dan SOLID .

Bisakah kelas mewakili objek tanpa entitas?

Bisa? Iya. Harus? Mungkin tidak - atau setidaknya, bukan bagaimana Anda mengutarakan sesuatu.

Objek sebenarnya adalah yang terbaik ketika tidak mewakili objek fisik secara langsung karena kenyataan sehingga jarang memetakan dengan baik ke kode. Tetapi mereka perlu mewakili konsep kohesif atau objek kode. Mereka perlu mewakili satu tanggung jawab kohesif.

Hanya bundling sekelompok fungsi terkait tangensial bersama adalah namespace atau modul - bukan objek dalam bahasa OOP. Itu bisa bermanfaat, tetapi tidak sama, dan membutuhkan jenis penggunaan / pemikiran yang berbeda untuk bekerja secara efektif.

Kelas harus memodelkan sesuatu - jika tidak, tidak ada gunanya. Namun, apa yang dimodelkan mungkin bukan "benda" fisik; sebagai gantinya, itu mungkin merupakan representasi dari sesuatu yang tidak 'nyata', tetapi yang diperlukan untuk mengendalikan sistem yang dimodelkan. Misalnya, dalam sistem kontrol lampu lalu lintas Anda bisa memiliki semacam kelas ControlSignal, mewakili sinyal yang dikirim dari satu bagian sistem ke yang lain untuk menunjukkan bahwa beberapa tindakan perlu dilakukan. Dalam "dunia nyata", sinyal-sinyal ini mungkin terdiri dari impuls listrik yang dikirim melalui kabel dari satu kotak ke kotak lainnya. Proses pemodelan sesuatu yang tidak "nyata" sebagai objek konkret disebut sebagai "reifikasi".

Semoga berhasil.

Tidak. (Judul diedit untuk menanyakan pertanyaan sebaliknya!)

misalnya:

Public class MyRepository
{
    public MyObject GetObject(string id)
    {
        //get data from the DB and build an object
    }
}

atau

Public class MyService
{
    public MyObject3 ProcessData(MyObject1 obj1, MyObject2 obj2)
    {
         //perform a process which is not a sole responsiblity of obj1 or obj2
    }
}

Namun, secara umum ideal di balik OOP adalah untuk menjauh

public struct Car
{
    public Wheel[] Wheels;
}

public int CountWheelsOnCar(MyCarStruct car)
{
   return car.Wheels.Length;
}

untuk

public class Car
{
    private Wheel[] wheels;
    Public int CountWheels()
    {
        return this.wheels.Length;
    }
}

Saya pikir memvisualisasikan sesuatu di dunia nyata sangat membantu ketika mengkodekan kelas tetapi tidak perlu.

Faktanya, tergantung pada seberapa literal yang Anda inginkan, banyak objek yang bekerja dengan kami tidak memiliki representasi fisik sama sekali. Misalnya - pertimbangkan arsitektur MVC. Di dunia nyata tidak ada Model atau Pengendali meskipun mereka umumnya diwakili oleh kelas. Tiga bersama sering mewakili sesuatu, tetapi tidak selalu - tetapi seperti yang saya katakan Anda mungkin bisa memaksakan kecocokan menjadi sesuatu jika Anda benar-benar ingin (dan mampu membayangkan SESUATU membantu! Saya memvisualisasikan sebagian besar objek dengan cara tertentu - hanya saja tidak apa-apa Anda akan pernah melihat di dunia nyata).

Sebagian besar "Aturan" yang akan Anda pelajari tentang OO ini hanyalah pedoman yang dimaksudkan untuk membuat Anda berorientasi pada pemikiran dalam OO, belum tentu hal-hal yang sangat Anda khawatirkan begitu Anda menggunakannya untuk kode setiap hari.

Ngomong-ngomong, OO itu sendiri bukan obat mujarab dan itu tidak banyak membantu Anda sama sekali saat lulus pertama Anda dalam coding beberapa solusi, tapi saya pikir jika dilakukan dengan benar itu adalah cara yang benar-benar fantastis untuk mengatur kode sehingga bisa lebih mudah dipahami nanti. Menulis kode yang dapat dipelihara mungkin merupakan salah satu tugas tersulit dalam pengembangan perangkat lunak dan dalam banyak kasus (apa pun yang memerlukan debugging / pemeliharaan yang sedang berlangsung) itu sejauh ini yang paling penting.

Apakah suatu objek harus mewakili suatu entitas?

Pertanyaan: Entitas mana yang Loggerdiwakili?

Tidak secara metaforis - secara harfiah.

Ketika menjelaskan OOP kepada siswa, akan sangat membantu untuk menjelaskan objek dengan analogi dengan dunia fisik.

Alan Kay - salah satu bapak OOP - menulis sebagai berikut:

[...]

Konsepsi orisinilnya memiliki bagian-bagian berikut.

• Saya memikirkan benda yang seperti sel biologis dan / atau komputer individu pada jaringan, hanya dapat berkomunikasi dengan pesan
• Saya ingin menyingkirkan data.

[...]

OOP bagi saya berarti hanya olahpesan, penyimpanan lokal dan perlindungan dan

menyembunyikan proses negara, dan sangat mengikat semua hal.

arsitektur HW hampir tidak bisa dipercaya. Saya menyadari bahwa itu

metafora sel / seluruh komputer akan menghilangkan data

sumber

Dari ini, objek dipahami sebagai

• objek autarkik mengenkapsulasi / menyembunyikan data

• berkomunikasi dengan objek lain melalui pesan

Bisakah kelas mewakili objek tanpa entitas?

Jelas: Pikirkan Math

Mengenai contoh Anda:

Contoh: dapat kelas disebut MotorOperations atau MotorActions, di mana tidak ada entitas, tetapi metode di dalam kelas melakukan hal-hal seperti

• getMotorDataFromHTMLForm ()

• getMotorManufacturers ()

• selectMotorFromUserRequirements ($ persyaratan)

• canMotorCanHandleOperatingConditions ($ conditions)

• computePowerConsumptionForMotor ($ id)

Untuk memutuskan, di mana harus meletakkan metode ini, Anda harus melihat responsibilities: siapa yang bertanggung jawab untuk apa .

getMotorDataFromHTMLForm ()

Konteks metode semacam itu adalah membangun objek motorik . Bukan tanggung jawab motor untuk membuat sendiri dari Data yang diambil melalui formulir . Setidaknya ada dua objek yang terlibat; satu adalah motor dan yang lainnya adalah pencipta motor .

getMotorManufacturers ()

Konteks khas di mana seseorang akan menulis metode seperti itu adalah a service.

selectMotorFromUserRequirements ($ persyaratan)

Ini juga akan digunakan dalam service-context

canMotorCanHandleOperatingConditions ($ conditions)

Ini adalah pertanyaan untuk motor-object

computePowerConsumptionForMotor ($ id)

Ini juga pertanyaan terbaik yang diajukan motor itu sendiri.

tl; dr

Metafora objectssebagai objek fisik lebih menjengkelkan daripada membantu.

Ya, Anda bisa melakukan ini. Tetapi pada dasarnya Anda membuat kelas untuk menyediakan fungsionalitas yang sama dengan pustaka prosedural. Satu-satunya alasan untuk melakukan itu adalah jika bahasa Anda tidak memiliki modul prosedural (misalnya, Java atau Ruby).

Dalam bahasa dengan modul prosedural (saya pikir PHP memiliki modul prosedural), Anda dapat mempertimbangkan hanya menggunakan modul prosedural.

Anda juga bisa mempertimbangkan mendesain ulang kelas Anda sehingga instance kelas mewakili objek yang koheren.

Tetapi hanya gunakan notasi OO ketika memberi Anda kekuatan ekstra, tidak hanya demi menjadi OO!

Dalam kata-kata awam

• Apa yang Anda gambarkan disebut kelas utilitas.
• Ini tidak memiliki keadaan, berarti Anda tidak akan pernah benar-benar perlu memiliki beberapa contoh itu
• Semua metode bersifat statis, artinya Anda harus melewati semuanya sebagai parameter

Kelas-kelas semacam itu memang ada, misalnya Java SDK memiliki kelas Koleksi yang secara eksklusif terdiri dari metode statis yang beroperasi pada atau mengembalikan koleksi.

Jadi jawabannya adalah tidak, tidak semua kelas perlu dimodelkan dari entitas domain.

Di sisi lain, kelas-kelas semacam itu hanya beberapa atau seharusnya hanya sedikit dalam program yang dibuat dalam bahasa OOP, karena kekuatan OOP yang sebenarnya terletak pada polimorfisme dan enkapsulasi.

Itu akan seperti menggunakan pesawat untuk pergi dari satu tempat ke tempat lain bukan dengan terbang tetapi dengan mengendarainya di sekitar jalan raya. Pesawat memiliki roda seperti mobil, tetapi dimaksudkan untuk terbang.

Tidak, kelas hanya mewakili sesuatu yang dapat dipakai, memiliki anggota, dan dapat diwarisi dari.

Bahkan, bahasa Anda mungkin memiliki kelas statis, yang bahkan tidak dipakai lebih dari satu kali.

.NET'sMath adalah contoh yang bagus dari kelas "profesional" yang tidak mewakili entitas (kecuali jika Anda ingin mendapatkan filosofi tentang apa itu matematika ...), dan juga menggambarkan kasus penggunaan yang sah dari kelas semacam itu. Ini hanya memiliki metode dan 2 bidang (keduanya mewakili konstanta individu).

Hirarki kelas dari perpustakaan yang sama Math.Net,, mengelompokkan metode matematika / numerik ke dalam kelas berdasarkan tipe. Di sini kelas mewakili bukan entitas, tetapi kategori logis.

Saya sendiri sering berakhir dengan membuat kelas (statis) yang tidak lebih dari sekantong fungsi terkait (statis), atau sekelompok konstanta yang dengan mudah dikelompokkan dalam satu tempat sentral. Saya tidak akan mengklaim bahwa ini adalah desain yang baik, tetapi kadang-kadang itu solusi yang paling mudah.

Jawaban atas pertanyaan Anda pada akhirnya bergantung pada seberapa tepatnya seseorang mendefinisikan istilah seperti "kelas" dan "entitas." Anda melakukan pekerjaan yang baik untuk mendefinisikan yang terakhir, memungkinkan entitas fisik dan konseptual. Tetapi istilah "kelas" untuk puritan akan selalu menjadi "pabrik untuk instantiasi objek dengan representasi internal tertentu" dan untuk pragmatis istilah tersebut akan mencakup hal-hal Jawa atau C ++ yang dibenci oleh puritan. Ditto untuk istilah "OOP," yang mungkin dikatakan oleh para pragmatis tentang Java dan C ++, tetapi para puritan mana yang akan berarti apa yang dimaksud Alan Kay ketika dia berkomentar ["Saya menemukan istilah berorientasi objek, dan saya dapat mengatakan kepada Anda bahwa saya tidak melakukannya. memiliki C ++ dalam pikiran "] ( Jadi * apa yang * Alan Kay benar-benar maksud dengan istilah" berorientasi objek "? ).

Jika Anda mengambil pandangan pragmatis, Anda dapat menerima kelas utilitas tanpa instance Anda. Namun pandangan purist lebih menarik. OOP, menurut Kay, selalu lebih banyak tentang pesan daripada kelas. Jadi untuk pertanyaan Anda:

Bisakah kelas mewakili objek tanpa entitas?

Kelas mengklasifikasikan objek. Kelas menurut definisi entitas yang Anda kirimi pesan seperti newuntuk menghasilkan objek. Objek adalah entitas yang dibuat dari kelas. Kelas ada untuk memproduksi, dan memang mengklasifikasikan, objek. Itu yang dilakukan kelas. Kelas membuat objek. Kami menggunakan kelas untuk mengklasifikasikan objek. Jadi, jika C hanyalah kumpulan metode yang tidak mengizinkan instantiasi atau subkelas, tidak mungkin ada objek yang diklasifikasikan oleh C, jadi C bukan kelas.

Jika tidak, mengapa mereka buruk / tidak lengkap / non-OOP-sentris?

Itu tidak buruk. Hanya saja, jangan sebut mereka kelas. Satu bundel metode adalah OOPable: sesuatu yang bisa Anda kirimi pesan untuk memanggil suatu metode, tetapi itu bukan kelas kecuali ia bisa membuat instance objek. Apakah Anda kenal Ruby? Di Ruby modul adalah kumpulan metode. Sebuah kelas adalah modul yang dapat instantiate objek. Tidak ada yang buruk tentang modul . Tetapi hal yang membuat kelas berbeda dari modul (dalam istilah OOP murni) adalah bahwa kelas dapat memiliki instance. Modul hanyalah beberapa metode. Kebingungannya adalah bahwa C ++ dan Java dan bahasa lain menggunakan istilah "kelas" untuk kelas dan modul .

Sekarang, untuk melihat salah satu contoh spesifik Anda, Anda bertanya tentang MotorOperationskelas di mana Anda dapat mengirim pesan computePowerConsumptionForMotordengan argumen id. Apakah itu buruk? Setidaknya itu tidak melanggar Prinsip Tell Don't Ask . Apakah kita harus membuat kelas motor dan mengirimkannya powerConsumptionpesan? Mungkin tidak 100% dari waktu, tetapi mungkin mencoba melakukan hal-hal seperti itu akan menyebabkan beberapa wawasan yang bagus tentang kode Anda. Atau, itu dapat menyebabkan ledakan kelas kecil yang akan menjadi buruk.

Apakah ada cara mereka perlu diubah / ditingkatkan secara konseptual agar sejalan dengan OOP?

Jika "melakukan OOP" penting bagi Anda, maka Anda perlu mencari cara untuk merancang sistem menjadi komponen yang berkomunikasi dengan mengirim pesan satu sama lain. Itu hanya apa OOP adalah , atau setidaknya apa yg berfantasi saja istilah yang ada dalam pikiran. Kelas utilitas bukan OOP dalam tampilan ini. Tetapi bagi sebagian orang, mereka mungkin saja demikian.

Mencoba membuat keseluruhan sistem besar dari jutaan makhluk hidup, pernapasan, benda, semuanya berasal dari kelas, dapat bekerja untuk beberapa proyek. Tetapi jika Anda menemukan diri Anda membuat kelas buatan, salah terdengar, maka modul harus diperkenalkan. Cobalah untuk menekankan kelas, dan gunakan modul ketika kelas yang tidak berguna akan konyol.

Bundel TL; DR - metode tidak selalu buruk. Cobalah untuk menggunakan kelas instantiable terlebih dahulu. Kembali ke "modul" hanya bila diperlukan.

Mengambil contoh yang diberikan:

getMotorDataFromHTMLForm()
selectMotorFromUserRequirements($requirements)

Ini terlihat seperti metode "pabrik", yang akan mengembalikan Motorobjek. Yang kedua menyiratkan bahwa Anda sedang membuat objek baru untuk memenuhi persyaratan, atau Anda memiliki database atau koleksi motor dalam memori yang sedang Anda periksa. Dalam hal ini harus menjadi metode untuk itu. Atau bisa juga metode pada objek persyaratan.

getMotorManufacturers()

Dari mana Anda mendapatkannya? Itulah yang seharusnya menjadi metode.

canMotorCanHandleOperatingConditions($conditions)
computePowerConsumptionForMotor($id)

Ini sepertinya harus menjadi metode Motor.

Objek adalah kumpulan metode dan data yang memiliki kohesi tinggi. Mereka termasuk dalam kelas karena mereka sangat saling terkait dan negara dipertahankan.

Ini benar apakah Anda menggunakan desain depan yang besar dan mencoba memodelkan segalanya, atau desain yang muncul di mana Anda beralih dan mengembangkan objek menjadi apa pun yang sesuai dengan kebutuhan sistem pada saat itu.

Jika Anda tidak memiliki alasan untuk mempertahankan status, Anda mungkin tidak memiliki alasan untuk membuat instance objek yang berarti mungkin tidak ada alasan untuk memiliki kelas. Kecuali, bahasa yang Anda gunakan tidak memiliki kemampuan untuk mendefinisikan namespace selain menggunakan kelas. Di mana menggunakan kelas harus baik-baik saja karena akan idiomatik.

Saya tidak bisa memikirkan aspek negatif untuk menggunakan kelas dengan cara ini selain tipikal. Biaya dan kerumitan mengundang Anda yang tidak perlu dengan harus membuat instantiate "namespace". Siapa pun yang mendukung kode ini akan bertanya-tanya di mana data ini menambah beban kognitif tambahan (kemungkinan besar biaya satu kali per orang). Ini adalah penggunaan yang tidak biasa tanpa nilai tambahan.