คุณจะทำอย่างไรถ้าลูกค้าของคุณไม่ต้องการใช้การเขียนโปรแกรมเชิงวัตถุ

ฉันกำลังเขียนโปรแกรมเพื่อจำลองกิจกรรมของมดในกริด (PDF) มดสามารถเคลื่อนที่ไปรอบ ๆ หยิบสิ่งของและวางสิ่งของได้

ปัญหาคือในขณะที่การกระทำของมดและตำแหน่งของมดแต่ละตัวนั้นสามารถติดตามได้โดยแอตทริบิวต์ของคลาสได้อย่างง่ายดาย (และเราสามารถสร้างมดหลายตัวได้อย่างง่ายดาย) ลูกค้าของฉันบอกว่าเนื่องจากเขามีพื้นหลังในการเขียนโปรแกรมการทำงาน การจำลองที่จะทำโดยใช้การโปรแกรมเชิงฟังก์ชัน

เพื่อให้ชัดเจนคำดั้งเดิมจากลูกค้าคือ "no class" เท่านั้น แต่ไม่ใช่ "Programming programming" ดังนั้นฉันคิดว่าเขาไม่ได้หมายถึงการเขียนโปรแกรมการทำงานและฉันสามารถทำมันได้อย่างจำเป็น นอกจากนี้ฉันไม่เคยมีประสบการณ์การเขียนโปรแกรมฟังก์ชั่นมาก่อน

อย่างไรก็ตามฉันคิดว่ามันมีประโยชน์ที่จะมุ่งเน้นไปที่คำถามนี้โดยเฉพาะอย่างยิ่งเกี่ยวกับความต้องการการเขียนโปรแกรมการทำงานมากกว่าเพียงแค่ "ทำมันจำเป็น"

คุณจะรับมือกับสถานการณ์นี้อย่างไร คุณลองชักชวนลูกค้าของคุณว่าการใช้การเขียนโปรแกรมเชิงวัตถุนั้นสะอาดกว่าหรือไม่ลองทำตามที่เขาต้องการและให้รหัสที่มีคุณภาพต่ำแก่เขาหรือทำอย่างอื่น?

รหัสเชิงวัตถุไม่ใช่โดยตัวล้างข้อกำหนดและรหัสที่ไม่ใช่ OO ตรงกันข้ามไม่ได้หมายถึงตัวเส็งเคร็ง ในขณะที่ดูเหมือนว่าจะมีการแมปเชิงวัตถุค่อนข้างชัดเจนกับปัญหานี้ฉันขอแนะนำให้คุณลองใช้วิธีการเขียนโปรแกรมการทำงานต่อไป ให้ภาพที่ดีที่สุดของคุณพยายามที่จะแก้ปัญหาในรูปแบบการเขียนโปรแกรมการทำงานที่ดีที่สุดที่คุณสามารถรวบรวมและคุณอาจเรียนรู้สิ่งที่คุณไม่ได้คาดหวัง

คุณพูดถึงว่าลูกค้าที่ใช้ในการเขียนโปรแกรมในภาษาการทำงานบางทีเขาอาจมีเหตุผลที่เขาต้องการให้คุณเขียนรหัสในรูปแบบการทำงาน คุณควรถามเขาว่าทำไม

บางทีเขาอาจตั้งใจที่จะเก็บรหัสและรักษามันไว้ในภายหลัง

ยิ่งกว่านั้นฉันไม่คิดว่าทั้งสองตัวเลือกนั้นทำในลักษณะ OO หรือเขียนรหัสเส็งเคร็งตามที่คุณพูดถึง แน่นอนว่าการเขียนโค้ดที่ใช้งานได้ในตัวอย่างเช่นนี้อาจเป็นเรื่องยากโดยเฉพาะอย่างยิ่งถ้าคุณมีประสบการณ์ในภาษาเชิงวัตถุ แต่ถ้าลูกค้ายินดีที่จะรออีกเล็กน้อยเพื่อให้คุณได้รับความเร็วที่เพิ่มขึ้นด้วยสไตล์การทำงาน เจ็บที่จะถามเขาว่า

ฉันจะถามเขาว่าทำไมเขาถึงต้องการโค้ดในรูปแบบการใช้งานและถ้าเวลาไม่เป็นปัญหาฉันจะขอเวลาพิเศษเพิ่มเพื่อเร่งความเร็วด้วยการตั้งโปรแกรมการทำงาน (ไชโยสำหรับการรับเงินเพื่อเรียนรู้!)

หากทุกคนล้มเหลวอธิบายว่ามันจะใช้เวลาคุณน้อยลงในการทำมันในสไตล์ OO

คุณทราบหรือไม่ว่าการเขียนโปรแกรมใช้งานไม่ได้หมายถึง "การเขียนโปรแกรมโดยไม่มีคลาส" เท่านั้น?

ดูบทความ Wikipedia เกี่ยวกับเรื่องนี้สำหรับ schtick เต็มรูปแบบ แต่ในระยะสั้น ...

ในวิทยาการคอมพิวเตอร์การเขียนโปรแกรมเชิงการทำงานเป็นกระบวนทัศน์การเขียนโปรแกรมที่ปฏิบัติกับการคำนวณเป็นการประเมินฟังก์ชั่นทางคณิตศาสตร์และหลีกเลี่ยงข้อมูลสถานะและไม่แน่นอน มันเน้นการประยุกต์ใช้ฟังก์ชั่นในทางตรงกันข้ามกับรูปแบบการเขียนโปรแกรมจำเป็นซึ่งเน้นการเปลี่ยนแปลงในรัฐ

ฟังก์ชั่นการเขียนโปรแกรมเป็นกระบวนทัศน์การเขียนโปรแกรมเช่นเดียวกับ OO เป็นกระบวนทัศน์การเขียนโปรแกรม

หากพื้นหลังของคุณอยู่ใน OO ฉันจะเห็นได้ว่าคุณต้องการให้มดทั้งหมดของคุณเป็นวัตถุอย่างไร ในทางตรงกันข้ามถ้าคุณจำลองฟาร์มมดที่มีมดนับล้านตัว OO และการส่งข้อความอาจไม่มีประสิทธิภาพ

โชคดีสำหรับคุณ Python มีเครื่องมือที่ยอดเยี่ยมสำหรับการเขียนโปรแกรมการทำงาน (สิ่งที่สำคัญที่สุดคือการที่ฟังก์ชั่นนั้นเป็นวัตถุชั้นหนึ่ง)

Python การเขียนโปรแกรมการทำงาน HOWTO

อธิบายกับลูกค้าของคุณว่าถ้าเขาต้องการโปรแกรมที่ใช้งานได้เขาควรจ้างคนที่มีความเชี่ยวชาญในเรื่องนั้น การเขียนโปรแกรมฟังก์ชั่นแตกต่างจาก OOP มากและคุณจะเข้าใจผิดถ้าคุณคิดว่าคุณสามารถหยิบมันมาและนำเสนอโซลูชันที่ซับซ้อนที่มีคุณภาพสูงได้อย่างง่ายดาย

มีความเข้าใจผิดว่า "OO" นั้นตรงกันข้ามกับ "หน้าที่" อย่างสมบูรณ์ สิ่งเหล่านี้สามารถไปจับมือกันได้เป็นอย่างดี ในตัวอย่างของคุณฉันเดาว่า "มด" สามารถทำตัวเป็นแบบข้อมูลนามธรรมได้ซึ่งสามารถนำไปใช้งานได้โดยตรงโดยใช้คลาสและวัตถุ ช่วงการเปลี่ยนภาพระหว่าง "Ant states" สามารถสร้างแบบจำลองโดยใช้ฟังก์ชั่นตามธรรมชาติซึ่งจะนำคุณไปสู่แนวทางการทำงานเท่าที่คลาส "Ant" ของคุณเป็นประเภทที่ไม่เปลี่ยนรูป

และโปรดทราบว่า "วัตถุ" สามารถเปลี่ยนได้โดยแนวคิดการทำงานของการปิดเนื่องจากวัตถุคือการปิดของคนยากจนเป็นวัตถุของคนยากจนคือ ... ;-):

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. เหตุใดเราทุกคนจึงสมมติว่าลูกค้ารู้ถึงความแตกต่างระหว่างฟังก์ชั่นการทำงานและการเขียนโปรแกรมที่จำเป็น ผู้คนจำนวนมากไม่รู้ชื่อหรือลักษณะเฉพาะของกระบวนทัศน์การโปรแกรมมิใช่ OO และจะแลกเปลี่ยนคำเช่น "ขั้นตอน" "คำสั่ง" และ "หน้าที่" ได้อย่างง่ายดาย

2. อย่าเดินตามที่คนอื่นบอกให้คุณเดินเว้นแต่คุณเชื่อว่าคุณควรเดินไปทางนั้น ดังนั้นหากคุณไม่เชื่อว่าการเขียนโปรแกรมฟังก์ชั่นนั้นเหมาะสมแล้วอย่าตั้งค่าตัวเองให้ล้มเหลวหรือทำโครงการครึ่งใจ

3. หากลูกค้าเขียน spec แล้วใช้ spec หรือคุณเขียน spec และใช้spec ของคุณ

4. กลยุทธ์ที่ดีที่สุดที่มีอิทธิพลต่อการตัดสินใจของลูกค้าคือการทำให้ตัวเลือกที่ไม่พึงประสงค์มีราคาแพงกว่าอย่างมาก มันใช้งานได้ทุกครั้ง

5. หากคุณเป็นผู้เชี่ยวชาญ (สัมพันธ์กับลูกค้า) คุณควรจะสามารถโน้มน้าวใจพวกเขาได้

6. เพื่อที่จะทราบว่าไคลเอนต์มีจุดที่ถูกต้องหรือไม่คุณจำเป็นต้องได้รับประสบการณ์มากขึ้นด้วยการเขียนโปรแกรมการทำงานเพื่อให้คุณสามารถยิงมันลงด้วยความมั่นใจหรือรู้ว่าอคติของคุณที่มีต่อ OO นั้นเป็นเพราะขาดประสบการณ์

7. ทำไมไม่ทำทั้งสองวิธีจากนั้นให้ลูกค้าเห็นการใช้งานทั้งสองและตัดสินใจที่จะรักษาง่ายกว่า เพียงนำปัจจัยทั้งหมดนี้ไปใส่ในประมาณการโครงการของคุณเพื่อให้คุณสามารถเพลิดเพลินกับช่วงการเรียนรู้ในขณะที่คุณได้รับเงิน

ก่อนที่จะรบกวนใด ๆ เพิ่มเติมฉันจะทำให้แน่ใจว่าคุณทั้งคู่กำลังพูดถึงสิ่งเดียวกัน คุณสามารถถามเขาเมื่อซอฟต์แวร์เป็น 'เชิงวัตถุ' กับเขา ซายน์เขาบอกว่ามันไม่ใช่ความเชี่ยวชาญหลักของเขาเองมันอาจเป็นไปได้ว่าเขามีความคิดที่เบ้

ตัวอย่างเช่นหลายคนอาจพิจารณา

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

ที่จะเป็นวิธีการเชิงวัตถุคลาสสิก แต่

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

ไม่ใช่ (ถึงแม้ว่าทั้งคู่จะให้ความสำคัญกับวัตถุเท่าที่ข้อมูล "คลาสสิกพร้อมกับฟังก์ชั่นที่ทำงานกับมัน" คำจำกัดความไป)

คุณพยายามชักชวนลูกค้าของคุณว่าการใช้การเขียนโปรแกรมเชิงวัตถุนั้นสะอาดกว่าหรือไม่?

ฉันคิดว่าคุณต้องให้ความรู้เพิ่มเติมเกี่ยวกับกระบวนทัศน์การเขียนโปรแกรม รหัสโปรแกรมเชิงวัตถุไม่จำเป็นต้องสะอาดกว่าและในความเป็นจริงมันไม่สามารถใช้ได้ในระดับสากล นอกจากนี้โค้ดอ็อบเจกต์เชิงวัตถุที่ดียังรู้วิธีการทำงานที่ดีโดยใช้โพรซีเดอร์ / โมดุล (ด้วยกระบวนทัศน์เชิงฟังก์ชันและการประกาศมันค่อนข้างยาก แต่มันไม่ควรยากเกินไปสำหรับโปรแกรมเมอร์ที่ดีที่จะมาถึง - ผ่านการอ่านและการหัก - สำหรับโซลูชัน FP / Declarative ที่ยอมรับได้)

คุณแทบจะไม่เคยทำซ้ำฉันแทบจะไม่มีความเข้าใจที่ดีเกี่ยวกับเวลาและวิธีการใช้การวางแนววัตถุโดยไม่ต้องมีความเข้าใจที่ดีเกี่ยวกับขั้นตอนและการเขียนโปรแกรมแบบแยกส่วน OO เป็นมากกว่าการประกาศคลาสและลำดับชั้นการสืบทอด

หรือคุณจะลองทำตามสิ่งที่เขาต้องการและให้รหัสเส็งเคร็งกับเขา?

หากคุณไม่สามารถเขียนโค้ดที่ดีได้ฉันสงสัยว่าคุณสามารถเขียนโค้ดที่ดีในลักษณะเชิงวัตถุได้ ระยะเวลา ฉันไม่ได้พยายามตัดสินที่นี่ แต่สิ่งนี้จะต้องได้รับการยืนยัน

การวางแนววัตถุเป็นส่วนขยายของการเขียนโปรแกรมตามขั้นตอนและแบบแยกส่วน การจัดวางวัตถุนั้นให้เครื่องมือที่เมื่อคุณใช้อย่างเหมาะสมจะช่วยให้คุณมีกลไกที่ดีขึ้นในการจัดการการห่อหุ้มข้อต่อการเชื่อมต่อการทำงานร่วมกันและปัญหาการใช้ซ้ำ / การขยายโค้ด

แต่ปัญหาทั้งหมดนั้นไม่ได้มีอยู่ในตัวและเป็นเอกลักษณ์ของ OO พวกเขามีอยู่ในรหัสขั้นตอน / โมดูลาร์ (และในกระบวนทัศน์อื่น ๆ สำหรับเรื่องนี้) นี่คือประเภทของปัญหาความซับซ้อนที่ในหลักของมันคือกระบวนทัศน์ที่เป็นอิสระ หากคุณไม่สามารถจัดการกับมันได้โดยไม่ต้องใช้กาว OO คุณไม่สามารถจัดการกับมันได้

=========

กลับไปที่คำถามดั้งเดิมของคุณว่าจะพยายามโน้มน้าวลูกค้าของคุณหรือไม่ มันขึ้นอยู่กับ. ดังที่โปสเตอร์ Sean McMillan กล่าวถ้าลูกค้าเพียงแค่พยายามจัดการกับความพยายามในการพัฒนาสำหรับบางวาระ (อ่านการเมืองในสำนักงาน) ให้เดินออกไป คนที่ทำโครงการก่อวินาศกรรมนั้นจะโทษคนอื่นหรือผลักดันวาระใดวาระหนึ่ง คุณไม่ต้องการมีส่วนร่วมในเรื่องนั้น

OTH อาจมีเหตุผลอื่นสำหรับข้อกำหนดดังกล่าว ร้านค้าฝังตัวหลายแห่งไม่ว่าจะถูกหรือผิดเลือกที่จะวางข้อ จำกัด มากมายกับสิ่งที่คุณสามารถทำได้ด้วย C ++ (ไม่มีวิธีการเสมือนไม่มีข้อยกเว้นเป็นต้น) บางครั้งก็ทำในลักษณะที่กระตุกเข่า บางครั้งมีเหตุผลทางเทคนิคที่ถูกต้องสำหรับการทำเช่นนั้น

ดังนั้นคุณต้องเข้าใจว่าทำไมลูกค้าต้องการหลีกเลี่ยงรหัส OO และถ้าคุณสามารถคาดเดาได้ว่าไม่มีระเบียบวาระทางการเมือง (ไม่มีธงสีแดง) คุณควรทำสิ่งที่เป็นมืออาชีพที่จะทำซึ่งก็คือทำโค้ดที่เป็นขั้นตอน / โมดูล / และทำหน้าที่ได้ดี

ไม่มีข้อแก้ตัวสำหรับการส่งรหัสเส็งเคร็งเป็นอิสระจากกระบวนทัศน์การเขียนโปรแกรม หากคุณไม่สามารถสร้างรหัสที่ยอมรับได้ด้วยกระบวนทัศน์เดียวคุณจะไม่สามารถสร้างรหัสที่ยอมรับได้โดยทั่วไป

คุณกำลังผสมโครงสร้างข้อมูลและการเขียนโปรแกรมเชิงวัตถุ (ความสับสนที่พบบ่อยในโลกที่รบกวน OO นี้)

หากสิ่งที่คุณต้องทำคือ "ติดตามข้อมูลคุณลักษณะ" ในโครงสร้างข้อมูลและปรับเปลี่ยนพวกเขาแล้วเกือบทุกภาษาที่เกิดขึ้นหลังจากยุค 70 จะมีการสนับสนุนที่ดีสำหรับ OO หรือไม่

สิ่งที่ทำได้ง่ายกว่าใน OO คือคร่าวๆ

• การสืบทอดตามคลาส (ง่ายต่อการสร้างคลาสใหม่ที่อ้างว่าเป็นคลาสเก่า)
• ความหลากหลายตามคลาส (ง่ายต่อการเพิ่มมดชนิดใหม่ในการจำลองภายหลัง)

หากคุณไม่มีความต้องการเร่งด่วนในสิ่งเหล่านี้โดยทั่วไปแล้วกระบวนทัศน์การเขียนโปรแกรมใด ๆ ควรแก้ไขปัญหานี้โดยไม่มีปัญหามากเกินไป

ลูกค้าของฉันกล่าวว่าเนื่องจากเขามีพื้นหลังในการเขียนโปรแกรมการทำงานเขาต้องการจำลองที่จะทำโดยใช้การเขียนโปรแกรมการทำงาน

(นี่เป็นอีกตัวอย่างหนึ่งของปัญหาสังคมที่กำลังถูกเข้าใจผิดว่าเป็นปัญหาด้านเทคนิค / การออกแบบ)

มีสองความเป็นไปได้ที่นี่:

1. ลูกค้าของคุณคาดว่าจะสามารถใช้รหัสที่คุณเขียนและใช้งานหรือรักษามันเองหลังจากที่คุณเขียนเสร็จ ถ้าเป็นเช่นนั้นคุณควรรู้มากขึ้นเกี่ยวกับ "สไตล์บ้าน" - functional vs OO เป็นเพียงส่วนเล็ก ๆ คุณจะต้อง จำกัด รูปแบบการเขียนโปรแกรมที่ลูกค้าของคุณเข้าใจหรือคุณจะต้องให้ความรู้แก่ลูกค้าของคุณในรูปแบบที่คุณต้องการ (ครั้งหนึ่งฉันถูกขอให้สร้างแอปพลิเคชันเว็บด้วย CGI โดยไม่ต้องใช้การสร้างเทมเพลตหรือไลบรารี่เนื่องจากไคลเอนต์อาจต้องการเปลี่ยนแปลง)

2. ลูกค้าของคุณพยายามควบคุมการพัฒนาเนื่องจากมีบางวาระ นี่คือกระเป๋าที่เต็มไปด้วยความบ้าคลั่งที่คุณไม่ต้องการทำอะไร หากคุณให้บริการซอฟต์แวร์ "ครบวงจร" อย่างแท้จริงลูกค้าไม่ควรสนใจว่ามันทำจากแฮมสเตอร์ที่ทำงานบนล้อหรือไม่ตราบใดที่ทำงานได้อย่างน่าเชื่อถือ การอนุญาตให้ตัวคุณเองเป็น micromanaged ด้วยวิธีนี้เป็นเพียงการขอความเจ็บปวด

ขึ้นอยู่กับคุณที่จะตัดสินใจว่าคุณอยู่ในสถานการณ์ใดและดำเนินการตามนั้น

อืมมมฉันเป็นคนเดียวที่นี่ที่คิดว่า"นี่เป็นงานทดสอบ / การมอบหมายที่ชัดเจน" .

ประการแรก - การมอบหมายตัวเองเป็นชนิดของ "วิชาการ" ในธรรมชาติ (จำลองลักษณะของพฤติกรรมของมด)

ประการที่สอง - คำขอเพื่อดำเนินการตามข้อกำหนดโดยใช้ (หรือหลีกเลี่ยง) กระบวนทัศน์การเขียนโปรแกรมที่เฉพาะเจาะจงมากกลิ่นของ "ลูกค้า" ที่สามารถอ่านรหัสและยืนยันดังกล่าว

ถ้าเป็นกรณีนี้คุณควรทำสิ่งที่คุณต้องการดีกว่า - มันจะเป็นประสบการณ์การเรียนรู้ที่ดีมากและถ้าคุณทำได้คุณจะได้เรียนรู้มากมายในกระบวนการ ...

หากไม่เป็นเช่นนั้นคุณควรถามตัวเองและ / หรือลูกค้าเกี่ยวกับเหตุผลที่ได้รับมอบหมาย หากการใช้เหตุผลนั้นมั่นคงให้ทำ - คุณจะได้เรียนรู้และคุณจะดีขึ้นในฐานะโปรแกรมเมอร์สำหรับประสบการณ์ ใครจะรู้ - คุณอาจเรียนรู้ที่จะชอบสไตล์การใช้งานมากกว่า OO

หากคำอธิบายขาดหายไปการเดิมพันทั้งหมดจะปิด .. ฉันไม่สามารถแนะนำคุณได้ว่าควรทำอย่างไร

คุณอาจต้องการลองโดยไม่คำนึงถึงการใช้ข้อกำหนดในภาษา / สไตล์การใช้งานหรือคุณอาจปฏิเสธข้อเสนออย่างสุภาพหากคุณรู้สึกว่ามีบางสิ่งที่น่ารังเกียจ

สิ่งสำคัญคือ - เมื่อคุณเข้าใจแรงจูงใจที่อยู่เบื้องหลังข้อกำหนดแนวทางการปฏิบัติที่เหมาะสมจะชัดเจน

แก้ไข:หลังจากดูในแนวทแยงที่ PDF อ้างอิงอัลกอริทึมที่อธิบายมีแน่นอนดูเหมือนว่าเหมาะสำหรับสไตล์การทำงานมากกว่า OO

มีข้อดีหลายประการในการร้องขอให้ใช้การเขียนโปรแกรมเชิงฟังก์ชัน:

1. คุณมีลูกค้ามันเป็นสัญญาณที่ดีเสมอ
2. ลูกค้าคาดหวังให้คุณเก่งในสิ่งที่คุณทำ นี่คือเหตุผลที่พวกเขาถามโปรแกรมการทำงาน ดังนั้นองค์กรขายของคุณกำลังทำงานได้ดีหรือคุณกำลังขอราคาที่สูงมากสำหรับบริการของคุณ
3. องค์กรลูกค้ามีบางคนที่รู้ว่าการเขียนโปรแกรมการทำงานเป็นสิ่งที่ดีและจะมีขนาดใหญ่ในอนาคต

แต่ก็มีสัญญาณที่น่าตกใจด้วยเช่นกัน:

1. ดูเหมือนว่าคุณไม่ได้เตรียมที่จะใช้งานในการเขียนโปรแกรมเชิงฟังก์ชัน คุณล้าสมัยไปแล้วในทักษะของคุณและไม่สามารถติดตามการเปลี่ยนแปลงได้
2. หรือลูกค้าคาดหวังว่าคุณจะเป็นโปรแกรมเมอร์ที่ดีกว่าที่เป็นจริง ซึ่งหมายความว่าคุณอาจต้องปรับลดความต้องการของพวกเขาจนกว่าคุณจะสามารถทำมันได้อย่างถูกต้อง

การตอบกลับข้างต้นอย่างที่สองที่อาจ OO ไม่ใช่ทางออกที่ดีที่สุดซึ่งในกรณีนี้ลูกค้าอาจมีประเด็น

ดูที่ AI Challenge ซึ่งเป็นตัวอย่างของพฤติกรรมที่มีรายละเอียดในคำถามที่นี่http://aichallenge.orgและดูความหลากหลายของแพ็คเกจเริ่มต้น - http://aichallenge.org/starter_packages.php/ส่วนใหญ่ เป็นภาษาที่ฉันจะไม่ใส่ในกระบวนทัศน์ OO

คุณไม่ได้เขียนอะไรเกี่ยวกับภาษาการเขียนโปรแกรมซึ่งเป็นสิ่งที่สำคัญที่สุดที่นั่น ความแตกต่างระหว่าง OOP และการตั้งโปรแกรมการทำงานไม่เพียง แต่เป็นวิธีการจัดระเบียบโค้ด แต่ภาษาเอง เมื่อมีการใช้งานพร้อมกันสูงภาษา Erlang ใช้งานได้มีการใช้งานและมีข้อได้เปรียบสูงกว่าเช่น Java (มีการใช้งานเช่นโดยการแชทบน Facebook) โซลูชัน OOP อาจล้มเหลวได้เนื่องจากปัญหาด้านประสิทธิภาพ

ลูกค้าที่นี่คือมหาวิทยาลัยดังนั้นภาษาไม่เพียง แต่มีปัญหาด้านประสิทธิภาพ / การกำหนดค่าเท่านั้นยังสามารถใช้รหัสนี้สำหรับการสอนเชิงปฏิบัติการกับนักเรียนหรือการวิจัยของตัวเอง ดังนั้นลูกค้า 'ชักชวน' ให้เลือกกระบวนทัศน์อื่น ๆ ในความคิดของฉันไม่สามารถใช้ได้ที่นี่ นี่เป็นทั้งที่คุณสามารถจัดการกับงานหรือคุณไม่สามารถ (และดังนั้นคุณไม่ควรใช้โครงการนั้น)

ลูกค้าบอกว่า "กระโดด" คำตอบของคุณคือ: __ _ ?

สำหรับฉันฉันจะพยายามเกลี้ยกล่อมหากมันเหมาะสม (โครงการใหม่) แต่ฉันยังมีลูกค้าที่มีแอพ VB6 อายุ 10 ปีที่ฉันทำการอัปเกรดเป็นครั้งคราว ... จะไม่โน้มน้าวให้พวกเขา

'Cross Examine' ไคลเอนต์ของคุณสักเล็กน้อย (ในลักษณะที่ไม่คาดคั้น):

ลูกค้าทราบถึงความแตกต่างระหว่าง OOP และการโปรแกรมเชิงฟังก์ชันหรือไม่? ข้อกังวล / คำขอของลูกค้าถูกต้องตามกฎหมายหรือไม่?

ถ้า 'ใช่': หากคุณผ่านการรับรองให้ทำสิ่งที่พวกเขาต้องการและนำเงินของคุณไป หากคุณไม่มีคุณสมบัติโปรดแจ้งให้พวกเขาทราบและให้พวกเขาตัดสินใจว่าจะทำอย่างไร

อื่น: สวัสดีเอามันออกไปที่นั่น!

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

ฟังก์ชั่นนี้ใช้งานได้ตราบเท่าที่มันไม่ได้อ่าน / เขียนอะไรนอกฟังก์ชั่น หากฟังก์ชั่นแตะตัวแปรคลาสมันจะไม่สามารถใช้งานได้อีก ข้อดีของรูปแบบการทำงานคือไม่มีข้อผิดพลาดจากการเปลี่ยนแปลงหรือสถานะที่ไม่ถูกต้อง ฟังก์ชั่นจำนวนมากเป็นเพียงสูตรทางคณิตศาสตร์ นั่นคือการเขียนโปรแกรมฟังก์ชั่นสั้น ๆ

BTW คุณสามารถรวมสไตล์การทำงานภายในการออกแบบเชิงวัตถุหรือเชิงวัตถุ ตัวอย่างเช่นตัวแปร "Point" สองตัวคือวัตถุที่มีสถานะ และฟังก์ชั่นยังคงใช้งานได้! เย้!!