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

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดเมื่อปีที่แล้ว ฉันพยายามที่จะเข้าใจว่า Polymorphism ใช้ในโครงการชีวิตจริง แต่ฉันสามารถหาตัวอย่างคลาสสิก (หรือบางอย่างที่คล้ายกัน) ของการมีAnimalคลาสผู้ปกครองด้วยวิธีการspeak()และชั้นเรียนเด็กจำนวนมากที่แทนที่วิธีนี้และตอนนี้ คุณสามารถเรียกใช้เมธอดspeak()บนอ็อบเจ็กต์ลูกใด ๆ ตัวอย่างเช่น: Animal animal; animal = dog; animal.speak(); animal = cat; animal.speak();

17 object-oriented  data-structures  polymorphism 

ฉันได้เรียนรู้ C # ในช่วงหกเดือนที่ผ่านมาและตอนนี้ฉันกำลังขุดหา Java คำถามของฉันเกี่ยวกับการสร้างอินสแตนซ์ (ในทั้งสองภาษาจริง ๆ ) และมีมากกว่า: ฉันสงสัยว่าทำไมพวกเขาถึงทำแบบนั้น นำตัวอย่างนี้ Person Bob = new Person(); มีเหตุผลที่ระบุวัตถุสองครั้งหรือไม่ เคยมีsomething_else Bob = new Person()บ้างไหม? ดูเหมือนว่าถ้าฉันทำตามจากการประชุมมันจะเป็นเหมือน: int XIsAnInt; Person BobIsAPerson; หรืออาจเป็นหนึ่งในสิ่งเหล่านี้: Person() Bob; new Person Bob; new Person() Bob; Bob = new Person(); ฉันคิดว่าฉันอยากรู้ว่าถ้ามีคำตอบที่ดีกว่า "นั่นเป็นเพียงวิธีที่มันทำ"

17 java  c#  object-oriented 

ในรหัส Java ส่วนใหญ่ฉันเห็นคนประกาศวัตถุ Java เช่นนี้: Map<String, String> hashMap = new HashMap<>(); List<String> list = new ArrayList<>(); แทน: HashMap<String, String> hashMap = new HashMap<>(); ArrayList<String> list = new ArrayList<>(); ทำไมจึงมีการตั้งค่าเพื่อกำหนดวัตถุ Java โดยใช้อินเตอร์เฟซมากกว่าการใช้งานที่จะใช้จริง?

17 java  object-oriented  class-design 

ฉันสงสัยว่าฉันทำผิดพลาดกับเด็กนักเรียนที่นี่และกำลังมองหาการชี้แจง เรียนจำนวนมากในโซลูชันของฉัน (C #) - ฉันกล้าพูดส่วนใหญ่ - ฉันสิ้นสุดการเขียนอินเทอร์เฟซที่สอดคล้องกันสำหรับ เช่นอินเทอร์เฟซ "ICalculator" และคลาส "เครื่องคิดเลข" ที่ใช้งานแม้ว่าฉันจะไม่เคยเปลี่ยนเครื่องคิดเลขนั้นด้วยการใช้งานที่แตกต่างกัน นอกจากนี้คลาสเหล่านี้ส่วนใหญ่อาศัยอยู่ในโครงการเดียวกันกับการพึ่งพาของพวกเขา - พวกเขาเพียง แต่จะต้องเป็นinternalจริง แต่ได้กลายpublicเป็นผลข้างเคียงของการใช้อินเทอร์เฟซที่เกี่ยวข้องของพวกเขา ฉันคิดว่าวิธีนี้ในการสร้างส่วนต่อประสานสำหรับทุกสิ่งที่เกิดขึ้นจากความผิดพลาดเล็กน้อย: - 1) ตอนแรกฉันคิดว่าอินเตอร์เฟสจำเป็นต้องสร้างหน่วยทดสอบ mocks (ฉันใช้ Moq) แต่ตั้งแต่ฉันค้นพบว่าคลาสสามารถเยาะเย้ยถ้าสมาชิกเป็นสมาชิกvirtualและมีคอนสตรัคเตอร์แบบไม่ใช้พารามิเตอร์ (แก้ไขฉันถ้า ฉันผิด). 2) ตอนแรกฉันคิดว่าจำเป็นต้องใช้อินเทอร์เฟซในการลงทะเบียนชั้นเรียนด้วยกรอบ IoC (Castle Windsor) เช่น Container.Register(Component.For<ICalculator>().ImplementedBy<Calculator>()... เมื่อในความเป็นจริงฉันสามารถลงทะเบียนประเภทคอนกรีตกับตัวเอง: Container.Register(Component.For<Calculator>().ImplementedBy<Calculator>()... 3) การใช้อินเตอร์เฟสเช่นพารามิเตอร์คอนสตรัคเตอร์สำหรับการฉีดแบบพึ่งพาผลลัพธ์ใน "การเชื่อมต่อแบบหลวม" ดังนั้นฉันจึงโกรธกับอินเทอร์เฟซ! ฉันตระหนักถึงสถานการณ์ที่คุณจะ "ปกติ" ใช้อินเทอร์เฟซเช่นเปิดเผย API สาธารณะหรือสิ่งต่าง ๆ เช่นฟังก์ชัน "เสียบได้" โซลูชันของฉันมีคลาสจำนวนเล็กน้อยที่เหมาะสมกับกรณีการใช้งานดังกล่าว …

17 object-oriented  interfaces  dependency-injection 

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

17 object-oriented  duck-typing  polymorphism 

พิจารณานักออกแบบ UI สองคนที่ต้องการออกแบบการออกแบบที่“ ดึงดูดผู้ใช้” "การดึงดูดผู้ใช้" เป็นแนวคิดที่ไม่ได้มีวัตถุประสงค์และอยู่ในใจของนักออกแบบเท่านั้น ดังนั้นผู้ออกแบบสามารถยกตัวอย่างเช่นสีแดงในขณะที่นักออกแบบ B เลือกสีน้ำเงิน นักออกแบบ A สร้างเลย์เอาต์ที่แตกต่างอย่างสิ้นเชิงจากดีไซเนอร์ B และอื่น ๆ ฉันอ่านเกี่ยวกับ SRP (Single Responsibility Principle) และสิ่งที่ฉันเข้าใจคือการวิเคราะห์เชิงอัตวิสัยหรือการแยกความรับผิดชอบที่อาจแตกต่างจากนักออกแบบ OO ถึงผู้ออกแบบ OO คนอื่น ฉันถูกไหม? กล่าวอีกนัยหนึ่งเป็นไปได้หรือไม่ที่จะมีตัววิเคราะห์เชิงวัตถุสองตัวที่ยอดเยี่ยมและผู้ออกแบบที่มาพร้อมกับการออกแบบที่แตกต่างกันสองแบบสำหรับหนึ่งระบบโดยยึดตามหลักการ SRP

17 object-oriented  object-oriented-design  single-responsibility  ooda 

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

17 object-oriented  teamwork 

มีปัญหา OOP แบบคลาสสิกของวิธีการผูกมัด vs วิธีการ "จุดเชื่อมต่อจุดเดียว": main.getA().getB().getC().transmogrify(x, y) VS main.getA().transmogrifyMyC(x, y) ครั้งแรกที่ดูเหมือนว่าจะมีข้อได้เปรียบที่แต่ละชั้นมีความรับผิดชอบสำหรับชุดปฏิบัติการขนาดเล็กเท่านั้นและทำให้ทุกอย่างเป็นแบบแยกส่วนมากขึ้น- การเพิ่มวิธีการใน C ไม่ต้องใช้ความพยายามใน A, B หรือ C เพื่อเปิดเผย ข้อเสียของหลักสูตรคือการห่อหุ้มที่อ่อนแอซึ่งรหัสที่สองแก้ ตอนนี้ A มีการควบคุมทุกวิธีที่ผ่านมันและสามารถมอบมันให้กับเขตข้อมูลของมันถ้ามันต้องการ ฉันรู้ว่าไม่มีวิธีแก้ปัญหาเดียวและแน่นอนขึ้นอยู่กับบริบท แต่ฉันอยากได้ยินบางอย่างเกี่ยวกับความแตกต่างที่สำคัญระหว่างสไตล์สองแบบและภายใต้สถานการณ์ใดที่ฉันควรเลือกแบบใดแบบหนึ่ง - เพราะตอนนี้เมื่อฉันลอง เพื่อออกแบบรหัสฉันรู้สึกว่าฉันไม่ได้ใช้อาร์กิวเมนต์เพื่อตัดสินใจทางเดียวหรืออื่น ๆ

17 object-oriented  encapsulation 

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

17 object-oriented 

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

17 object-oriented  code-reuse 

ใน Java มีตัวดัดแปลงการเข้าถึงที่ใช้ได้สี่วิธีสำหรับวิธีการ: public - คลาสใด ๆ สามารถใช้วิธีนี้ protected - คลาสในแพ็คเกจเดียวกันและคลาสย่อยในแพ็คเกจใด ๆ สามารถใช้วิธีนี้ได้ private - คลาสนี้เท่านั้นที่สามารถใช้วิธีนี้ no modifier ("แพ็คเกจส่วนตัว") - เฉพาะคลาสในแพ็คเกจเดียวกันเท่านั้นที่สามารถใช้วิธีนี้ได้ สิ่งที่เกิดขึ้นบ่อยครั้งคือฉันต้องการมีวิธีการที่มีประโยชน์ในซูเปอร์คลาสซึ่งคลาสย่อยทั้งหมดสามารถใช้ได้ แต่มันจะไม่สมเหตุสมผลสำหรับคลาสอื่น ๆ ในการเข้าถึงวิธีการนี้ ดังนั้นฉันจึงต้องประกาศวิธีการที่มีประโยชน์เหล่านี้ในซูเปอร์คลาสpublicหรือprotectedซึ่งเปิดเผยให้คลาสอื่น ๆ ทั้งหมดอย่างน้อยในแพ็คเกจ แม้ว่าคลาสย่อยเหล่านี้จะถูกใช้เพื่อการใช้งานเท่านั้น มีเหตุผลที่ไม่มีsubclasses-onlyตัวดัดแปลงการเข้าถึงใน Java หรือไม่? ดูเหมือนแปลกมากสำหรับฉัน ฉันพลาดอะไรไปรึเปล่า? นอกจากนี้subclasses-onlyตัวดัดแปลงการเข้าถึงจะมีประโยชน์เมื่อคุณต้องการเปิดเผยตัวแปรเฉพาะคลาสย่อย ซึ่งสำหรับฉันเกิดขึ้นมาก

17 java  object-oriented  inheritance  language-features 

ภาวะที่กลืนไม่เข้าคายไม่ออก ฉันได้อ่านหนังสือฝึกหัดที่ดีที่สุดมากมายเกี่ยวกับการฝึกฝนเชิงวัตถุและหนังสือเกือบทุกเล่มที่ฉันอ่านมีส่วนที่พวกเขาบอกว่า enums เป็นกลิ่นรหัส ฉันคิดว่าพวกเขาพลาดส่วนที่พวกเขาอธิบายเมื่อ enums ถูกต้อง ดังนั้นฉันกำลังมองหาแนวทางและ / หรือกรณีการใช้งานที่ enums ไม่ได้กลิ่นรหัสและในความเป็นจริงโครงสร้างที่ถูกต้อง แหล่งที่มา: "คำเตือนตามกฎของหัวแม่มือ, enums เป็นรหัสที่มีกลิ่นและควรได้รับการ refactored เพื่อเรียน polymorphic [8]" Seemann, Mark, การฉีดพึ่งพาใน. Net, 2011, p. 342 [8] Martin Fowler et al., Refactoring: การปรับปรุงการออกแบบของรหัสที่มีอยู่ (นิวยอร์ก: Addison-Wesley, 1999), 82 บริบท สาเหตุของภาวะที่กลืนไม่เข้าคายไม่ออกของฉันคือการซื้อขาย API พวกเขาให้กระแสข้อมูล Tick โดยส่งผ่านวิธีนี้: void TickPrice(TickType tickType, double value) ที่ไหน …

17 c#  design-patterns  object-oriented  refactoring  enum 

หลักการความรับผิดชอบเดี่ยวระบุว่า "คลาสควรมีเหตุผลประการเดียวคือการเปลี่ยนแปลง" ในรูปแบบ MVC งานของผู้ควบคุมจะเป็นสื่อกลางระหว่างมุมมองและรูปแบบ มันมีอินเทอร์เฟซสำหรับมุมมองเพื่อรายงานการกระทำของผู้ใช้บน GUI (เช่นการอนุญาตให้ดูการโทรcontroller.specificButtonPressed()) และสามารถเรียกวิธีการที่เหมาะสมในตัวแบบเพื่อจัดการข้อมูลหรือเรียกใช้การดำเนินการ (เช่นmodel.doSomething()) . ซึ่งหมายความว่า: คอนโทรลเลอร์จำเป็นต้องรู้เกี่ยวกับ GUI เพื่อเสนอมุมมองอินเทอร์เฟซที่เหมาะสมเพื่อรายงานการกระทำของผู้ใช้ นอกจากนี้ยังจำเป็นต้องรู้เกี่ยวกับตรรกะในรูปแบบเพื่อที่จะสามารถเรียกใช้วิธีการที่เหมาะสมในรูปแบบ นั่นหมายความว่ามีสองเหตุผลในการเปลี่ยนแปลง : การเปลี่ยนแปลงใน GUI และการเปลี่ยนแปลงในตรรกะธุรกิจ หากมีการเปลี่ยนแปลง GUI เช่นมีการเพิ่มปุ่มใหม่ตัวควบคุมอาจต้องเพิ่มวิธีการใหม่เพื่อให้มุมมองรายงานผู้ใช้กดปุ่มนี้ และหากตรรกะทางธุรกิจในรูปแบบการเปลี่ยนแปลงผู้ควบคุมอาจต้องเปลี่ยนเพื่อที่จะเรียกใช้วิธีการที่ถูกต้องในรูปแบบ ดังนั้นการควบคุมมีสองเหตุผลที่เป็นไปได้ที่จะมีการเปลี่ยนแปลง มันทำลาย SRP หรือไม่

16 design  object-oriented  mvc  single-responsibility 

ขณะนี้ฉันมีคลาสที่ได้รับสองคลาสAและBที่ทั้งสองมีเขตข้อมูลร่วมกันและฉันพยายามที่จะตรวจสอบว่ามันควรจะขึ้นไปในชั้นฐาน มันไม่เคยอ้างถึงจากชั้นฐานและบอกว่าในบางจุดลงมาที่ถนนอีกชั้นจะได้รับCที่ไม่ได้_field1แล้วจะไม่เป็นหลักของ "สิทธิพิเศษน้อย" (หรือบางสิ่งบางอย่าง) ถ้ามันถูกละเมิด เป็น? public abstract class Base { // Should _field1 be brought up to Base? //protected int Field1 { get; set; } } public class A : Base { private int _field1; } public class B : Base { private int _field1; } public class C …

16 object-oriented  inheritance  abstract-class 

ขณะนี้ฉันอยู่ในขั้นตอนการออกแบบ (อีกครั้ง) ของคลาสรุ่นต่างๆของแอปพลิเคชัน C # .NET (โมเดลดังใน M ของ MVC) คลาสโมเดลมีข้อมูลพฤติกรรมและความสัมพันธ์ซึ่งได้รับการออกแบบมาเป็นอย่างดี ฉันเขียนแบบจำลองใหม่จาก Python เป็น C # ใน Python model ฉันคิดว่าฉันเห็นหูด แต่ละรุ่นรู้วิธีการทำให้เป็นอันดับตัวเองและตรรกะการทำให้เป็นอันดับไม่มีส่วนเกี่ยวข้องกับพฤติกรรมที่เหลือของคลาสใด ๆ ตัวอย่างเช่นลองนึกภาพ: Imageชั้นเรียนด้วย.toJPG(String filePath) .fromJPG(String filePath)วิธีการ ImageMetaDataชั้นเรียนด้วย.toString()และ.fromString(String serialized)วิธีการ คุณสามารถจินตนาการได้ว่าวิธีการทำให้เป็นอันดับเหล่านี้ไม่ได้เชื่อมโยงกับส่วนที่เหลือของชั้นเรียน แต่มีเพียงชั้นเรียนเท่านั้นที่สามารถรับประกันได้ว่าจะรู้ข้อมูลที่เพียงพอในการทำให้เป็นอันดับตัวเอง มันเป็นเรื่องธรรมดาสำหรับชั้นเรียนหรือไม่ที่จะรู้วิธีการทำให้เป็นอันดับและทำให้เสียความเป็นตัวของตัวเอง? หรือฉันไม่มีรูปแบบทั่วไป

16 c#  object-oriented  python  serialization