คำถามติดแท็ก object-oriented

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

6
ทำความเข้าใจกับ“ การเขียนโปรแกรมไปยังส่วนต่อประสาน”
ฉันเจอคำว่า "การเขียนโปรแกรมไปยังอินเทอร์เฟซแทนที่จะใช้งาน" มากและฉันคิดว่าฉันเข้าใจความหมายของมัน แต่ฉันต้องการให้แน่ใจว่าฉันเข้าใจถึงประโยชน์และการใช้งานที่เป็นไปได้ "การเขียนโปรแกรมไปยังอินเทอร์เฟซ" หมายความว่าเมื่อเป็นไปได้เราควรอ้างถึงระดับนามธรรมของคลาส (อินเทอร์เฟซคลาสนามธรรมหรือบางครั้งเป็นซูเปอร์คลาสของการเรียงลำดับบางอย่าง) แทนที่จะอ้างถึงการใช้งานที่เป็นรูปธรรม ตัวอย่างทั่วไปใน Java คือการใช้: List myList = new ArrayList();ArrayList myList = new ArrayList();แทน ฉันมีคำถามสองข้อเกี่ยวกับเรื่องนี้: ฉันต้องการให้แน่ใจว่าฉันเข้าใจถึงประโยชน์หลักของวิธีนี้ ฉันคิดว่าประโยชน์ส่วนใหญ่มีความยืดหยุ่น การประกาศวัตถุเป็นข้อมูลอ้างอิงระดับสูงมากกว่าการนำไปปฏิบัติอย่างเป็นรูปธรรมช่วยให้มีความยืดหยุ่นและบำรุงรักษาได้มากขึ้นตลอดวงจรการพัฒนาและตลอดทั้งรหัส ถูกต้องหรือไม่ ความยืดหยุ่นเป็นประโยชน์หลักหรือไม่? มีวิธีเพิ่มเติมในการ 'เขียนโปรแกรมไปยังส่วนต่อประสาน' หรือไม่? หรือ "การประกาศตัวแปรเป็นอินเตอร์เฟสแทนที่จะใช้อย่างเป็นรูปธรรม" เป็นการนำแนวคิดนี้ไปปฏิบัติเท่านั้น ฉันไม่ได้พูดคุยเกี่ยวกับการเชื่อมต่อสร้าง Java ฉันกำลังพูดถึงหลักการ OO "การเขียนโปรแกรมไปยังส่วนต่อประสานไม่ใช่การใช้งาน" ในหลักการนี้"อินเตอร์เฟซ" ของโลกหมายถึง "supertype" ใด ๆ ของคลาส - อินเทอร์เฟซคลาสนามธรรมหรือซูเปอร์คลาสธรรมดาซึ่งเป็นนามธรรมและคอนกรีตน้อยกว่าคลาสย่อยที่เป็นรูปธรรมมากขึ้น

9
ทำไมภาษาที่จำเป็น / OO ที่เป็นที่รู้จักกันดีส่วนใหญ่อนุญาตให้เข้าถึงประเภทที่สามารถแสดงถึงค่า 'ไม่มีอะไร' ได้โดยไม่ จำกัด
ผมได้อ่านเกี่ยวกับ (UN) ความสะดวกสบายของการมีnullแทน Maybe(ตัวอย่าง) หลังจากที่ได้อ่านบทความนี้ , ผมเชื่อว่ามันจะดีกว่าที่จะใช้Maybe (หรือบางสิ่งบางอย่างที่คล้ายกัน) อย่างไรก็ตามฉันรู้สึกประหลาดใจที่เห็นว่าภาษาการเขียนโปรแกรมเชิงวัตถุหรือเชิงวัตถุที่มีชื่อเสียง "ยังคงใช้อยู่null(ซึ่งอนุญาตการเข้าถึงชนิดที่ไม่ถูกตรวจสอบซึ่งสามารถแสดงถึงค่า 'ไม่มีอะไร') และMaybeส่วนใหญ่จะใช้ในภาษาโปรแกรมเชิงฟังก์ชัน ตัวอย่างเช่นดูรหัส C # ต่อไปนี้: void doSomething(string username) { // Check that username is not null // Do something } มีบางอย่างมีกลิ่นไม่ดีที่นี่ ... ทำไมเราควรตรวจสอบว่าข้อโต้แย้งนั้นเป็นโมฆะหรือไม่ เราไม่ควรคิดว่าทุกตัวแปรมีการอ้างอิงไปยังวัตถุหรือไม่? อย่างที่คุณเห็นปัญหาคือว่าโดยนิยามตัวแปรเกือบทั้งหมดสามารถมีการอ้างอิงที่เป็นโมฆะ เกิดอะไรขึ้นถ้าเราสามารถตัดสินใจว่าตัวแปรใดเป็น "โมฆะ" และไม่ได้? นั่นจะช่วยเราได้มากในขณะที่ทำการดีบั๊กและมองหา "NullReferenceException" ลองจินตนาการว่าโดยค่าเริ่มต้นไม่มีประเภทอาจมีอ้างอิงโมฆะ แทนที่จะเป็นเช่นนั้นคุณจะระบุอย่างชัดเจนว่าตัวแปรสามารถมีการอ้างอิงที่เป็นโมฆะได้เฉพาะในกรณีที่คุณต้องการ นั่นคือความคิดเบื้องหลังบางที หากคุณมีฟังก์ชั่นที่ในบางกรณีล้มเหลว (ตัวอย่างเช่นการหารด้วยศูนย์) คุณสามารถส่งกลับMaybe<int>ระบุอย่างชัดเจนว่าผลลัพธ์อาจเป็น int แต่ยังไม่มีอะไร! นี่คือเหตุผลหนึ่งที่ต้องการบางทีอาจจะแทนที่จะเป็นโมฆะ …

7
ความแตกต่างระหว่าง "การซ่อนข้อมูล" และ "การห่อหุ้มข้อมูล" คืออะไร?
ฉันกำลังอ่าน "การทำงานพร้อมกันของ Java ในทางปฏิบัติ" และมีการกล่าวว่า: "โชคดีที่เทคนิคเชิงวัตถุเดียวที่ช่วยให้คุณเขียนคลาสที่มีการจัดการที่ดีและบำรุงรักษาได้เช่น encapsulation และการซ่อนข้อมูล - สามารถช่วยคุณสร้าง thread-safe ชั้นเรียน." ปัญหา # 1 - ฉันไม่เคยได้ยินเกี่ยวกับการซ่อนข้อมูลและไม่รู้ว่ามันคืออะไร ปัญหา # 2 - ฉันคิดเสมอว่า encapsulation ใช้ private vs public และจริงๆแล้วคือการซ่อนข้อมูล คุณช่วยอธิบายการซ่อนข้อมูลคืออะไรและแตกต่างจากการห่อหุ้มข้อมูลได้อย่างไร

12
ทำไมชั้นเรียนควรเป็นอย่างอื่นนอกจาก“ นามธรรม” หรือ“ สุดท้าย / ปิดผนึก”
หลังจาก 10 ปีของการเขียนโปรแกรม java / c # ฉันพบว่าตัวเองกำลังสร้าง: คลาสนามธรรม : สัญญาที่ไม่ได้มีไว้เพื่อสร้างอินสแตนซ์ ชั้นเรียนสุดท้าย / ปิดผนึก : การนำไปปฏิบัติไม่ได้หมายถึงการใช้เป็นคลาสพื้นฐานให้กับสิ่งอื่น ฉันไม่สามารถนึกถึงสถานการณ์ใด ๆ ที่ "คลาส" ง่าย ๆ (เช่นไม่เป็นนามธรรมหรือสุดท้าย / ปิดผนึก) จะเป็น "การเขียนโปรแกรมที่ชาญฉลาด" ทำไมชั้นเรียนควรเป็นอย่างอื่นนอกจาก "นามธรรม" หรือ "ขั้นสุดท้าย / ปิดผนึก" แก้ไข บทความที่ดีนี้อธิบายถึงความกังวลของฉันได้ดีกว่าที่ฉันสามารถทำได้

12
ชั้นเรียนมีขนาดใหญ่แค่ไหน?
ฉันเป็นนักพัฒนาที่ยาวนาน (ฉันอายุ 49 ปี) แต่ค่อนข้างใหม่สำหรับการพัฒนาเชิงวัตถุ ฉันได้อ่านเกี่ยวกับ OO มาตั้งแต่ไอเฟลของ Bertrand Meyer แต่ได้เขียนโปรแกรม OO น้อยมาก ประเด็นก็คือหนังสือทุกเล่มเกี่ยวกับการออกแบบ OO เริ่มต้นด้วยตัวอย่างของเรือรถยนต์หรือสิ่งของทั่วไปที่เราใช้บ่อยมากและพวกเขาก็เริ่มเพิ่มคุณสมบัติและวิธีการและอธิบายว่าพวกเขาจำลองสถานะของวัตถุอย่างไรและสามารถทำอะไรได้บ้าง มัน. ดังนั้นพวกเขาจึงมักจะไปบางอย่างเช่น "ยิ่งโมเดลดีขึ้นเท่าไรมันก็จะแสดงวัตถุในแอปพลิเคชันได้ดีเท่านั้นและยิ่งออกมาดีกว่า" จนถึงตอนนี้ดี แต่ในทางกลับกันฉันได้พบผู้เขียนหลายคนที่ให้สูตรเช่น "คลาสควรพอดีในหน้าเดียว" (ฉันจะเพิ่ม "ในขนาดจอภาพอะไร?" ตอนนี้เราพยายามไม่ เพื่อพิมพ์รหัส!) ยกตัวอย่างเช่นPurchaseOrderคลาสที่มีเครื่องสถานะ จำกัด ควบคุมพฤติกรรมและคอลเลกชันPurchaseOrderItemหนึ่งในข้อโต้แย้งที่นี่ในที่ทำงานคือเราควรใช้PurchaseOrderคลาสที่เรียบง่ายด้วยวิธีการบางอย่าง (น้อยกว่าคลาสข้อมูล) และมีPurchaseOrderFSM“ชั้นผู้เชี่ยวชาญ” ที่จับเครื่องสถานะ จำกัด PurchaseOrderสำหรับ ฉันจะบอกว่าตกอยู่ในหมวดหมู่ "อิจฉาคุณสมบัติ" หรือ "ความไม่เหมาะสมที่ใกล้ชิด" ของการโพสต์โค้ดของ Jeff Atwood's Smellsเมื่อสยองขวัญการเข้ารหัส ฉันแค่เรียกมันว่าสามัญสำนึก ถ้าผมสามารถออกอนุมัติหรือยกเลิกคำสั่งซื้อของฉันจริงแล้วPurchaseOrderชั้นควรมีissuePO, approvePOและcancelPOวิธีการ นั่นไม่ได้เกิดขึ้นกับ "การเพิ่มการเชื่อมโยงสูงสุด" และ "ลดการแต่งงาน" หลักการเก่า …

10
มีอินเทอร์เฟซมากเกินไปจำนวนเท่าใดในคลาส? [ปิด]
ฉันอาจจะคิดว่ามันเป็นกลิ่นรหัสหรือแม้กระทั่งการต่อต้านรูปแบบที่จะมีชั้นเรียนที่ใช้อินเตอร์เฟซ 23 ถ้ามันเป็นรูปแบบการต่อต้านคุณจะเรียกมันว่าอะไร? หรือเป็นเพียงแค่ไม่ปฏิบัติตามหลักการความรับผิดชอบเดี่ยว?

6
การเรียนรู้ภาษาที่ใช้งานได้จะทำให้โปรแกรมเมอร์ OOP ดีขึ้นหรือไม่ [ปิด]
ในฐานะโปรแกรมเมอร์ Java / C # / C ++ ฉันได้ยินการพูดคุยเกี่ยวกับภาษาที่ใช้งานได้หลายอย่าง แต่ไม่เคยพบว่าจำเป็นต้องเรียนรู้ ฉันเคยได้ยินเช่นกันว่าระดับความคิดที่สูงขึ้นของภาษาที่ใช้งานได้ทำให้คุณเป็นโปรแกรมเมอร์ภาษา OOP / ขั้นตอนที่ดีขึ้น มีใครยืนยันได้ไหม มันพัฒนาทักษะการเขียนโปรแกรมของคุณในทางใดบ้าง อะไรคือตัวเลือกที่ดีของภาษาในการเรียนรู้โดยมีเป้าหมายเพื่อพัฒนาทักษะในภาษาที่ซับซ้อนน้อยกว่า?

6
คำเตือนของการใช้ประเภทพื้นฐาน (เช่น int) เป็นชั้นเรียนคืออะไร?
เมื่อมีการออกแบบและ implenting ภาษาโปรแกรมเชิงวัตถุในบางจุดหนึ่งต้องให้ทางเลือกเกี่ยวกับการใช้ประเภทพื้นฐาน (เช่นint, float, doubleหรือเทียบเท่า) เป็นชั้นเรียนหรือสิ่งอื่นใด เห็นได้ชัดว่าภาษาในตระกูล C มีแนวโน้มที่จะไม่กำหนดเป็นคลาส (Java มีชนิดดั้งเดิมแบบพิเศษ C # ใช้ภาษาเหล่านี้เป็น struct ที่ไม่เปลี่ยนรูป ฯลฯ ) ฉันสามารถนึกถึงข้อได้เปรียบที่สำคัญมากเมื่อมีการใช้ประเภทพื้นฐานเป็นคลาส (ในระบบชนิดที่มีลำดับชั้นแบบรวม): ชนิดเหล่านี้อาจเป็นชนิดย่อย Liskov ที่เหมาะสมของประเภทรูต ดังนั้นเราจึงหลีกเลี่ยงความสับสนของภาษาด้วย Boxing / unboxing (ชัดเจนหรือโดยปริยาย) ประเภทของ wrapper กฎความแปรปรวนพิเศษพฤติกรรมพิเศษ ฯลฯ แน่นอนฉันสามารถเข้าใจบางส่วนว่าทำไมนักออกแบบภาษาจึงตัดสินใจเลือกวิธีการ: อินสแตนซ์ของชั้นเรียนมักจะมีค่าใช้จ่ายเชิงพื้นที่ (เนื่องจากอินสแตนซ์อาจมี vtable หรือข้อมูลเมตาอื่น ๆ ในโครงร่างหน่วยความจำ) มี (ถ้าภาษาไม่อนุญาตให้สืบทอดกับสิ่งเหล่านั้น) ประสิทธิภาพเชิงพื้นที่ (และพื้นที่เชิงพื้นที่ที่ได้รับการปรับปรุงโดยเฉพาะในอาร์เรย์ขนาดใหญ่) เป็นเหตุผลเดียวที่ว่าทำไมประเภทพื้นฐานมักไม่ได้เรียน? โดยทั่วไปฉันคิดว่าคำตอบคือใช่ แต่คอมไพเลอร์มีอัลกอริธึมการวิเคราะห์แบบ Escape และพวกเขาสามารถอนุมานได้ว่าพวกเขาสามารถ (เลือก) …

7
การเขียนโปรแกรมเชิงฟังก์ชันละเลยประโยชน์ที่ได้รับจาก“ ตามเกณฑ์ที่จะใช้ในการย่อยสลายระบบเป็นโมดูล” (การซ่อนข้อมูล) หรือไม่?
มีบทความคลาสสิกชื่อตามเกณฑ์ที่จะใช้ในการย่อยสลายระบบเป็นโมดูลที่ฉันเพิ่งอ่านเป็นครั้งแรก มันสมเหตุสมผลดีสำหรับฉันและอาจเป็นหนึ่งในบทความที่ OOP อ้างอิง ข้อสรุปของมัน: เราพยายามสาธิตโดยตัวอย่างเหล่านี้ว่ามันไม่ถูกต้องเสมอไปที่จะเริ่มการสลายตัวของระบบเป็นโมดูลบนพื้นฐานของแผนผังลำดับงาน ... แต่ละโมดูลได้รับการออกแบบมาเพื่อซ่อนการตัดสินใจจากสิ่งอื่น ในความเห็นที่ไม่มีการศึกษาและไม่มีประสบการณ์ของฉันการเขียนโปรแกรมฟังก์ชั่นใช้คำแนะนำตรงข้ามแน่นอนของบทความนี้ ความเข้าใจของฉันคือการเขียนโปรแกรมการทำงานทำให้การไหลของข้อมูลเป็นสำนวน ข้อมูลถูกส่งผ่านจากฟังก์ชั่นหนึ่งไปยังอีกฟังก์ชั่นแต่ละฟังก์ชั่นจะรับรู้ข้อมูลอย่างใกล้ชิดและ"เปลี่ยน"ไปพร้อมกัน และฉันคิดว่าฉันเคยเห็น Rich Hickey คุยกันในที่ที่เขาพูดถึงว่าการซ่อนข้อมูลนั้นเกินจริงหรือไม่จำเป็นหรืออะไร แต่ฉันจำไม่ได้แน่นอน ก่อนอื่นฉันต้องการทราบว่าการประเมินของฉันถูกต้องหรือไม่ กระบวนทัศน์ของ FP และบทความนี้ขัดแย้งกับปรัชญาหรือไม่? สมมติว่าพวกเขาไม่เห็นด้วย FP จะ "ชดเชย" อย่างไรหากไม่มีการซ่อนข้อมูล บางทีพวกเขาอาจเสียสละการซ่อนข้อมูล แต่ได้รับ X, Y และ Z ฉันต้องการทราบเหตุผลว่าทำไม X, Y และ Z จึงถือว่าเป็นประโยชน์มากกว่าการซ่อนข้อมูล หรือสมมติว่าพวกเขาไม่เห็นด้วย FP อาจรู้สึกว่าการซ่อนข้อมูลไม่ดี ถ้าเป็นเช่นนั้นทำไมจึงคิดว่าการซ่อนข้อมูลไม่ดี สมมติว่าพวกเขาเห็นด้วยฉันต้องการทราบว่าการนำ FPs ไปปฏิบัติใช้ของการซ่อนข้อมูลคืออะไร เห็นได้ชัดใน OOP คุณสามารถมีprivateฟิลด์ที่ไม่มีใครนอกชั้นเรียนสามารถเข้าถึงได้ ไม่มีสิ่งใดที่เปรียบเทียบกับฉันใน FP ฉันรู้สึกว่ามีคำถามอื่น …

9
จะมีอะไรผิดพลาดได้หากหลักการชดเชย Liskov ถูกละเมิด?
ฉันได้ติดตามคำถามที่ได้รับการโหวตอย่างสูงเกี่ยวกับการละเมิดหลักการทดแทน Liskov ฉันรู้ว่าหลักการชดเชย Liskov คืออะไร แต่สิ่งที่ยังไม่ชัดเจนในใจของฉันคือสิ่งที่อาจผิดพลาดได้หากฉันในฐานะนักพัฒนาไม่ได้คิดถึงหลักการในขณะที่เขียนโค้ดเชิงวัตถุ

12
SOLID vs. การหลีกเลี่ยงสิ่งที่เป็นนามธรรมก่อนวัยอันควร
ฉันเข้าใจว่าSOLIDควรทำอะไรให้สำเร็จและใช้มันเป็นประจำในสถานการณ์ที่ความเป็นโมดูล่านั้นสำคัญและเป้าหมายของมันก็มีประโยชน์อย่างชัดเจน อย่างไรก็ตามมีสองสิ่งที่ขัดขวางไม่ให้ฉันใช้มันอย่างสม่ำเสมอบน codebase ฉันต้องการหลีกเลี่ยงสิ่งที่เป็นนามธรรมก่อนวัยอันควร จากประสบการณ์ของฉันวาดเส้นที่เป็นนามธรรมโดยไม่มีกรณีการใช้อย่างเป็นรูปธรรม (ชนิดที่มีอยู่ในปัจจุบันหรือในอนาคตอันใกล้ ) นำไปสู่การที่พวกเขาถูกวาดในสถานที่ที่ผิด เมื่อฉันพยายามแก้ไขโค้ดดังกล่าวบรรทัดที่เป็นนามธรรมจะเข้ามาแทนที่การช่วยเหลือ ดังนั้นฉันมักจะทำผิดด้านข้างของการไม่วาดเส้นนามธรรมจนกว่าฉันจะมีความคิดที่ดีว่าพวกเขาจะมีประโยชน์ที่ไหน ฉันพบว่ามันยากที่จะปรับให้เป็นแบบโมดูลาร์เพื่อประโยชน์ของตัวเองถ้ามันทำให้โค้ดของฉันละเอียดยิ่งขึ้นเข้าใจได้ยากขึ้นและไม่กำจัดการทำซ้ำใด ๆ ฉันพบว่ารหัสโพรซีเดอร์ที่เรียบง่ายและแน่นหนาบางครั้งเข้าใจง่ายกว่าโค้ดราวีโอลี่ที่มีปัจจัยดีเพราะการไหลนั้นง่ายและเป็นเชิงเส้น นอกจากนี้ยังง่ายต่อการเขียน ในทางตรงกันข้ามความคิดนี้มักจะนำไปสู่วัตถุที่พระเจ้า ฉันมักจะปรับโครงสร้างเหล่านี้อย่างอนุรักษ์นิยมโดยเพิ่มเส้นนามธรรมที่ชัดเจนเฉพาะเมื่อฉันเห็นรูปแบบที่ชัดเจน หากมีสิ่งใดผิดปกติกับวัตถุของพระเจ้าและรหัสคู่ที่แน่นหนาถ้าคุณไม่ต้องการความเป็นโมดูล่าร์ที่ชัดเจนกว่านี้ไม่มีการทำซ้ำอย่างมีนัยสำคัญและสามารถอ่านรหัสได้? แก้ไข: เท่าที่หลักการของแต่ละบุคคลฉันตั้งใจจะเน้นว่าการทดแทน Liskov เป็น IMHO อย่างเป็นทางการของสามัญสำนึกและควรนำไปใช้ทุกที่เนื่องจาก abstractions ไม่สมเหตุสมผลถ้าไม่ใช่ นอกจากนี้ทุกชั้นเรียนควรมีความรับผิดชอบเพียงระดับเดียวในระดับที่เป็นนามธรรมแม้ว่ามันอาจจะเป็นระดับที่สูงมากโดยมีรายละเอียดการดำเนินการทั้งหมดหนาตาลงในชั้นเรียน 2,000 บรรทัดขนาดใหญ่ โดยพื้นฐานแล้วบทคัดย่อของคุณควรเข้าใจว่าคุณเลือกนามธรรมอย่างไร หลักการที่ฉันถามในกรณีที่ไม่มีความชัดเจนว่าเป็นโมดูล่าร์แบบเปิดปิดการแยกอินเทอร์เฟซและโดยเฉพาะอย่างยิ่งการพึ่งพาอาศัยกัน

14
มีการจัดการฐานรหัสที่ไม่ใช่ OO ขนาดใหญ่เท่าใด
ฉันมักจะเห็นสิ่งที่เป็นนามธรรมเป็นคุณสมบัติที่มีประโยชน์มากที่ OO มีให้สำหรับการจัดการโค้ด แต่จะมีการจัดการฐานรหัสที่ไม่ใช่ OO ขนาดใหญ่ได้อย่างไร หรือว่ากลายเป็น " Big Ball of Mud " ในที่สุด? อัปเดต: ดูเหมือนว่าทุกคนกำลังคิดว่า 'นามธรรม' เป็นเพียงการทำให้เป็นโมดูลหรือการซ่อนข้อมูล แต่ IMHO ก็หมายถึงการใช้ 'Abstract Classes' หรือ 'Interfaces' ซึ่งเป็นสิ่งจำเป็นสำหรับการพึ่งพาการฉีดและการทดสอบ รหัสฐานที่ไม่ใช่ OO จะจัดการสิ่งนี้ได้อย่างไร นอกจากนี้ยังมีสิ่งที่เป็นนามธรรมนอกจากนี้การห่อหุ้มยังช่วยในการจัดการฐานรหัสขนาดใหญ่ในขณะที่มันกำหนดและ จำกัด ความสัมพันธ์ระหว่างข้อมูลและฟังก์ชั่น ด้วย C มันเป็นไปได้มากที่จะเขียนโค้ดหลอก -OO ฉันไม่รู้เกี่ยวกับภาษาที่ไม่ใช่ OO มากนัก เป็นวิธีจัดการฐานรหัส C ขนาดใหญ่หรือไม่

8
มีรสชาติของ OOP ที่หลักการ SOLID บางส่วนหรือทั้งหมดขัดแย้งกับการทำความสะอาดรหัสหรือไม่?
ฉันเพิ่งได้พูดคุยกับเพื่อนของฉันเกี่ยวกับ OOP ในการพัฒนาวิดีโอเกม ฉันอธิบายสถาปัตยกรรมของหนึ่งในเกมของฉันซึ่งทำให้เพื่อนของฉันประหลาดใจมีชั้นเรียนขนาดเล็กจำนวนมากและเลเยอร์สิ่งที่เป็นนามธรรมหลายชั้น ฉันเป็นที่ถกเถียงกันอยู่ว่านี่เป็นผลมาจากการที่ฉันมุ่งเน้นไปที่การให้ความรับผิดชอบทุกอย่างเดียวและยังช่วยลดการเชื่อมต่อระหว่างส่วนประกอบ ความกังวลของเขาคือจำนวนชั้นเรียนจำนวนมากจะแปลฝันร้ายบำรุงรักษา มุมมองของฉันคือว่ามันจะมีผลตรงกันข้ามที่แน่นอน เราดำเนินการหารือเกี่ยวกับเรื่องนี้สำหรับสิ่งที่ดูเหมือนว่าหลายศตวรรษในที่สุดก็ตกลงที่จะไม่เห็นด้วยบอกว่าอาจมีบางกรณีที่หลักการที่เป็นของแข็งและ OOP ที่เหมาะสมไม่จริงผสมกันได้ดี แม้แต่รายการ Wikipediaเกี่ยวกับหลักการ SOLID ก็ระบุว่าเป็นแนวทางที่ช่วยในการเขียนโค้ดที่สามารถบำรุงรักษาได้และเป็นส่วนหนึ่งของกลยุทธ์โดยรวมของการเขียนโปรแกรมแบบคล่องตัวและปรับตัว ดังนั้นคำถามของฉันคือ: มีกรณีใน OOP ที่หลักการ SOLID บางส่วนหรือทั้งหมดไม่ได้ยืมตัวเองเพื่อทำความสะอาดรหัสหรือไม่? ฉันสามารถจินตนาการได้ทันทีว่าหลักการทดแทน Liskov อาจขัดแย้งกับการรับมรดกที่ปลอดภัยอีกรสชาติหนึ่ง กล่าวคือหากมีใครคิดรูปแบบที่มีประโยชน์อื่น ๆ ที่นำมาใช้ผ่านการสืบทอดมันค่อนข้างเป็นไปได้ที่ LSP อาจขัดแย้งโดยตรงกับมัน มีคนอื่นไหม? บางทีโครงการบางประเภทหรือแพลตฟอร์มเป้าหมายบางอย่างอาจทำงานได้ดีขึ้นด้วยวิธี SOLID ที่น้อยลง? แก้ไข: ฉันแค่ต้องการระบุว่าฉันไม่ได้ถามวิธีการปรับปรุงรหัสของฉัน;) เหตุผลเดียวที่ฉันพูดถึงโครงการในคำถามนี้คือการให้บริบทเล็กน้อย คำถามของฉันเป็นเรื่องเกี่ยวกับหลักการ OOP และการออกแบบทั่วไป หากคุณอยากรู้เกี่ยวกับโครงการของฉันให้ดูนี้ แก้ไข 2: ฉันจินตนาการว่าคำถามนี้จะตอบในหนึ่งใน 3 วิธี: ใช่มีหลักการออกแบบของ OOP ที่ขัดแย้งกับ SOLID บางส่วน ใช่มีหลักการออกแบบของ …

6
ฟังก์ชั่นการเขียนโปรแกรมเป็นชุดของวัตถุที่มุ่งเน้น?
ยิ่งฉันเขียนโปรแกรมที่ใช้งานได้มากเท่าไหร่ฉันก็ยิ่งรู้สึกว่ามันเพิ่มเลเยอร์สิ่งที่เป็นนามธรรมซึ่งดูเหมือนว่าเลเยอร์ของหอมหัวใหญ่เป็นอย่างไรรวมไปถึงเลเยอร์ก่อนหน้า ฉันไม่รู้ว่านี่เป็นความจริงหรือเปล่าดังนั้นเพื่อปิดหลักการ OOP ที่ฉันเคยทำมานานหลายปีแล้วใครจะอธิบายได้ว่าการทำงานหรือไม่สามารถอธิบายสิ่งเหล่านี้ได้อย่างถูกต้อง: Encapsulation, Abstraction, Inheritance, Polymorphism ฉันคิดว่าเราทุกคนสามารถพูดได้ใช่มันมีการห่อหุ้มผ่านทูเปิลหรือสิ่งอันดับนับเป็นเทคนิคในความเป็นจริงของ "การเขียนโปรแกรมฟังก์ชั่น" หรือพวกเขาเป็นเพียงยูทิลิตี้ของภาษา? ฉันรู้ว่า Haskell สามารถตอบสนองความต้องการ "อินเทอร์เฟซ" แต่อีกครั้งไม่แน่ใจว่ามันเป็นวิธีการทำงานจริงหรือไม่ ฉันคาดเดาว่าความจริงที่ว่า functors มีพื้นฐานทางคณิตศาสตร์ที่คุณสามารถบอกได้ว่าสิ่งเหล่านี้เป็นสิ่งที่แน่นอนในการคาดหวังการทำงาน โปรดให้รายละเอียดว่าคุณคิดว่าการทำงานทำหน้าที่หรือไม่ปฏิบัติตาม 4 หลักการของ OOP แก้ไข: ฉันเข้าใจความแตกต่างระหว่างกระบวนทัศน์การทำงานและกระบวนทัศน์เชิงวัตถุได้ดีและตระหนักว่ามีหลายภาษาหลายภาษาในทุกวันนี้ซึ่งสามารถทำได้ทั้งสองอย่าง ฉันแค่กำลังมองหาคำจำกัดความของวิธีการที่ fp ทันที (คิดว่าคนพิถีพิถันเช่น haskell) สามารถทำสิ่งใดสิ่งหนึ่งในสี่รายการที่ระบุไว้หรือทำไมมันไม่สามารถทำใด ๆ ของพวกเขา เช่น "การห่อหุ้มสามารถทำได้ด้วยการปิด" (หรือถ้าฉันผิดในความเชื่อนี้โปรดระบุสาเหตุ)

5
วิธีการ refactor โปรแกรม OO เป็นหนึ่งทำงานได้อย่างไร
ฉันมีปัญหาในการค้นหาแหล่งข้อมูลเกี่ยวกับวิธีการเขียนโปรแกรมในสไตล์การใช้งาน หัวข้อขั้นสูงที่สุดที่ฉันสามารถหาได้ทางออนไลน์คือการใช้โครงสร้างการพิมพ์เพื่อลดลำดับชั้นของชั้นเรียนลง ส่วนใหญ่เพียงจัดการกับวิธีการใช้แผนที่ / พับ / ลด / ฯลฯ เพื่อแทนที่ลูปที่จำเป็น สิ่งที่ฉันต้องการค้นหาจริงๆคือการสนทนาในเชิงลึกเกี่ยวกับการใช้งาน OOP ของโปรแกรมที่ไม่น่าสนใจข้อ จำกัด และวิธีการปรับโครงสร้างในลักษณะการทำงาน ไม่ใช่แค่อัลกอริธึมหรือโครงสร้างข้อมูล แต่มีบางอย่างที่มีบทบาทและแง่มุมที่แตกต่างกัน - อาจเป็นวิดีโอเกม โดยวิธีที่ฉันได้อ่าน Real-World Function Programming โดย Tomas Petricek แต่ฉันก็อยากได้มากกว่านี้

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