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

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

8
การออกแบบคลาสที่เน้นวัตถุ
ฉันสงสัยเกี่ยวกับการออกแบบคลาสเชิงวัตถุที่ดี โดยเฉพาะอย่างยิ่งฉันมีเวลาตัดสินใจยากระหว่างตัวเลือกเหล่านี้: วิธีการคงที่ vs อินสแตนซ์ method ที่ไม่มีพารามิเตอร์หรือ return value vs method กับพารามิเตอร์และ return value ฟังก์ชันการใช้วิธีการที่ทับซ้อนกัน vs ที่แตกต่างกัน วิธีส่วนตัวและสาธารณะ ตัวอย่างที่ 1: การใช้งานนี้ใช้วิธีการแบบอินสแตนซ์โดยไม่มีค่าส่งคืนหรือพารามิเตอร์โดยไม่มีการซ้อนทับฟังก์ชันการทำงานและวิธีการทั้งหมดสาธารณะ XmlReader reader = new XmlReader(url); reader.openUrl(); reader.readXml(); Document result = reader.getDocument(); ตัวอย่างที่ 2: การใช้งานนี้ใช้วิธีการคงที่มีค่าตอบแทนและพารามิเตอร์ที่มีฟังก์ชั่นที่ทับซ้อนกันและวิธีการส่วนตัว Document result = XmlReader.readXml(url); ในตัวอย่างที่หนึ่งวิธีทั้งหมดเป็นแบบสาธารณะซึ่งทำให้ง่ายต่อการทดสอบหน่วย แม้ว่าวิธีการทั้งหมดจะแตกต่างกัน readXml () ขึ้นอยู่กับ openUrl () ใน openUrl () นั้นจะต้องถูกเรียกก่อน …

9
การรับมรดกผิดไป
ฉันมีรหัสบางส่วนที่โมเดลการสืบทอดที่ดีลงไปและฉันพยายามเข้าใจว่าทำไมและวิธีการแก้ไข โดยพื้นฐานแล้วจินตนาการว่าคุณมีลำดับชั้นของ Zoo ด้วย: class Animal class Parrot : Animal class Elephant : Animal class Cow : Animal เป็นต้น คุณมีวิธีกิน (), รัน (), ฯลฯ และทุกอย่างดี วันหนึ่งมีคนเข้ามาและพูดว่า - คลาส CageBuilder ของเราทำงานได้ดีและใช้ animal.weight () และ animal.height () ยกเว้น African Bison ใหม่ที่แข็งแรงเกินไปและสามารถทุบกำแพงได้ดังนั้นฉันจะเพิ่ม อีกคุณสมบัติหนึ่งของคลาส Animal - isAfricanBizon () และใช้สิ่งนั้นเมื่อเลือกวัสดุและแทนที่มันสำหรับคลาส AfricanBizon เท่านั้น บุคคลต่อไปมาและทำสิ่งที่คล้ายกันและสิ่งต่อไปที่คุณรู้ว่าคุณมีคุณสมบัติเหล่านี้ทั้งหมดสำหรับชุดย่อยของลำดับชั้นในคลาสพื้นฐาน เป็นวิธีที่ดีในการปรับปรุง / …

5
ข้อดีของวิธีการหลายวิธีมากกว่าสวิตช์
ฉันได้รับการตรวจสอบโค้ดจากผู้พัฒนาระดับสูงในวันนี้โดยถามว่า "อย่างไรก็ตามอะไรคือสิ่งที่คุณคัดค้านการมอบหมายหน้าที่โดยใช้คำสั่งสวิตช์?" ฉันได้อ่านในหลาย ๆ ที่เกี่ยวกับวิธีการปั๊มการโต้เถียงผ่านวิธีสลับการโทรเป็นวิธีการที่ไม่ดี OOP ไม่สามารถขยายได้ ฯลฯ อย่างไรก็ตามฉันไม่สามารถหาคำตอบที่ชัดเจนสำหรับเขาได้ ฉันต้องการจะทำสิ่งนี้ให้กับตัวเองซักครั้ง นี่คือคำแนะนำเกี่ยวกับรหัสการแข่งขันของเรา (php ใช้เป็นตัวอย่าง แต่สามารถใช้ได้ในระดับสากล): class Switch { public function go($arg) { switch ($arg) { case "one": echo "one\n"; break; case "two": echo "two\n"; break; case "three": echo "three\n"; break; default: throw new Exception("Unknown call: $arg"); break; } } } class …

9
หลีกเลี่ยงข้อผิดพลาดที่มุ่งเน้นวัตถุย้ายจาก C ทำงานอะไรให้คุณ
ฉันได้เขียนโปรแกรมในภาษาเชิงปฏิบัติมาระยะหนึ่งแล้วและปฏิกิริยาแรกของฉันต่อปัญหาคือการเริ่มแบ่งมันเป็นงานเพื่อดำเนินการแทนที่จะพิจารณาหน่วยงานต่าง ๆ (วัตถุ) ที่มีอยู่และความสัมพันธ์ของพวกเขา ฉันมีหลักสูตรมหาวิทยาลัยใน OOP และเข้าใจพื้นฐานของการห่อหุ้มข้อมูลที่เป็นนามธรรมข้อมูลที่หลากหลายรูปแบบโมดูลย่อยและมรดก ผมอ่าน/programming/2688910/learning-to-think-in-the-object-oriented-wayและ/programming/1157847/learning-object-oriented-thinking , และจะดูหนังสือบางเล่มที่ชี้ไปยังคำตอบเหล่านั้น ฉันคิดว่าโครงการขนาดกลางถึงขนาดใหญ่หลายแห่งของฉันจะได้รับประโยชน์จากการใช้ OOP อย่างมีประสิทธิภาพ แต่ในฐานะมือใหม่ฉันต้องการหลีกเลี่ยงข้อผิดพลาดที่ใช้เวลานานและเสียเวลา จากประสบการณ์ของคุณข้อผิดพลาดเหล่านี้คืออะไรและมีวิธีการที่เหมาะสมรอบตัวพวกเขาอย่างไร หากคุณสามารถอธิบายได้ว่าทำไมพวกเขาถึงเป็นข้อผิดพลาดและวิธีที่ข้อเสนอแนะของคุณมีประสิทธิภาพในการจัดการกับปัญหานั้นจะได้รับการชื่นชม ฉันกำลังคิดตามแนวของบางอย่างเช่น "เป็นเรื่องปกติหรือไม่ที่จะมีผู้สังเกตการณ์และวิธีการปรับเปลี่ยนจำนวนพอสมควรและใช้ตัวแปรส่วนตัวหรือมีเทคนิคสำหรับการรวม / ลดพวกมัน?" ฉันไม่กังวลเกี่ยวกับการใช้ C ++ เป็นภาษา OO บริสุทธิ์หากมีเหตุผลที่ดีในการผสมวิธีการ (เตือนความจำถึงเหตุผลในการใช้ GOTO แม้ว่าจะ จำกัด อยู่เพียงเล็กน้อย) ขอบคุณ!

12
C ++ ไม่เหมาะสำหรับ OOP หรือไม่ [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้มีแนวโน้มที่จะเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา ฉันอ่านหนึ่งในคำตอบของคำถามที่นี่ (จำไม่ได้ว่า) C ++ ไม่เหมาะสำหรับการเขียนโปรแกรมเชิงวัตถุ มีบางคนพูดถึงว่าคุณสามารถใช้ประโยชน์จากคุณลักษณะหรืออะไรทำนองนั้น แต่ไม่ได้อยู่ในความหมายของ OOP อย่างแท้จริง (ฉันจริง ๆ ไม่เข้าใจว่าบุคคลนั้นหมายถึงอะไร) มีความจริงในเรื่องนี้บ้างไหม? ถ้าเป็นเช่นนั้นทำไม

4
เหตุใดจึงไม่มีคำจำกัดความที่สอดคล้องกันของแนวคิดที่สำคัญสำหรับ OOP
ฉันยังใหม่กับการเขียนโปรแกรมและสับสนเล็กน้อยจากการอ่าน \ ฟังการประชุมต่าง ๆ จากแหล่งต่าง ๆ : การโปรแกรมเชิงวัตถุมีแนวคิด 4 หรือ 5 หรือไม่? ในฐานะผู้มาใหม่ฉันเข้าใจว่านี่คือแนวคิด 5 ประการ: สิ่งที่เป็นนามธรรม มรดก encapsulation ความแตกต่าง modularity เหตุใดฉันจึงไม่พบคำจำกัดความที่ "เข้มงวดมากขึ้น" และดูเหมือนจะมีการจัดการแนวคิดเหล่านี้หลายอย่าง

4
ลำดับชั้นแบบขนาน - เหมือนกันบางส่วนแตกต่างกันเล็กน้อย
มีคำถามที่คล้ายกันอยู่สองสามข้อ 1 ,2 ,3 ,4แต่ดูเหมือนว่าไม่ใช่ในกรณีของคำถามนี้และการแก้ปัญหาก็ดูดีที่สุด นี่เป็นคำถามทั่วไปของ OOP โดยสมมติว่ามีหลายรูปแบบชื่อสามัญและมิกซ์อินมีอยู่ ภาษาจริงที่ใช้คือ OOP Javascript (Typescript) แต่เป็นปัญหาเดียวกันใน Java หรือ C ++ ฉันมีลำดับชั้นของชั้นเรียนแบบขนานซึ่งบางครั้งก็มีพฤติกรรมที่เหมือนกัน (ส่วนต่อประสานและการใช้งาน) แต่บางครั้งก็มีพฤติกรรมที่ 'ได้รับการป้องกัน' ของตัวเอง ภาพประกอบดังนี้: นี้สำหรับวัตถุประสงค์ในการประกอบการอธิบายเท่านั้น ; มันไม่ใช่แผนภาพคลาสที่แท้จริง หากต้องการอ่าน: สิ่งใดก็ตามในลำดับชั้นทั่วไป (กลาง) จะแชร์กันระหว่างทั้ง Canvas (ซ้าย) และ SVG (ขวา) ด้วยการแบ่งปันฉันหมายถึงทั้งอินเทอร์เฟซและการใช้งาน สิ่งใดก็ตามที่อยู่บนคอลัมน์ซ้ายหรือขวาหมายถึงพฤติกรรม (วิธีการและสมาชิก) เฉพาะสำหรับลำดับชั้นนั้น ตัวอย่างเช่น: ทั้งลำดับชั้นซ้ายและขวาใช้กลไกการตรวจสอบความถูกต้องเดียวกันแสดงเป็นวิธีการเดียว ( Viewee.validate()) ในลำดับชั้นทั่วไป paint()เพียงลำดับชั้นของผ้าใบมีวิธีการ วิธีนี้เรียกวิธีการทาสีบนเด็กทุกคน ลำดับชั้น SVG จำเป็นต้องแทนที่addChild()วิธีการCompositeแต่ไม่ได้เป็นกรณีที่มีลำดับชั้นของผืนผ้าใบ โครงสร้างจากลำดับชั้นทั้งสองไม่สามารถผสมกันได้ …

7
OOP พัฒนาขึ้นอย่างไรเพื่อรวมแนวคิดของ Properties
ฉันมาจากพื้นหลัง C ++ และหมดทุกอย่าง C # ในงานปัจจุบันของฉันและฉันเพิ่งอ่านคำถามมากมายเกี่ยวกับความแตกต่างระหว่างฟิลด์สาธารณะและคุณสมบัติและสิ่งที่แตกต่างและกลับมาในรูปแบบนี้ คำถามพื้นฐาน (เช่นโพสต์ SO นี้และคำถามที่เชื่อมโยงทั้งหมดที่เกี่ยวข้อง) คำถามทั้งหมดเหล่านี้ได้รับการแก้ไขในแง่ของความแตกต่างในทางปฏิบัติที่ได้รับการมีอยู่ของระบบทรัพย์สิน แต่ฉันคิดว่ามันเป็นการดีที่จะเข้าใกล้เรื่องนี้ในแง่ของสิ่งที่นักออกแบบของทุกภาษาที่ตัดสินใจสนับสนุนคุณสมบัติในครั้งแรก สถานที่กำลังคิด (ตรวจสอบรายชื่อในบทความ Wikipedia ที่นี่) OOP วิวัฒนาการมาจาก C ++ / Java เพื่อขยายสู่บทความ Wikipedia ที่น่าสนใจว่าเป็นตัวกลางระหว่างวิธีการและข้อมูลสมาชิกอย่างไร "นั่นคือคุณสมบัติจะอยู่ตรงกลางระหว่างรหัสสมาชิก (วิธีการ) และข้อมูลสมาชิก (ตัวแปรอินสแตนซ์) ของคลาสและคุณสมบัติให้ระดับการห่อหุ้มที่สูงกว่าเขตข้อมูลสาธารณะ" MSDNเพิ่มพื้นหลังเพิ่มเติม: "แม้ว่าคุณสมบัติจะคล้ายกันกับวิธีการทางเทคนิค แต่ก็แตกต่างกันมากในแง่ของสถานการณ์การใช้งานพวกเขาควรมองว่าเป็นสมาร์ทฟิลด์พวกเขามีการเรียกไวยากรณ์ของฟิลด์และความยืดหยุ่นของเมธอด" ฉันอยากจะรู้ว่ามันมาถึงแล้วในระดับปานกลางของการห่อหุ้มที่พิสูจน์แล้วว่ามีประโยชน์สำหรับการเขียนโปรแกรมโดยทั่วไป ฉันสมมติว่าแนวคิดนี้ไม่ได้เกิดขึ้นในการเขียนโปรแกรมภาษาแรกที่แสดงกระบวนทัศน์ OOP

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

1
ใช้รูปแบบผู้เข้าชมที่มีลำดับชั้นวัตถุขนาดใหญ่
บริบท ฉันได้ใช้กับลำดับชั้นของวัตถุ (ต้นไม้นิพจน์) รูปแบบผู้เข้าชม "หลอก" (หลอกเพราะมันไม่ได้ใช้ส่งสองครั้ง): public interface MyInterface { void Accept(SomeClass operationClass); } public class MyImpl : MyInterface { public void Accept(SomeClass operationClass) { operationClass.DoSomething(); operationClass.DoSomethingElse(); // ... and so on ... } } การออกแบบนี้เป็นที่ตั้งคำถาม แต่ค่อนข้างสะดวกสบายเนื่องจากจำนวนการใช้งานของ MyInterface มีความสำคัญ (~ 50 หรือมากกว่า) และฉันไม่จำเป็นต้องเพิ่มการดำเนินการเพิ่มเติม การใช้งานแต่ละอย่างนั้นไม่ซ้ำกัน (เป็นนิพจน์หรือตัวดำเนินการที่แตกต่างกัน) และบางรายการเป็นคอมโพสิต (เช่นโหนดโอเปอเรเตอร์ที่จะมีโอเปอเรเตอร์ / โหนดใบไม้) Traversal …

3
วิธีการหลักควรเป็นเพียงการสร้างวัตถุและการเรียกเมธอดเท่านั้น
เพื่อนของฉันบอกฉันว่าวิธีปฏิบัติที่ดีที่สุดคือคลาสที่มีmainเมธอดควรตั้งชื่อMainและมีmainเมธอดเท่านั้น นอกจากนี้mainวิธีการควรแยกวิเคราะห์อินพุตสร้างวัตถุอื่น ๆ และเรียกวิธีการอื่น ๆ Mainชั้นเรียนและmainวิธีการที่ไม่ควรจะทำอะไรก็ได้ โดยพื้นฐานสิ่งที่เขาพูดว่าคลาสที่มีmainเมธอดควรเป็นดังนี้ public class Main { public static void main(String[] args) { //parse inputs //create other objects //call methods } } มันเป็นวิธีปฏิบัติที่ดีที่สุด?

3
อนุสัญญาการตั้งชื่อทั่วไปสำหรับฟังก์ชั่นสาธารณะและส่วนตัวของ OO C คืออะไร? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว คำถามสั้น ๆ มีวิธีทั่วไปในการตั้งชื่อสมาชิก 'สาธารณะ' และ 'ส่วนตัว' ของโครงการ OO C หรือไม่? ประวัติความเป็นมา ผมเข้าใจว่าประชาชนและสมาชิกส่วนตัวไม่ได้จริงๆมีอยู่ในภาษา C อย่างไรก็ตามเช่นเดียวกับโปรแกรมเมอร์ C ส่วนใหญ่ฉันยังคงปฏิบัติต่อสมาชิกในฐานะสาธารณะหรือส่วนตัวเพื่อคงไว้ซึ่งการออกแบบ OO นอกเหนือจากวิธีการทั่วไปของ OO ฉันพบว่าตัวเองทำตามรูปแบบ (ดูตัวอย่างด้านล่าง) ซึ่งทำให้ฉันแยกแยะว่าวิธีใดมีความหมายสำหรับโลกภายนอกเทียบกับสมาชิกส่วนตัวที่อาจมีการตรวจสอบน้อยลง / มีประสิทธิภาพมากขึ้นเป็นต้น ... มีมาตรฐานหรือแนวปฏิบัติที่ดีที่สุดสำหรับสิ่งนั้นหรือเป็นตัวอย่างของฉันที่ด้านล่างเป็นวิธีที่ดีในการเข้าถึงสิ่งนี้หรือไม่? ส่วนหัวตัวอย่าง #ifndef _MODULE_X_H_ #define _MODULE_X_H_ bool MOD_X_get_variable_x(void); void MOD_X_set_variable_x(bool); #endif /* _MODULE_X_H_ */ ตัวอย่างแหล่งที่มา // Module Identifier: …

3
คุณเข้าใกล้การออกแบบคลาสใน OOP ได้อย่างไร
เมื่อฉันพยายามออกแบบโซลูชัน OO ฉันมักใช้การสร้างแบบจำลองCRCโดยที่ฉันแสดงรายการชื่อคลาส (คำนาม) สิ่งที่พวกเขาทำ (คำกริยา) และวิธีที่พวกเขาทำงานร่วมกับคลาสอื่น ๆ บล็อกนี้มีสิ่งด้านล่างที่จะพูดเกี่ยวกับวิธีการที่เป็นคำนามคำกริยานี้ ...This approach, which I will call “noun and verb,” is so limited I’ll dare to call it brain damaged.... คำถามของฉันคือมีเทคนิคการสร้างแบบจำลองที่ดีกว่าที่จะใช้วิธีการ OO หรือไม่?

5
คุณใช้ประโยชน์จากหลักการแบบเปิดหรือไม่
หลักการ open-closed (OCP) ระบุว่าควรเปิดวัตถุสำหรับส่วนขยาย แต่ปิดเพื่อทำการปรับเปลี่ยน ฉันเชื่อว่าฉันเข้าใจและใช้งานร่วมกับ SRP เพื่อสร้างคลาสที่ทำสิ่งเดียวเท่านั้น และฉันพยายามสร้างวิธีการขนาดเล็กจำนวนมากที่ทำให้สามารถแยกการควบคุมพฤติกรรมทั้งหมดออกเป็นวิธีที่อาจขยายหรือแทนที่ในคลาสย่อยบางประเภท ดังนั้นฉันจบลงด้วยคลาสที่มีคะแนนส่วนขยายมากมายไม่ว่าจะเป็น: การฉีดและองค์ประกอบ, เหตุการณ์, การมอบหมาย ฯลฯ พิจารณาคลาสที่เรียบง่ายและขยายได้ดังต่อไปนี้ class PaycheckCalculator { // ... protected decimal GetOvertimeFactor() { return 2.0M; } } ตอนนี้พูดเช่นว่าการOvertimeFactorเปลี่ยนแปลง 1.5 ตั้งแต่ระดับดังกล่าวข้างต้นได้รับการออกแบบมาเพื่อขยายฉันสามารถ subclass OvertimeFactorและกลับที่แตกต่างกัน แต่ ... แม้จะมีคลาสที่ถูกออกแบบมาสำหรับการขยายและการยึดติดกับ OCP ฉันจะแก้ไขวิธีการที่เป็นปัญหามากกว่าซับคลาสและแทนที่วิธีการที่มีปัญหา ด้วยเหตุนี้ฉันจึงละเมิดส่วนหนึ่งของความพยายามของ OCP ที่จะทำให้สำเร็จ รู้สึกเหมือนฉันเพิ่งขี้เกียจเพราะสิ่งที่กล่าวมานั้นง่ายกว่านิดหน่อย ฉันเข้าใจ OCP ผิดหรือเปล่า? ฉันควรจะทำอะไรที่แตกต่างออกไปจริงๆเหรอ? คุณใช้ประโยชน์จาก OCP ต่างกันหรือไม่ อัปเดต …

4
กระบวนทัศน์ที่ไม่ใช่ OOP สนับสนุนแนวคิดเช่นการห่อหุ้มหรือไม่?
หนึ่งในแนวคิดที่สำคัญในการเขียนโปรแกรมเชิงวัตถุคือ Encapsulation อย่างไรก็ตามเมื่อไม่นานมานี้โลกของซอฟต์แวร์ดูเหมือนจะเอียงไปทางกระบวนทัศน์อื่น ๆ เช่นการเขียนโปรแกรมการทำงาน มันทำให้ฉันคิดว่าสิ่งที่เกี่ยวกับการห่อหุ้มและหลักการ OOP อื่น ๆ ? พวกเขาผิดหรือเปล่า? มีการใช้ OOP ผิดหรือไม่ ตัวอย่างเช่น Alan Kay ถูกกล่าวถึงในการกล่าวคำปราศรัย OOPSLA'97: "ฉันคิดค้นคำว่า object-oriented และฉันสามารถบอกคุณได้ว่าฉันไม่มี C ++ ในใจ" Joe Armstrong - "วัตถุผูกฟังก์ชั่นและโครงสร้างข้อมูลร่วมกันในหน่วยแบ่งแยกฉันคิดว่านี่เป็นข้อผิดพลาดพื้นฐานเนื่องจากฟังก์ชั่นและโครงสร้างข้อมูลอยู่ในโลกที่แตกต่างกันโดยสิ้นเชิง"

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