ฟังก์ชั่นการสลายตัวเป็นปฏิปักษ์จริงหรือไม่?


9

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

และหน้าhttp://sourcemaking.com/antipatterns/functional-decompositionทำให้ฉันสงสัย

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

และสิ่งนี้ทำให้เกิดคำถามขึ้นฉันกำลังทำผิดโดยติดกับ OOP + ฟังก์ชั่นสไตล์หรือเป็นเรื่องธรรมดาในอุตสาหกรรมและไม่ใช่เรื่องเลวร้าย

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

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

ปัญหา OOP ได้รับการเสริมด้วยลิงก์จากโพสต์อื่นในเธรดเดียวกัน ลิงค์จะดูที่สไตล์ OOP ของ Java http://chaosinmotion.com/blog/?p=622

ดังนั้นทัศนคติทั่วไปที่มีต่อการผสมการทำงานของโปรแกรมกับ OOP คืออะไร? และอะไรคือความสมดุลที่นักพัฒนาควรพยายามที่จะบรรลุ?


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

ขออภัยฉันไม่ใช่เจ้าของภาษาและฉันก็ลำบากที่จะคิดถึงชื่อที่ดีกว่า ยินดีต้อนรับการแก้ไข
Coder

1
คำถามชัดเจน อย่าฟังบลูเบอร์รี่ฟิลด์
jojo

5
เห็นได้ชัดว่าสำหรับ OOP zealots อะไรก็ตามที่อยู่นอกเหนือการเข้าถึงของ OOP นั้นเป็น "antipattern" อันที่จริงสิ่งที่เป็นไปได้ที่เลวร้ายที่สุดคือ OOP มากเกินไป
SK-logic

คำตอบ:


8

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

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

ในทางปฏิบัติฉันได้เห็นวิศวกรรมเพิ่มเติมในรหัสเชิงวัตถุมากกว่าขั้นตอน - น้อยกว่าทางวิศวกรรมและอีกเล็กน้อยทางวิศวกรรม

ในกรณีของคุณมันจะขึ้นอยู่กับเฉพาะและฉันไม่แน่ใจว่าสิ่งที่คุณทำในรูปแบบขั้นตอน มันถูกต้องชัดเจนทดสอบได้ปรับเปลี่ยนได้ง่าย ฯลฯ หรือไม่ เกณฑ์ในการตัดสินรหัสควรเป็นไปตามข้อกังวลในทางปฏิบัติดังกล่าวและไม่ใช่ความบริสุทธิ์ของรูปแบบเฉพาะ ดูเหมือนว่าในกรณีของคุณคนที่มีเหตุผลและมีความรู้อาจไม่เห็นด้วย (และทำ!) เกี่ยวกับข้อกังวลเหล่านั้นและถ้าเป็นเช่นนั้นคงไม่มีวิธีที่มีวัตถุประสงค์เพื่อกำหนดความจริงของเรื่อง


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

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

4
แม้แต่วิธีนี้ - การสลายตัวตามขั้นตอนเป็นเทคนิคที่ถูกต้องและไม่ยอมรับว่าการเข้ากันไม่ได้กับ OOP นั้นเป็นสิ่งที่คลั่งไคล้อย่างแท้จริง ให้ดอกไม้ทั้งหมดบาน เทคนิคทั้งหมดใช้ได้ถ้าใช้อย่างชาญฉลาด การเกาะติดกับวิธีการใดวิธีหนึ่งโดยเฉพาะนั้นไม่ฉลาดเลย
SK-logic
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.