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


31

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?


9
Satu hal yang mungkin berubah pikiran, adalah jika biaya Anda melakukannya lebih tinggi (jika Anda lebih mahir dalam bahasa OO daripada bahasa pemrograman fungsional).
Holger

Mungkin menarik untuk membandingkan kode simulasi semut Rich Hickey ( gist.github.com/1093917 ) - di Clojure jadi pada dasarnya fungsional meskipun simulasi ini terutama dirancang untuk menunjukkan penggunaan STM.
mikera

13
Komentator: Jangan tinggalkan jawaban di sini di komentar. Tulis jawaban Anda sendiri. Komentar bukanlah tempat untuk membahas berbagai kemungkinan jawaban untuk pertanyaan: ajukan saran Anda sebagai jawaban atau bawa untuk mengobrol untuk menyempurnakannya terlebih dahulu.

6
Hanya ingin memastikan Anda melihat poin N3dst4 bahwa "pemrograman fungsional" adalah disiplin pemrograman tertentu. Pemrograman yang tidak berorientasi objek biasanya digambarkan sebagai "pemrograman prosedural".
DJClayworth

1
Menurut Anda mengapa implementasi berorientasi objek akan "jauh lebih bersih"? Kemungkinan besar itu akan jauh lebih mudah dibaca daripada solusi fungsional yang tepat.
SK-logic

Jawaban:


201

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.


83
+1 untuk "Anda mungkin belajar sesuatu yang tidak Anda harapkan"!
Kenneth

2
Juga, Pemrograman Berorientasi Data memang memungkinkan kinerja yang sangat baik karena ramah terhadap cache dan lebih baik diimplementasikan dalam set fungsi yang memproses blok data. Tampaknya cocok untuk masalah yang sedang Anda kerjakan. Saya tidak tahu bagaimana ini berlaku untuk pemrograman fungsional tetapi saya kira itu membantu lebih dari itu menyakitkan.
Klaim

8
Memberi +1 untuk "Anda mungkin belajar sesuatu yang tidak Anda harapkan"!, TETAPI: Jika OP tidak memiliki banyak pengalaman dalam pemrograman fungsional dan klien mengharapkan solusi yang baik dan murah, akan lebih berisiko untuk terjun ke dalam cara baru untuk memecahkan masalah.
mort

3
@mort - Klien dalam hal ini menginginkan sesuatu yang khusus, terdengar seperti mereka cukup tahu untuk benar-benar mengetahui apa yang mereka inginkan, jadi jika orang yang mereka sewa tidak bisa melakukannya, itu masalah mereka. Saya kira apa yang saya katakan adalah fakta bahwa klien menginginkan sesuatu yang "baik dan murah" dan mengatakan mereka merekrut orang yang salah yang tidak dapat memberikan itu, itu adalah kesalahan klien, bukan kesalahan penulis ia tidak tahu bagaimana memberikan yang murah dan solusi pemrograman fungsional yang baik untuk masalah ini. Salah satu yang layak penulis coba berikan apa yang diinginkan klien, karena tidak ada alasan teknis untuk tidak melakukannya.
Ramhound

2
Tidak ada dalam pertanyaan di mana OP mengatakan kata-kata "baik dan murah". Keinginan itu bisa "Cepat dan baik" (dari ketiganya: cepat, bagus, murah). Semua itu tidak relevan, tanpa panduan OP, karena "Spesifikasi" mengatakan "Gunakan Pemrograman Fungsional".
WernerCD

68

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.


@ downvoter, bisakah Anda memberikan umpan balik?
Thanos Papathanasiou

3
Saya mengerti bahwa notasi dr layak downvote, untuk beberapa
Independen

1
Apakah ada sesuatu di FAQ atau halaman bantuan di mana saja yang memperingatkan penggunaan "tl; dr"? Atau hanya beberapa pengguna nakal yang tidak menyukainya? Menurut saya menambahkan ringkasan ringkas dari jawaban hanya bisa menjadi hal yang baik, jadi saya tidak bisa membayangkan mengapa ini dianggap layak untuk downvote.
Ben Lee

1
@ Awal Saya pikir tl; notasi dr adalah untuk pengguna yang mencoba membaca jawaban saya. Artinya bahkan jika Anda melewatkan semua sisanya, jika Anda baru saja membaca ini maka Anda mendapatkan inti dari jawabannya. Apa maksud Anda dengan apa yang Anda katakan?
Thanos Papathanasiou

1
Beberapa dari kita, orang tua tidak tahu apa artinya; dr (saya memang mencarinya tetapi mengapa ada orang yang menggunakan omong kosong samar seperti itu?)
HLGEM

55

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


+1 untuk menuliskan ini. Itu benar-benar harus diklarifikasi dalam pertanyaan.
Bratch

Tahukah Anda bahwa Anda dapat memiliki bahasa yang OO dan fungsional? Itu adalah dua prinsip pengorganisasian yang sebenarnya sebagian besar ortogonal satu sama lain. Memang banyak bahasa OO juga merupakan bahasa imperatif terstruktur, tetapi tidak ada dasar teoritis untuk menggabungkannya dengan kuat.
Donal Fellows

@DonalFellows Tentu saja, ini adalah poin bagus bahwa keduanya sama sekali tidak eksklusif. Python (karena pertanyaan awalnya ditandai Python) sangat penting, berorientasi objek, dan fungsional, tergantung di mana Anda berdiri ketika Anda melihatnya. Dan di bagian lain halaman ini seseorang menyebut OCaml, yang merupakan OO dan fungsional.
N3dst4

22

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.


Setuju. Itu hanya akal sehat yang diterapkan.
Tuan Smith

1
Masalahnya adalah, dari perspektif bisnis, tidak selalu mudah untuk mengakui kurangnya pengetahuan Anda kepada pelanggan ("Anda sebaiknya merekrut seseorang yang akrab dengan pemrograman fungsional sebagai gantinya"). Lebih mudah untuk mengklaim OOP lebih baik, hanya karena Anda sudah terbiasa dengannya. Kurang jujur , tapi lebih mudah.
Andres F.

@Andres F: Berurusan dengan bahasa baru (dan paradigma) tidak mudah sama sekali. Cepat atau lambat, klien harus mempertimbangkan kembali masalahnya. Lebih baik segera daripada nanti.
Tuan Smith

4
@ Tuan Smith: Saya sepenuhnya setuju dengan Anda. Saya hanya mengatakan kejujuran semacam ini dari provider (yaitu programmer) tidak selalu akan muncul. Pada dasarnya Anda memberitahu pelanggan untuk mempekerjakan orang lain, yang masuk akal di dunia, tetapi tetap saja menyakitkan.
Andres F.

13

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


+1 Pemrograman fungsional dan OOP adalah konsep ortogonal. Lihatlah OCaml, Scala, Clojure, python untuk bahasa yang dapat menangani keduanya.
rds

Kedua tautan itu layak mendapat dukungan suara saja ...
Wayne Werner

8

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.


8
  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.


+1 untuk "Mengapa kita semua menganggap klien mengetahui perbedaan antara pemrograman fungsional dan imperatif?". Klien bisa berarti sesuatu seperti "Saya tidak ingin itu berulang, jadi pisahkan semuanya menjadi fungsi", yang masuk akal bagi pengembang. Seorang klien mungkin tidak berpikir itu masuk akal, jadi dia memberi tahu Anda.
AlexWebr

1
+1, pada kenyataannya klien tidak tahu apa itu pemrograman Fungsional yang didorong oleh kata-kata buzz terbaru atau karena mereka melakukannya dua puluh tahun yang lalu dan masih menganggap diri mereka sebagai teknis.
Jenis Anonim

5

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").


2
Mengapa berdebat tentang arti tepat dari OOP? Akan lebih baik untuk bertanya mengapa pelanggan berpikir simulasinya lebih cocok untuk pemrograman fungsional. Pelanggan mungkin benar ... Saya benar-benar ragu dengan "fungsional" yang ia maksudkan sebagai contoh C kedua Anda, atau bahwa ia membingungkan "fungsional" dengan "keharusan".
Andres F.

@Andres F .: Saya tidak mengklaim bahwa dengan 'fungsional' yang ia maksudkan adalah contoh C kedua saya. Saya baru saja menunjukkan bahwa beberapa orang menganggapnya sebagai OOP sementara yang lain tidak. Jadi sebelum memulai pertengkaran, ada baiknya menghindari kesalahpahaman. Mungkin tidak ada perselisihan di tempat pertama. Mungkin bos, karena dia mengatakan bahwa dia tidak terbiasa dengan OOP sendiri, mengasumsikan bahwa OOP memiliki sifat-sifat tertentu (seperti OP yang tampaknya menganggap pemrograman fungsional memiliki sifat-sifat tertentu).
Frerich Raabe

Sebenarnya, saya tidak akan menganggap yang terakhir menjadi OOP karena metode panggilan / pengiriman pesan tidak dialihkan melalui objek. Itu fitur utama dari OOP.
Donal Fellows

5

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.


3

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.


Saya akan menambahkan bahwa bahasa pemrograman fungsional dengan dukungan untuk polimorfisme harus membuatnya cukup mudah untuk menulis gaya berorientasi objek atau pseudo-objek berorientasi yang memungkinkan Anda untuk dengan mudah menambahkan jenis semut baru.
Marcin

@ Marsin: memang benar bahwa bahasa FP modern cukup kuat. Saya hanya benar-benar ingin menunjukkan perbedaan antara data-structurs / ADTs dan OO
hugomg

Tapi OO benar-benar hanya ADT ditambah metode pengiriman objek-dikendalikan. Semuanya dibangun di atas itu. (Yah, seringkali satu-satunya kontrol oleh objek atas pengiriman adalah dengan jenis objek, tapi itu penyempurnaan.)
Donal Fellows

3

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.


3

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


2

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.

-1 untuk asumsi implisit bahwa FP lebih baik daripada OOP.
Russell Borogove

@ tp1 1) Anda menganggap klien secara teknis lebih pintar daripada programmer, yang bukan merupakan masalah karena klien hanya klien. 2) FP lebih tua dari OOP dan saat ini mendapatkan banyak pers akhir-akhir ini, tidak ada yang salah dengan OOP dan Anda tidak perlu lupa untuk menggunakan FP 3) Bagian yang lebih buruk dari ini adalah menganggap FP lebih baik dan menggunakan FP menjadikan Anda seorang programmer yang lebih baik, hanya benar dalam kasus per kasus dan dalam kasus ini yang tampaknya tidak benar.
Joe Tyman

@ Jooe Tyman: Yah, harus ada asumsi bahwa orang tidak bodoh, atau klien hilang dalam sekejap. Saya tidak mencoba mengatakan oop itu buruk atau lebih buruk, tetapi menganggap bahwa fungsional mungkin merupakan persyaratan yang tidak masuk akal dalam situasi ini - mungkin klien tidak mengetahui keterampilan programmer, atau lebih buruk lagi, mencoba membuat programmer mengganti teknologi mereka.
tp1

@ Jooe Tyman: Juga, skenario terburuk yang ada dalam pikiran saya adalah bahwa klien benar-benar membutuhkan orang yang dapat melakukan beberapa pemrograman fungsional tingkat lanjut seperti teori kategori, dan mereka berusaha mencari tim yang dapat melakukannya - inilah sebabnya permintaan karena mereka bisa jadi tidak masuk akal.
tp1

1

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.


1

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).


0

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


secara teknis meskipun aplikasi VB6 baik-baik saja, hampir OO, dan jika berfungsi dengan baik pada OS saat ini mengapa "upgrade" ke .NET. Itu tidak masuk akal kecuali Anda ingin memanfaatkan fungsionalitas baru.
Jenis Anonim

Ya tetapi apakah Anda sudah mencoba menggunakan vb6 belakangan ini? itu sangat menyakitkan;)
boomhauer

Ya. Kami menggunakan banyak untuk mempertahankan aplikasi yang ada yang belum diberi anggaran untuk pembaruan ke java atau .net. Ini menyakitkan (dibandingkan dengan IDE modern) tetapi juga relatif. Seperti bahasa apa pun (termasuk skrip) setelah Anda mahir melakukannya, definisi Anda tentang rasa sakit menjadi lebih subjektif.
Jenis Anonim

0

'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!


0
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 !!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.