Apa yang akan Anda lakukan jika klien Anda meminta Anda untuk tidak menggunakan pemrograman berorientasi objek?

Saya menulis sebuah program untuk mensimulasikan aktivitas semut dalam kotak (PDF). Semut dapat bergerak, mengambil barang-barang dan menjatuhkan barang-barang.

Masalahnya adalah sementara aksi semut dan posisi masing-masing semut dapat dilacak dengan atribut kelas dengan mudah (dan kami dapat dengan mudah membuat banyak contoh semut tersebut) klien saya mengatakan bahwa karena ia memiliki latar belakang dalam pemrograman fungsional ia ingin simulasi dibuat menggunakan pemrograman fungsional.

Agar jelas, kata-kata asli dari klien adalah "tidak ada kelas" saja, tetapi bukan "pemrograman fungsional". Jadi saya berasumsi dia tidak bermaksud pemrograman fungsional dan saya bisa melakukannya dengan keharusan. Selain itu, saya tidak memiliki pengalaman sebelumnya dalam pemrograman fungsional.

Namun, saya pikir itu bermanfaat untuk fokus pada pertanyaan ini menjadi terutama tentang persyaratan pemrograman fungsional daripada sekadar "melakukannya secara imperatif."

Bagaimana Anda menangani situasi ini? Apakah Anda mencoba meyakinkan klien Anda bahwa menggunakan pemrograman berorientasi objek jauh lebih bersih, mencoba mengikuti apa yang dia butuhkan dan memberinya kode berkualitas buruk, atau melakukan sesuatu yang lain?

Kode berorientasi objek bukan dengan pembersih definisi, dan sebaliknya kode non-OO bukan oleh definisi jelek. Meskipun tampaknya ada pemetaan berorientasi objek yang agak jelas untuk masalah khusus ini, saya akan menyarankan agar Anda mencoba pendekatan pemrograman fungsional. Berikan yang terbaik, cobalah untuk menyelesaikan masalah dengan gaya pemrograman fungsional terbaik yang dapat Anda kumpulkan, dan Anda mungkin hanya belajar sesuatu yang tidak Anda harapkan.

Anda menyebutkan bahwa klien biasa memprogram dalam bahasa fungsional, mungkin dia memiliki alasan bahwa dia mengharuskan Anda untuk menulis kode dengan gaya fungsional. Anda harus bertanya mengapa .

Mungkin dia berniat untuk menyimpan kode dan mempertahankannya sendiri nanti.

Selain itu, saya tidak berpikir dua pilihan adalah melakukannya dengan gaya OO atau menulis kode jelek seperti yang Anda sebutkan. Tentu saja menulis kode fungsional dalam contoh seperti ini bisa lebih sulit, terutama jika Anda hanya memiliki pengalaman dalam bahasa berorientasi objek, tetapi jika klien bersedia menunggu sedikit lebih lama bagi Anda untuk mendapatkan kecepatan dengan gaya fungsional maka itu tidak akan Tidak ada salahnya menanyakan itu padanya.

Saya akan bertanya kepadanya mengapa dia menginginkan kode dalam gaya fungsional dan jika waktu tidak begitu banyak masalah saya akan meminta beberapa hari ekstra untuk mempercepat dengan pemrograman fungsional. (Hore untuk dibayar untuk belajar!)

Jika semuanya gagal menjelaskan bahwa Anda akan membutuhkan waktu lebih sedikit untuk melakukannya dalam gaya OO.

Apakah Anda sadar bahwa pemrograman fungsional tidak hanya berarti "pemrograman tanpa kelas"?

Lihat artikel Wikipedia tentang itu untuk selengkapnya, tetapi singkatnya ...

Dalam ilmu komputer, pemrograman fungsional adalah paradigma pemrograman yang memperlakukan komputasi sebagai evaluasi fungsi matematika dan menghindari keadaan dan data yang bisa berubah. Ini menekankan penerapan fungsi, berbeda dengan gaya pemrograman imperatif, yang menekankan perubahan dalam keadaan.

Pemrograman fungsional adalah paradigma pemrograman, seperti OO adalah paradigma pemrograman.

Jika latar belakang Anda dalam OO, maka saya bisa melihat bagaimana Anda ingin semua semut Anda menjadi objek. Di sisi lain, jika Anda mensimulasikan peternakan semut dengan jutaan semut, OO dan penyampaian pesan mungkin menjadi tidak efisien.

Beruntung bagi Anda, Python memiliki alat yang luar biasa untuk pemrograman fungsional (yang paling penting adalah bahwa fungsinya adalah objek kelas satu).

Pemrograman fungsional Python HOWTO

Jelaskan kepada klien Anda bahwa jika ia menginginkan pemrograman fungsional, ia harus mempekerjakan seseorang yang berspesialisasi dalam hal itu. Pemrograman fungsional sangat berbeda dari OOP, dan Anda akan salah jika Anda berpikir Anda dapat dengan mudah mengambilnya dan memberikan solusi kompleks berkualitas tinggi.

Ada kesalahpahaman umum bahwa "OO" sepenuhnya bertentangan dengan "fungsional". Hal-hal ini dapat berjalan seiring dengan baik. Dalam contoh Anda, saya kira "Semut" dapat dimodelkan dengan baik sebagai tipe data abstrak, yang dapat langsung diimplementasikan menggunakan kelas dan objek. Transisi antara "Ant state" dapat dimodelkan secara alami menggunakan fungsi, yang akan mengarahkan Anda ke pendekatan fungsional sejauh kelas "Ant" Anda adalah tipe yang tidak dapat diubah.

Dan ketahuilah bahwa "objek" dapat dipertukarkan dengan konsep fungsional penutupan, karena objek adalah penutupan orang miskin adalah objek orang miskin adalah ... ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Setelah membicarakannya dengan klien, jika dia masih menginginkannya dengan caranya sendiri, Anda melakukan pekerjaan profesional, atau jika Anda tidak bisa, Anda juga tidak mengambil kontrak atau mencari jalan keluar dari itu.

Memproduksi "kode jelek" hanya karena Anda tidak setuju akan sangat tidak profesional.

1. Mengapa kita semua menganggap klien tahu perbedaan antara pemrograman fungsional dan imperatif? Banyak orang tidak tahu nama atau spesifikasi paradigma pemrograman non OO dan akan mudah bertukar istilah seperti "prosedural" "imperatif" dan "fungsional".

2. Jangan berjalan seperti yang orang lain katakan agar Anda jalan kecuali Anda yakin harus berjalan seperti itu. Karena itu, jika Anda tidak percaya pemrograman fungsional cocok maka jangan mengatur diri Anda untuk gagal atau mengambil proyek dengan setengah hati.

3. Jika klien menulis spec kemudian mengimplementasikan spec, jika tidak Anda menulis spec dan mengimplementasikan spec Anda .

4. Strategi terbaik untuk mempengaruhi keputusan klien adalah membuat opsi yang tidak diinginkan secara signifikan lebih mahal. Ini berfungsi setiap saat.

5. Jika Anda ahli (relatif terhadap klien), maka Anda harus dapat membujuk mereka.

6. Untuk benar-benar mengetahui apakah klien memiliki poin yang valid, Anda perlu mendapatkan lebih banyak pengalaman dengan pemrograman fungsional, baik sehingga Anda dapat menembaknya dengan percaya diri atau menyadari bahwa bias Anda terhadap OO adalah karena kurangnya pengalaman Anda.

7. Mengapa tidak melakukannya dengan dua cara lalu biarkan klien melihat kedua implementasi dan memutuskan mana yang lebih mudah untuk dipertahankan. Masukkan saja semua ini ke dalam perkiraan proyek Anda sehingga Anda dapat menikmati kurva belajar saat Anda dibayar.

Sebelum mengganggu lebih jauh, saya akan memastikan bahwa Anda berdua berbicara tentang hal yang sama. Anda bisa menanyakan kepadanya kapan perangkat lunak 'berorientasi objek' kepadanya. Karena dia mengatakan bahwa itu bukan keahlian utamanya sendiri, mungkin dia memiliki beberapa gagasan miring.

Misalnya, banyak orang dapat mempertimbangkan

class C {
public:
  C();
  void f( int );
  void g();
};

menjadi pendekatan berorientasi objek klasik, tetapi

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

tidak (meskipun keduanya sama-sama berorientasi objek sejauh definisi klasik "data bersama dengan fungsi yang beroperasi di atasnya").

Apakah Anda akan mencoba meyakinkan klien Anda bahwa menggunakan pemrograman berorientasi objek jauh lebih bersih?

Saya pikir Anda perlu mendidik diri sendiri lebih banyak tentang paradigma pemrograman. Kode terprogram Berorientasi Objek belum tentu lebih bersih, dan pada kenyataannya, itu tidak berlaku secara universal. Juga, seorang programmer berorientasi objek yang baik tahu bagaimana melakukan pekerjaan dengan baik menggunakan prosedural / modular (Dengan paradigma Fungsional dan Deklaratif, ini sedikit lebih sulit, tetapi seharusnya tidak terlalu sulit bagi programmer yang baik untuk datang - melalui membaca dan deduksi - untuk solusi FP / Deklaratif yang dapat diterima.)

Anda hampir tidak pernah bisa, saya ulangi, Anda hampir tidak bisa memiliki pemahaman yang baik tentang kapan dan bagaimana menggunakan Orientasi Objek tanpa memiliki pemahaman yang baik tentang pemrograman prosedural dan modular. OO jauh lebih dari sekadar mendeklarasikan kelas dan hierarki warisan.

Atau akankah Anda mencoba mengikuti apa yang dia butuhkan dan memberinya kode jelek?

Jika Anda tidak dapat menulis kode yang baik secara prosedural, saya ragu Anda dapat menulis kode yang baik dengan cara yang berorientasi objek. Periode. Saya tidak mencoba menghakimi di sini, tetapi ini harus ditegaskan.

Orientasi Objek adalah perpanjangan dari pemrograman prosedural dan modular. Object-Orientation hanya memberi Anda alat yang, ketika digunakan dengan tepat, memberi Anda mekanisme yang lebih baik untuk menangani enkapsulasi, penggabungan, kohesi, dan masalah penggunaan ulang / ekstensibilitas kode.

Tetapi semua masalah itu tidak melekat dan unik untuk OO. Mereka ada dalam kode prosedural / modular (dan dalam paradigma lain dalam hal ini.) Ini adalah jenis masalah kompleksitas yang, pada intinya, adalah paradigma-independen. Jika Anda tidak bisa menanganinya tanpa lem OO, maka kecil kemungkinan Anda bisa mengatasinya.

=========

Kembali ke pertanyaan awal Anda, apakah akan mencoba membujuk klien Anda. Tergantung. Seperti yang dikatakan poster Sean McMillan, jika klien hanya mencoba mengelola usaha pengembangan mikro untuk beberapa agenda (baca, politik kantor), menjauhlah. Orang yang melakukan itu menyabot proyek untuk menyalahkan orang lain, atau mendorong agenda tertentu. Anda tidak ingin terlibat dalam hal itu.

OTH, mungkin ada alasan lain untuk persyaratan seperti itu. Banyak toko tertanam, baik benar atau salah, memilih untuk menempatkan banyak kendala pada apa yang dapat Anda lakukan dengan C ++ (misalnya, tidak ada metode virtual, tanpa pengecualian,). Beberapa kali ini dilakukan dengan cara menyentak lutut. Terkadang, ada alasan teknis yang sah untuk melakukannya.

Jadi, Anda perlu memahami mengapa klien ingin menghindari kode OO. Dan jika Anda dapat menduga bahwa tidak ada agenda politik (tidak ada bendera merah), maka Anda harus melakukan hal yang profesional untuk dilakukan, yang hanya melakukan kode secara prosedural / modular, dan melakukan pekerjaan dengan baik.

Sebenarnya tidak ada alasan untuk memberikan kode jelek, terlepas dari paradigma pemrograman. Jika Anda tidak dapat menghasilkan kode yang dapat diterima dengan satu paradigma, Anda tentu saja tidak dapat menghasilkan kode yang dapat diterima secara umum.

Anda mencampuradukkan struktur data dan pemrograman berorientasi objek (kebingungan umum di dunia yang penuh dengan OO ini)

Jika semua yang perlu Anda lakukan adalah "melacak atribut data" dalam struktur data dan memodifikasinya, maka hampir semua bahasa yang dibuat setelah tahun 70-an akan memiliki dukungan yang baik untuk itu, OO atau tidak.

Hal-hal yang lebih mudah dilakukan di OO adalah roughfly

• Warisan berbasis kelas (mudah untuk membuat kelas baru yang berpura-pura menjadi yang lama)
• Polimorfisme berbasis kelas (mudah untuk menambahkan semut jenis baru ke dalam simulasi setelahnya)

Jika Anda tidak memiliki kebutuhan mendesak akan salah satu dari ini maka pada dasarnya paradigma pemrograman apa pun harus menyelesaikannya tanpa terlalu banyak masalah.

klien saya mengatakan bahwa karena dia memiliki latar belakang dalam pemrograman fungsional dia ingin simulasi dibuat menggunakan pemrograman fungsional.

(Ini adalah contoh lain dari masalah sosial yang dikira sebagai masalah teknis / desain.)

Ada dua kemungkinan di sini:

1. Klien Anda mengharapkan untuk dapat mengambil kode yang Anda tulis dan mengadaptasi atau mempertahankannya sendiri setelah Anda selesai menulisnya. Jika demikian, Anda harus tahu lebih banyak tentang "gaya rumah" - fungsional vs OO hanya merupakan puncak gunung es. Anda perlu membatasi diri pada gaya pemrograman yang dipahami klien Anda, atau Anda perlu mendidik klien Anda dengan gaya yang Anda inginkan. (Suatu ketika, saya diminta untuk membangun aplikasi web dengan CGI, tanpa menggunakan templating atau pustaka karena klien mungkin ingin membuat perubahan.)

2. Klien Anda mencoba mengendalikan pengembangan karena beberapa agenda. Ini adalah tas penuh gila yang tidak ingin Anda lakukan. Jika Anda benar-benar memberikan perangkat lunak "turnkey", klien tidak akan peduli apakah itu terbuat dari hamster yang berjalan di atas roda, asalkan itu melakukan pekerjaan dengan andal. Membiarkan diri Anda dikelola secara mikro dengan cara ini hanya meminta rasa sakit.

Terserah Anda untuk memutuskan situasi yang Anda hadapi, dan bertindak sesuai.

Umm ... apakah saya satu-satunya di sini yang berpikir "ini jelas merupakan tes / tugas"? .

Pertama - penugasan itu sendiri bersifat "akademis" (mensimulasikan aspek perilaku semut).

Kedua - permintaan untuk mengimplementasikan persyaratan menggunakan (atau menghindari) paradigma pemrograman yang sangat spesifik dari "klien" yang dapat membaca kode dan membuat pernyataan seperti itu.

Jika demikian, Anda lebih baik melakukan apa yang diminta dari Anda - itu akan menjadi pengalaman belajar yang menyenangkan dan jika Anda bisa melakukannya, Anda akan belajar banyak dalam proses ...

Jika ini bukan masalahnya, Anda harus bertanya pada diri sendiri dan / atau pelanggan untuk alasan tentang penugasan tersebut. Jika alasannya kuat, maka lakukan - Anda akan belajar dan Anda akan lebih baik sebagai programmer untuk pengalaman itu. Siapa tahu - Anda bahkan mungkin belajar menyukai gaya fungsional di atas OO.

Jika penjelasannya kurang, maka semua taruhan dibatalkan .. Saya tidak bisa merekomendasikan Anda apa yang harus dilakukan.

Anda mungkin ingin mencoba terlepas dari menerapkan persyaratan dalam bahasa fungsional / gaya atau Anda mungkin dengan sopan menolak tawaran jika Anda merasakan sesuatu yang mencurigakan.

Hal utama adalah - setelah Anda memahami motivasi di balik persyaratan, tindakan yang tepat menjadi jelas.

EDIT: Setelah melihat diagonal pada PDF yang direferensikan, algoritma yang dijelaskan di sana sepertinya cocok untuk gaya fungsional daripada OO

Ada beberapa aspek yang baik dalam permintaan mereka untuk menggunakan pemrograman fungsional:

1. Anda punya klien, itu pertanda baik
2. Klien mengharapkan Anda menjadi sangat baik pada apa yang Anda lakukan. Inilah sebabnya mereka meminta pemrograman fungsional. Jadi organisasi penjualan Anda melakukan pekerjaan dengan baik atau Anda meminta harga yang sangat tinggi untuk layanan Anda.
3. Organisasi klien memiliki beberapa orang yang tahu pemrograman fungsional adalah hal yang baik dan akan menjadi besar di masa depan

Tetapi ada beberapa tanda yang mengkhawatirkan juga:

1. Anda sepertinya tidak siap untuk mengimplementasikannya dalam pemrograman fungsional. Anda sudah sedikit ketinggalan jaman dalam keterampilan Anda dan tidak bisa mengikuti perubahan.
2. Atau klien mengharapkan Anda untuk menjadi programmer yang lebih baik daripada yang sebenarnya. Ini berarti Anda mungkin perlu menurunkan persyaratannya hingga Anda dapat melakukannya dengan benar.

Menanggapi tanggapan di atas yang mungkin OO bukan solusi terbaik dalam hal klien mungkin ada benarnya.

Lihatlah Tantangan AI yang memodelkan beberapa perilaku yang dirinci dalam pertanyaan di sini http://aichallenge.org dan kemudian lihat berbagai paket pemula - http://aichallenge.org/starter_packages.php/ most adalah bahasa yang tidak akan saya tempatkan dalam paradigma OO.

Anda tidak menulis apa pun tentang bahasa pemrograman, yang mungkin merupakan hal terpenting di sana. Perbedaan antara OOP dan pemrograman fungsional bukan hanya cara kode diatur tetapi bahasa itu sendiri. Ketika konkurensi tinggi terjadi, bahasa fungsional Erlang sedang digunakan, dan memiliki keunggulan yang sangat tinggi di atas misalnya Java (digunakan misalnya oleh obrolan Facebook). Solusi OOP bisa saja gagal karena masalah kinerja.

Klien di sini adalah universitas, jadi bahasa tidak hanya masalah kinerja / konfigurasi, kode ini juga dapat digunakan untuk pekerjaan didaktik dengan siswa atau penelitian sendiri. Jadi 'membujuk' klien untuk memilih paradigma lain menurut saya tidak berlaku di sini. Ini adalah salah satu dari Anda dapat menangani tugas atau Anda tidak bisa (dan karenanya, Anda tidak boleh mengambil proyek itu).

Klien mengatakan "melompat", jawaban Anda adalah: __ _ ?

Bagi saya, saya akan berusaha meyakinkan jika itu masuk akal (proyek baru), tapi saya juga punya klien dengan aplikasi VB6 lama 10 tahun yang saya perbarui sesekali ... tidak akan meyakinkan mereka untuk

'Silang Periksa' klien Anda sedikit (dengan cara yang tidak konfrontatif):

Apakah klien benar-benar mengetahui perbedaan antara OOP dan pemrograman fungsional? Apakah kekhawatiran / permintaan klien itu sah?

Jika 'Ya': Jika Anda memenuhi syarat, lakukan apa yang mereka inginkan dan ambil uang Anda. Jika Anda tidak memenuhi syarat, beri tahu mereka dan biarkan mereka memutuskan apa yang harus dilakukan.

Lain: hi-tail itu keluar dari sana!

double dist(Point p1, Point p2) 
{
  //return distance
}

Fungsi ini berfungsi selama tidak membaca / menulis apa pun di luar fungsi. Jika fungsi menyentuh variabel kelas itu tidak akan lagi menjadi "fungsional". Keuntungan dari gaya fungsional adalah tidak ada lagi bug dari perubahan atau keadaan tidak valid. Sejumlah besar fungsi hanyalah rumus matematika. Singkatnya, pemrograman fungsional.

BTW Anda dapat menggabungkan gaya fungsional dalam desain berbasis objek atau berorientasi. Sebagai contoh, dua variabel "Point" adalah objek dengan status. Dan fungsinya masih fungsional! Yay !!