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

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

22 object-oriented  programming-languages  inheritance 

นี่เป็นสถานการณ์ทั่วไปที่ทำให้ฉันต้องจัดการ ฉันมีโมเดลวัตถุที่มีวัตถุแม่ พาเรนต์มีวัตถุย่อยบางอย่าง บางสิ่งเช่นนี้ public class Zoo { public List<Animal> Animals { get; set; } public bool IsDirty { get; set; } } แต่ละวัตถุลูกมีข้อมูลและวิธีการต่าง ๆ public class Animal { public string Name { get; set; } public int Age { get; set; } public void MakeMess() { ... } } …

22 object-oriented  modeling 

class Boxer: def punch(self, punching_bag, strength): punching_bag.punch(strength) class PunchingBag: def punch(self, strength): print "Punching bag punched with strength", strength boxer = Boxer() punching_bag = PunchingBag() boxer.punch(punching_bag, 2) ไม่ต้องสงสัยเลยว่าpunchเป็นชื่อวิธีการที่ดีในกรณีนักมวย แต่ชื่อpunchก็ดีสำหรับวิธีการเจาะถุง ในทั้งสองกรณีฉันหมายถึงหมัดเป็นคำสั่ง (เช่นทำหมัด)

22 object-oriented 

obj.idดูเหมือนว่าค่อนข้างธรรมดาและดูเหมือนว่าจะตกอยู่ในช่วงของสิ่งที่วัตถุสามารถรู้เกี่ยวกับตัวเอง ฉันพบว่าตัวเองถามว่าทำไมวัตถุของฉันควรรู้รหัสของตัวเอง? ดูเหมือนจะไม่มีเหตุผลที่จะมีหรือไม่ หนึ่งในเหตุผลหลักสำหรับมันที่มีอยู่คือการดึงมันและดังนั้นที่เก็บของฉันจำเป็นต้องรู้และใช้เพื่อการโต้ตอบของฐานข้อมูล ฉันเคยพบปัญหาที่ฉันต้องการทำให้วัตถุเป็นอนุกรมกับ JSON สำหรับ RESTful API ซึ่ง ID ดูเหมือนจะไม่พอดีกับเพย์โหลด แต่มีเพียง URI และรวมไว้ในวัตถุทำให้ยากขึ้น วัตถุควรรู้ว่าเป็น id ของตัวเองหรือไม่? ทำไมหรือทำไมไม่? อัปเดต : ข้อกำหนด id: แอตทริบิวต์ตัวระบุบนวัตถุ ในแง่ฐานข้อมูลคีย์ตัวแทนไม่ได้เป็นคีย์ธรรมชาติ วัตถุ: เอนทิตีหรือวัตถุที่ระบุตัวตนไม่ซ้ำกันภายในระบบ

22 object-oriented  object-oriented-design 

Alan Kay อ้างว่า "ฉันสร้างคำว่า" เชิงวัตถุ "และฉันสามารถบอกคุณได้ว่าฉันไม่มี C ++ ในใจ" แน่นอนว่าเขามีสิ่งที่อยู่ในใจคือสมอลทอล์ค แต่เขาไม่ได้เขียนโปรแกรมเชิงวัตถุ เขาได้รับแนวคิดพื้นฐานจาก Simula ดังนั้นถ้าคำนั้นยังไม่ถูกประดิษฐ์ขึ้นมาพวกเขาเรียกการเขียนโปรแกรมเชิงวัตถุใน Simula ว่าอย่างไร?

22 object-oriented  history 

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

22 design  design-patterns  object-oriented 

ฉันมีคลาส CPP ซึ่งตัวสร้างทำการดำเนินการบางอย่าง การดำเนินการบางอย่างอาจล้มเหลว ฉันรู้ว่าผู้สร้างไม่คืนสิ่งใด คำถามของฉันคือ มันอนุญาตให้ดำเนินการบางอย่างอื่น ๆ ที่เริ่มต้นสมาชิกในนวกรรมิก? เป็นไปได้ไหมที่จะบอกฟังก์ชั่นการโทรว่าการทำงานบางอย่างใน Constructor ล้มเหลว? ฉันจะnew ClassName()คืนค่า NULL ได้ไหมหากมีข้อผิดพลาดเกิดขึ้นในตัวสร้าง?

21 object-oriented  c++ 

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

21 java  object-oriented  teamwork  communication  maintainability 

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

21 design-patterns  object-oriented  programming-practices  ruby 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา ฉันเห็นผู้พัฒนารายอื่นใช้คลาสคงที่เป็นเนมสเปซ public static class CategoryA { public class Item1 { public void DoSomething() { } } public class Item2 { public void DoSomething() { } } } public static class CategoryB { public class Item3 { public void DoSomething() …

21 c#  c++  object-oriented  static-typing  namespace 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ฉันได้ยินเมื่อเร็ว ๆ นี้อาจารย์ผู้สอนกล่าวว่าการพัฒนาเกมเป็นวิธีที่ดีที่สุดในการเรียนรู้การเขียนโปรแกรม นอกจากความจริงที่ว่าทุกอย่างจะต้องสร้างขึ้นในโค้ดเขาบอกว่าคุณจะได้รับประสบการณ์อย่างเต็มที่และนำ OOP ไปใช้ในโปรแกรมของคุณ ในคำอื่น ๆ ทุกสิ่งที่คุณทำในเกมเป็นวัตถุที่แท้จริงทั้งในทางเทคนิคและในแนวคิด การสร้างสมมติฐานนี้ปลอดภัยหรือไม่? หรือมีข้อยกเว้นเสมอเมื่อเรียนรู้การเขียนโปรแกรม? ทราบว่ามันมุ่งสู่. net / xna / c # การพัฒนา

21 learning  object-oriented 

ฉันได้รับมอบหมายให้รับแอปพลิเคชันรุ่นเก่าภายใต้การทดสอบหน่วย เริ่มจากพื้นฐานเกี่ยวกับแอปพลิเคชั่น: เป็นฐานรหัส LOC Java RCP 600k ที่มีปัญหาสำคัญเหล่านี้ การทำสำเนารหัสจำนวนมาก ไม่มีการห่อหุ้มข้อมูลส่วนตัวส่วนใหญ่สามารถเข้าถึงได้จากภายนอกข้อมูลทางธุรกิจบางส่วนยังสร้างซิงเกิลตันดังนั้นจึงไม่เพียง แต่เปลี่ยนแปลงจากภายนอก แต่ยังมาจากทุกที่ ไม่มี abstractions (เช่นไม่มีโมเดลธุรกิจข้อมูลธุรกิจถูกเก็บไว้ใน Object [] และ double [] []) ดังนั้นจึงไม่มี OO มีชุดทดสอบการถดถอยที่ดีและทีมงาน QA ที่มีประสิทธิภาพคือการทดสอบและค้นหาข้อบกพร่อง ฉันรู้เทคนิคในการทดสอบจากหนังสือคลาสสิกเช่น Michael Feathers แต่มันช้าเกินไป เนื่องจากมีระบบทดสอบการถดถอยที่ใช้งานได้ฉันจึงไม่กลัวที่จะทำการปรับโครงสร้างระบบใหม่อย่างจริงจังเพื่อให้สามารถเขียนการทดสอบหน่วยได้ ฉันจะเริ่มโจมตีปัญหาเพื่อให้ได้ความครอบคลุมได้อย่างรวดเร็วดังนั้นฉันจึงสามารถแสดงความคืบหน้าต่อการจัดการ (และอันที่จริงแล้วเริ่มมีรายได้จากความปลอดภัยของการทดสอบ JUnit) ฉันไม่ต้องการใช้เครื่องมือในการสร้างชุดทดสอบการถดถอยเช่น AgitarOne เพราะการทดสอบเหล่านี้ไม่ได้ทดสอบว่ามีบางอย่างถูกต้องหรือไม่

21 object-oriented  refactoring  test-coverage  junit 

สมมติว่าฉันมีอินเทอร์เฟซFooInterfaceที่มีลายเซ็นต่อไปนี้: interface FooInterface { public function doSomething(SomethingInterface something); } และคลาสรูปธรรมConcreteFooที่ใช้ส่วนต่อประสานนั้น: class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { } } ฉันต้องการConcreteFoo::doSomething()ทำสิ่งที่ไม่ซ้ำกันหากผ่านSomethingInterfaceวัตถุชนิดพิเศษ(สมมติว่ามันถูกเรียกว่าSpecialSomething) มันเป็นการละเมิด LSP อย่างแน่นอนถ้าฉันเพิ่มเงื่อนไขของวิธีการหรือสร้างข้อยกเว้นใหม่ แต่มันจะเป็นการละเมิด LSP หรือไม่ถ้าฉันใส่SpecialSomethingวัตถุพิเศษในขณะที่ให้ทางเลือกสำหรับSomethingInterfaceวัตถุทั่วไป? สิ่งที่ต้องการ: class ConcreteFoo implements FooInterface { public function doSomething(SomethingInterface something) { if (something instanceof SpecialSomething) { // Do SpecialSomething magic } …

20 object-oriented  solid  liskov-substitution 

ฉันจำไม่ได้เมื่อฉันเขียนชั้นเรียนทั่วไปครั้งที่แล้ว ทุกครั้งที่ฉันคิดว่าฉันต้องการมันหลังจากที่ฉันคิดว่าจะทำข้อสรุปที่ฉันทำไม่ได้ คำตอบที่สองสำหรับคำถามนี้ทำให้ฉันต้องขอคำชี้แจง (เนื่องจากฉันยังไม่สามารถแสดงความคิดเห็นได้ฉันจึงได้ตั้งคำถามใหม่) ดังนั้นลองใช้โค้ดที่ได้รับเป็นตัวอย่างของกรณีที่ใครต้องการยาชื่อสามัญ: public class Repository<T> where T : class, IBusinessOBject { T Get(int id) void Save(T obj); void Delete(T obj); } มันมีข้อ จำกัด ประเภท: IBusinessObject วิธีคิดตามปกติของฉันคือคลาสมีข้อ จำกัด ในการใช้IBusinessObjectดังนั้นคลาสที่ใช้สิ่งนี้Repositoryคือ พื้นที่เก็บข้อมูลเก็บลูกค้าเหล่านี้IBusinessObjectส่วนใหญ่ของสิ่งนี้Repositoryจะต้องการรับและใช้วัตถุผ่านIBusinessObjectอินเตอร์เฟซ ดังนั้นทำไมไม่เพียงเพื่อ public class Repository { IBusinessOBject Get(int id) void Save(IBusinessOBject obj); void Delete(IBusinessOBject obj); } ถึงแม้ว่าตัวอย่างจะไม่ดีเนื่องจากเป็นเพียงคอลเล็กชันอื่นและคอลเล็กชันทั่วไปคือคลาสสิก ในกรณีนี้ประเภทของข้อ จำกัด …

20 c#  object-oriented  interfaces  generics 

มีเหตุผลมากมายว่าทำไมคนรอบข้างจึงชั่วร้ายใน OOP หากจำนวนหรือขนาดของวัตถุที่ต้องการแบ่งปันมีขนาดใหญ่เกินไปที่จะส่งผ่านอย่างมีประสิทธิภาพในพารามิเตอร์ฟังก์ชั่นมักจะทุกคนแนะนำพึ่งพาการฉีดแทนวัตถุทั่วโลก อย่างไรก็ตามในกรณีที่เกือบทุกคนจำเป็นต้องรู้เกี่ยวกับโครงสร้างข้อมูลบางอย่างทำไมการพึ่งพาการฉีดจึงดีกว่าวัตถุระดับโลก ตัวอย่าง (ตัวย่อที่เรียบง่ายเพื่อแสดงจุดโดยทั่วไปโดยไม่ต้องเจาะลึกในแอปพลิเคชันเฉพาะ) มีรถยนต์เสมือนจำนวนมากที่มีคุณสมบัติและสถานะจำนวนมากตั้งแต่ประเภทชื่อสีไปจนถึงความเร็วตำแหน่ง ฯลฯ ผู้ใช้จำนวนมากสามารถควบคุมจากระยะไกลและเหตุการณ์จำนวนมาก (ทั้งผู้ใช้ - เริ่มต้นและอัตโนมัติ) สามารถเปลี่ยนสถานะหรือคุณสมบัติได้มากมาย วิธีการแก้ปัญหาที่ไร้เดียงสาคือการสร้างภาชนะใส่ของโลกเช่น vector<Vehicle> vehicles; ซึ่งสามารถเข้าถึงได้จากทุกที่ วิธีแก้ปัญหาที่เป็นมิตรกับ OOP ก็คือให้มีคอนเทนเนอร์เป็นสมาชิกของคลาสที่จัดการห่วงเหตุการณ์หลักและถูกสร้างอินสแตนซ์ในตัวสร้าง ทุกคลาสที่ต้องการมันและเป็นสมาชิกของเธรดหลักจะได้รับการเข้าถึงคอนเทนเนอร์ผ่านตัวชี้ในตัวสร้างของพวกเขา ตัวอย่างเช่นหากข้อความภายนอกเข้ามาผ่านการเชื่อมต่อเครือข่ายคลาส (หนึ่งสำหรับแต่ละการเชื่อมต่อ) การจัดการการแยกจะใช้เวลามากกว่าและ parser จะเข้าถึงคอนเทนเนอร์ผ่านตัวชี้หรือการอ้างอิง ตอนนี้ถ้าข้อความที่วิเคราะห์คำส่งผลให้เกิดการเปลี่ยนแปลงในองค์ประกอบของคอนเทนเนอร์หรือต้องการข้อมูลบางส่วนเพื่อดำเนินการก็สามารถจัดการได้โดยไม่จำเป็นต้องสลับตัวแปรหลายพันตัวผ่านสัญญาณและช่องเสียบ (หรือแย่กว่านั้น เก็บไว้ใน parser ที่จะเรียกคืนในภายหลังโดยผู้ที่เรียกว่า parser) แน่นอนว่าคลาสทั้งหมดที่ได้รับการเข้าถึงคอนเทนเนอร์ผ่านการฉีดเป็นส่วนหนึ่งของเธรดเดียวกัน เธรดที่แตกต่างกันจะไม่สามารถเข้าถึงได้โดยตรง แต่ทำงานของพวกเขาแล้วส่งสัญญาณไปยังเธรดหลักและสล็อตในเธรดหลักจะอัพเดตคอนเทนเนอร์ อย่างไรก็ตามถ้าส่วนใหญ่ของคลาสจะเข้าถึงคอนเทนเนอร์สิ่งที่ทำให้แตกต่างจากส่วนกลาง หากคลาสจำนวนมากต้องการข้อมูลในคอนเทนเนอร์ไม่ใช่ "วิธีการฉีดพึ่งพา" เป็นเพียงระบบปลอมทั่วโลกใช่หรือไม่ คำตอบหนึ่งก็คือความปลอดภัยของเธรด: แม้ว่าฉันจะระวังไม่ให้ใช้ภาชนะที่ไม่เหมาะสมกับผู้ใช้ทั่วโลกบางทีผู้พัฒนารายอื่นในอนาคตภายใต้แรงกดดันของเส้นตายที่ใกล้จะถึงกระนั้นก็ตาม กรณีการปะทะกัน อย่างไรก็ตามแม้ในกรณีของการฉีดพึ่งพาใครสามารถชี้ให้คนที่ทำงานในหัวข้ออื่นที่นำไปสู่ปัญหาเดียวกัน

20 design-patterns  object-oriented  dependency-injection