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

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

7
หลีกเลี่ยงกฎในพ่อมดและนักรบ
ในบทความบล็อกชุดนี้ Eric Lippert อธิบายถึงปัญหาในการออกแบบเชิงวัตถุโดยใช้พ่อมดและนักรบเป็นตัวอย่างโดยที่: abstract class Weapon { } sealed class Staff : Weapon { } sealed class Sword : Weapon { } abstract class Player { public Weapon Weapon { get; set; } } sealed class Wizard : Player { } sealed class Warrior : Player { } แล้วเพิ่มกฎสองสามข้อ: …

3
มันตกลงหรือไม่สำหรับอินเตอร์เฟสที่ต้องพึ่งพาคลาสที่เป็นรูปธรรม?
ฉันกำลังสร้างส่วนติดต่อใน Java สำหรับตัวจัดการข้อผิดพลาดที่กำหนดเอง ต้องการส่งผ่านข้อผิดพลาดวัตถุข้อโต้แย้ง แต่ฉันต้องการมันเป็นลูกของExceptionชั้น จะใช้ชื่อคลาสที่กำหนดในอินเทอร์เฟซได้หรือไม่ มันจะทำให้อินเทอร์เฟซน้อยลงหรือไม่ขึ้นอยู่กับการใช้งานใด ๆ ฉันพยายามทำสิ่งนี้: public class CustomException { /* ... Implementation ... */ } public interface Interface { void onError(CustomException ex); }

1
ดูเหมือนว่าการเข้าร่วมของ Python จะไม่ได้มุ่งเน้นไปที่รายการที่จะเข้าร่วม แต่บนสัญลักษณ์เมื่อเทียบกับ Ruby หรือ Smalltalk ด้วยเหตุผลด้านการออกแบบ
ฉันคิดว่าหนึ่งในหลักสำคัญของ OOP คือเรามีวัตถุซึ่งเป็นรายการที่เราสนใจในการจัดการและจากนั้นเราส่งข้อความถึงพวกเขา ดังนั้นมันอาจดูเป็นธรรมชาติที่ฉันมีของสะสมและฉันจำเป็นต้องใส่มันเข้าไปในสายเดียวเพื่อที่จะทำมัน: ["x", "o", "o"].join(" | ") # joining a tic-tac-toe row in Ruby (Smalltalk ทำเช่นเดียวกัน) " | "เป็นในทางที่บางคนคิดว่าการเป็นอาร์กิวเมนต์หนึ่งสัญลักษณ์ของวิธีการที่จะเข้าร่วมได้ อาจเป็น" "เช่นเดียวกันหากบอร์ดเกมนั้นเรียบง่ายขึ้น ดังนั้นองค์ประกอบการเข้าร่วม" | "ไม่ใช่สิ่งที่เราสนใจโดยเฉพาะ - มันไม่ใช่วัตถุหลักในโปรแกรมที่มีความสำคัญหรือความสำคัญเป็นพิเศษ ถ้า Python ใช้งาน " | ".join(["x", "o", "o"]) มันรู้สึกค่อนข้างแปลกที่เกือบจะรู้สึกเหมือนว่าเรากำลังส่งข้อความไปยังการโต้แย้งเพื่อบอกข้อโต้แย้งเกี่ยวกับบางสิ่ง Python อาจจะเป็นขั้นตอนมากกว่านี้ใช่ไหม เพื่อบอกให้สายการเข้าร่วมทำหน้าที่ให้เราบ้างไหม? เป็นการบันทึกการนำไปปฏิบัติเพื่อที่เราจะได้ไม่ต้องกำหนดjoinคลาสสำหรับคอลเลกชั่นแต่ละคลาสที่เรามี? แต่มันไม่เป็นความจริงเลยที่เราสามารถเขียนคลาสคอลเลกชันใด ๆ ก็ได้เช่นใน Ruby: module Enumerable def my_join(joiner) self.inject …

2
การแยกส่วนอินเทอร์เฟซหลักการ: จะทำอย่างไรถ้าส่วนต่อประสานมีการทับซ้อนกันอย่างมีนัยสำคัญ?
จากการพัฒนาซอฟต์แวร์หลักการรูปแบบและการปฏิบัติ: Pearson New International Edition : บางครั้งวิธีที่เรียกใช้โดยกลุ่มลูกค้าที่แตกต่างกันจะทับซ้อนกัน หากการซ้อนทับมีขนาดเล็กดังนั้นอินเทอร์เฟซสำหรับกลุ่มควรจะแยกจากกัน ควรประกาศฟังก์ชันทั่วไปในอินเทอร์เฟซที่ทับซ้อนกันทั้งหมด คลาสเซิร์ฟเวอร์จะสืบทอดฟังก์ชันทั่วไปจากแต่ละอินเตอร์เฟสเหล่านั้น แต่จะใช้งานเพียงครั้งเดียว ลุงบ๊อบพูดถึงกรณีที่มีการเหลื่อมกันเล็กน้อย เราควรทำอย่างไรหากมีการทับซ้อนอย่างมีนัยสำคัญ บอกว่าเรามี Class UiInterface1; Class UiInterface2; Class UiInterface3; Class UiIterface : public UiInterface1, public UiInterface2, public UiInterface3{}; เราควรทำอย่างไรหากมีการทับซ้อนกันระหว่างUiInterface1และUiInterface2?

2
เหตุใดจึงไม่เหมาะสมที่จะใช้ไดอะแกรม UML เพื่อวางแผนว่าจะจัดระเบียบรหัสของคุณอย่างไร
ดังนั้นใช่ไดอะแกรมอาจไม่เหมาะสมในบางครั้ง เมื่อใดที่ไม่เหมาะสม เมื่อคุณสร้างพวกเขาโดยไม่มีรหัสเพื่อตรวจสอบพวกเขาแล้วตั้งใจที่จะติดตามพวกเขา ไม่มีอะไรผิดปกติกับการวาดไดอะแกรมเพื่อสำรวจความคิด การพัฒนาซอฟต์แวร์แบบว่องไว: หลักการรูปแบบและการปฏิบัติ - Robert C. Martin สิ่งนี้หมายความว่าอย่างไร UML ไม่ได้ออกแบบมาเพื่อช่วยวางแผนวิธีจัดโครงสร้างโค้ดของคุณก่อน "ลงมือดำน้ำ" หรือไม่? อะไรคือจุดประสงค์ของการใช้มันถ้าคุณไม่ทำตามไดอะแกรมที่คุณคิดขึ้นมา บริบท: ในบทนี้ลุงบ็อบจัดทำแผนภาพ UML สำหรับผู้รักษาคะแนนของเกมโบว์ลิ่ง จากนั้นเขาก็ไปพัฒนาโปรแกรมในลักษณะทดสอบการขับเคลื่อนโดยไม่ปรึกษาแผนภาพ UML โปรแกรมที่ได้นั้นไม่มีอะไรเหมือนกับแผนภาพ UML และลุงบ๊อบก็มาถึงข้อสรุปที่กล่าวไว้ข้างต้น

2
ควรระบุ ID ธุรกิจที่เป็นที่รู้จักกันดีของกิจการด้วยประเภทเฉพาะใน DDD / OOP หรือไม่
ในแง่การปฏิบัติมันหมายถึงการใช้กำหนดเอง (ไม่เปลี่ยนรูป) classมากกว่าstringหรือบางประเภทดั้งเดิมอื่น ๆ ตัวอย่าง: สำนักพิมพ์: หมายเลขหนังสือมาตรฐานสากล การเงิน: หมายเลขประจำตัวของหลักทรัพย์ระหว่างประเทศ ข้อดี: สามารถมั่นใจได้ว่ารูปแบบของตัวระบุ กลายเป็นสมาชิกชั้นหนึ่งของโมเดล ข้อเสีย: เพิ่มแรงเสียดทานติดตา (เช่น Entity Framework) รหัสเพิ่มเติม

4
ฉันจะให้วัตถุโต้ตอบและสื่อสารกันโดยไม่บังคับลำดับชั้นได้อย่างไร
ฉันหวังว่าการพูดจาโผงผางเหล่านี้จะทำให้คำถามของฉันชัดเจน - ฉันเข้าใจโดยสิ้นเชิงถ้าพวกเขาไม่ได้ดังนั้นแจ้งให้เราทราบว่าเป็นกรณีนี้และฉันจะพยายามทำให้ตัวเองชัดเจนขึ้น พบกับBoxPongเกมง่ายๆที่ฉันสร้างความคุ้นเคยกับการพัฒนาเกมเชิงวัตถุ ลากกล่องเพื่อควบคุมลูกบอลและรวบรวมสิ่งที่เป็นสีเหลือง การทำให้ BoxPong ช่วยฉันกำหนดคำถามพื้นฐาน: ฉันจะมีวัตถุที่มีปฏิสัมพันธ์ซึ่งกันและกันโดยไม่ต้อง "เป็น" กันได้อย่างไร กล่าวอีกนัยหนึ่งมีวิธีที่วัตถุจะไม่เป็นลำดับชั้น แต่แทนที่จะอยู่ร่วมกันหรือไม่ (ฉันจะเข้าไปดูรายละเอียดเพิ่มเติมด้านล่าง) ฉันสงสัยว่าปัญหาของวัตถุที่อยู่ร่วมกันนั้นเป็นปัญหาทั่วไปดังนั้นฉันหวังว่าจะมีวิธีการแก้ไขที่แน่นอน ฉันไม่ต้องการที่จะสร้างใหม่ล้อสี่เหลี่ยมดังนั้นฉันเดาคำตอบที่ดีที่สุดที่ฉันกำลังมองหาคือ "นี่เป็นรูปแบบการออกแบบที่ใช้กันทั่วไปในการแก้ปัญหาของคุณ" โดยเฉพาะอย่างยิ่งในเกมง่ายๆเช่น BoxPong เป็นที่ชัดเจนว่ามีหรือควรมีวัตถุจำนวนหนึ่งอยู่ร่วมกันในระดับเดียวกัน มีกล่องมีลูกบอลมีของสะสม ทั้งหมดที่ฉันสามารถแสดงในภาษาเชิงวัตถุแม้ว่า - หรือเพื่อให้ดูเหมือน - มีความสัมพันธ์HAS-A ที่เข้มงวด ทำผ่านตัวแปรสมาชิก ฉันไม่สามารถเริ่มballและปล่อยให้มันทำสิ่งนั้นฉันต้องการให้มันเป็นของวัตถุอื่นอย่างถาวร ฉันได้ตั้งค่าเพื่อให้วัตถุหลักของเกมมีกล่องและกล่องนั้นมีลูกบอลและมีตัวนับคะแนน แต่ละวัตถุยังมีupdate()วิธีการซึ่งจะคำนวณตำแหน่งทิศทาง ฯลฯ และฉันไปลักษณะที่คล้ายกันที่นั่นผมเรียกวิธีการอัพเดตเกมวัตถุหลักซึ่งเรียกวิธีการปรับปรุงของเด็กทุกคนของตนและพวกเขาในทางกลับกันเรียกวิธีการปรับปรุงทั้งหมดของพวกเขาเด็ก นี่เป็นวิธีเดียวที่ฉันสามารถเห็นการสร้างเกมเชิงวัตถุ แต่ฉันรู้สึกว่ามันไม่ใช่วิธีที่เหมาะ ท้ายที่สุดฉันจะไม่คิดว่าลูกบอลเป็นของกล่อง แต่อยู่ในระดับเดียวกันและมีปฏิสัมพันธ์กับมัน ฉันคิดว่าสามารถทำได้โดยการเปลี่ยนวัตถุเกมทั้งหมดเป็นตัวแปรสมาชิกของวัตถุเกมหลัก แต่ฉันไม่เห็นว่าการแก้ปัญหาอะไร ฉันหมายถึง ... ทิ้งความยุ่งเหยิงที่เห็นได้ชัดจะมีวิธีใดสำหรับลูกบอลและกล่องที่จะรู้จักซึ่งกันและกันนั่นคือการโต้ตอบ? นอกจากนี้ยังมีปัญหาของวัตถุที่ต้องการส่งผ่านข้อมูลระหว่างกัน ฉันมีประสบการณ์ค่อนข้างน้อยในการเขียนโค้ดสำหรับ SNES ซึ่งคุณสามารถเข้าถึง RAM ทั้งหมดได้ตลอดเวลา สมมติว่าคุณกำลังสร้างศัตรูที่กำหนดเองสำหรับSuper Mario …

5
มันสมเหตุสมผลหรือไม่ที่จะ "โปรแกรมไปยังส่วนต่อประสาน" ใน Java?
ฉันได้เห็นการอภิปรายในคำถามนี้เกี่ยวกับวิธีการที่คลาสที่ใช้จากอินเทอร์เฟซจะถูกยกตัวอย่าง ในกรณีของฉันฉันกำลังเขียนโปรแกรมขนาดเล็กมากใน Java ที่ใช้อินสแตนซ์ของTreeMapและตามความเห็นของทุกคนที่นั่นควรมีอินสแตนซ์เช่น: Map<X> map = new TreeMap<X>(); ในโปรแกรมของฉันฉันกำลังเรียกใช้ฟังก์ชั่นmap.pollFirstEntry()ซึ่งไม่ได้ประกาศในMapอินเทอร์เฟซ (และอีกสองสามคนที่อยู่ในMapอินเทอร์เฟซด้วย) ฉันจัดการเพื่อทำสิ่งนี้ได้โดยการส่งไปยังTreeMap<X>ทุกที่ที่ฉันเรียกวิธีนี้เช่น someEntry = ((TreeMap<X>) map).pollFirstEntry(); ฉันเข้าใจถึงข้อดีของแนวทางการเริ่มต้นตามที่อธิบายไว้ข้างต้นสำหรับโปรแกรมขนาดใหญ่อย่างไรก็ตามสำหรับโปรแกรมขนาดเล็กมากที่วัตถุนี้จะไม่ถูกส่งผ่านไปยังวิธีอื่นฉันคิดว่ามันไม่จำเป็น แต่ถึงกระนั้นฉันกำลังเขียนโค้ดตัวอย่างนี้เป็นส่วนหนึ่งของการสมัครงานและฉันไม่ต้องการให้รหัสของฉันดูไม่ดีหรือรก สิ่งที่จะเป็นทางออกที่หรูหราที่สุด? แก้ไข: TreeMapผมอยากจะชี้ให้เห็นว่าฉันสนใจมากขึ้นในการเข้ารหัสการปฏิบัติที่ดีในวงกว้างแทนของการประยุกต์ใช้ฟังก์ชั่นที่เฉพาะเจาะจง เนื่องจากคำตอบบางข้อได้ชี้ให้เห็นแล้ว (และฉันได้ทำเครื่องหมายเป็นคำตอบแรกให้ทำ) ควรใช้ระดับนามธรรมที่สูงขึ้นโดยไม่สูญเสียฟังก์ชันการทำงาน

4
รูปแบบของผู้เข้าชมใช้ได้ในสถานการณ์นี้หรือไม่
เป้าหมายของงานของฉันคือการออกแบบระบบขนาดเล็กที่สามารถเรียกใช้งานที่เกิดขึ้นซ้ำตามกำหนดเวลา งานที่เกิดซ้ำเป็นเหมือน "ส่งอีเมลไปยังผู้ดูแลระบบทุกชั่วโมงตั้งแต่ 8:00 น. ถึง 17:00 น. วันจันทร์ถึงวันศุกร์" ฉันได้เรียนฐานที่เรียกว่าRecurringTask public abstract class RecurringTask{ // I've already figured out this part public bool isOccuring(DateTime dateTime){ // implementation } // run the task public abstract void Run(){ } } และฉันมีหลายชั้นเรียนซึ่งได้รับมาจากRecurringTask หนึ่งในนั้นคือเรียกว่าSendEmailTask public class SendEmailTask : RecurringTask{ private Email email; public SendEmailTask(Email …

5
ชั้นเรียนในภาษา OOP และประเภท
ในทฤษฎีการเขียนโปรแกรมภาษาประเภทคือชุดของค่า เช่น type "int" คือชุดของค่าจำนวนเต็มทั้งหมด ในภาษา OOP คลาสเป็นประเภทใช่หรือไม่ เมื่อชั้นเรียนมีสมาชิกมากกว่าหนึ่งคนเช่น class myclass{ int a; double b; } เมื่อเราพูดถึงชั้นเรียนเราหมายถึง " (a,b)อยู่ที่ไหนaint และbเป็นสองเท่า" หรือ "{ (x,y)| xis int ใด ๆ , ydouble ใด ๆ }"? ตัวอย่างmyclassหมายถึงอะไร " (a,b)อยู่ที่ไหนaint และbเป็นสองเท่า" หรือ วัตถุที่ใช้พื้นที่หน่วยความจำและที่ (ไม่จำเป็นต้องเช่นว่างเปล่า) ร้านค้า(x,y)ที่xใด int และyเป็นคู่ใด ๆ

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

4
เมื่อไรที่เมธอดของคลาสส่งคืนอินสแตนซ์เดียวกันหลังจากแก้ไขตัวเอง?
ฉันได้เรียนที่มีสามวิธีA(), และB() C()วิธีการเหล่านั้นแก้ไขอินสแตนซ์ของตัวเอง ในขณะที่วิธีการจะต้องส่งคืนอินสแตนซ์เมื่ออินสแตนซ์เป็นสำเนาแยกต่างหาก (เช่นเดียวกับClone()) ฉันมีตัวเลือกฟรีที่จะส่งคืนvoidหรืออินสแตนซ์เดียวกัน ( return this;) เมื่อทำการแก้ไขอินสแตนซ์เดียวกันในวิธีการและไม่คืนค่าอื่น ๆ obj.A().B().C();เมื่อตัดสินใจกลับมาเช่นการแก้ไขเดียวกันผมสามารถทำโซ่วิธีการเรียบร้อยเช่น นี่จะเป็นเหตุผลเดียวที่ทำเช่นนั้น? มันยังโอเคที่จะปรับเปลี่ยนอินสแตนซ์ของตัวเองและส่งคืนด้วยหรือไม่ หรือควรส่งคืนสำเนาและปล่อยให้วัตถุต้นฉบับเหมือนเดิมหรือไม่ เพราะเมื่อส่งคืนอินสแตนซ์ที่ถูกแก้ไขเดียวกันผู้ใช้อาจจะคิดว่าค่าที่ส่งคืนเป็นสำเนามิฉะนั้นจะไม่ถูกส่งคืน? หากไม่เป็นไรวิธีที่ดีที่สุดในการชี้แจงเรื่องดังกล่าวกับวิธีการคืออะไร

6
จำนวนครั้งที่สำคัญฉันไม่สามารถคิดเหตุผลที่มีวัตถุแทนคลาสแบบสแตติก วัตถุมีประโยชน์มากกว่าที่ฉันคิดหรือไม่ [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเข้าใจแนวคิดของวัตถุและในฐานะที่เป็นโปรแกรมเมอร์ Java ฉันรู้สึกว่ากระบวนทัศน์ OO นั้นค่อนข้างเป็นธรรมชาติสำหรับฉันในทางปฏิบัติ อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันพบว่าตัวเองกำลังคิด: รอสักครู่สิ่งที่เป็นประโยชน์จริงของการใช้วัตถุมากกว่าการใช้คลาสคงที่ (มีการห่อหุ้มที่เหมาะสมและการปฏิบัติ OO)? ฉันนึกถึงประโยชน์สองประการของการใช้วัตถุ (ทั้งสองอย่างมีความสำคัญและมีประสิทธิภาพ): ความแตกต่าง: ช่วยให้คุณสามารถสลับการทำงานแบบไดนามิกและยืดหยุ่นในช่วงรันไทม์ ยังอนุญาตให้เพิ่ม 'ส่วน' การทำงานใหม่และทางเลือกให้กับระบบได้อย่างง่ายดาย ตัวอย่างเช่นหากมีCarคลาสที่ออกแบบมาเพื่อทำงานกับEngineวัตถุและคุณต้องการเพิ่ม Engine ใหม่ให้กับระบบที่รถยนต์สามารถใช้ได้คุณสามารถสร้างEngineคลาสย่อยใหม่ และเพียงส่งวัตถุของคลาสนี้ไปยัง Carวัตถุโดยไม่ต้อง Carเปลี่ยนอะไรเกี่ยวกับ และคุณสามารถตัดสินใจได้ในระหว่างรันไทม์ ความสามารถในการ 'ผ่านฟังก์ชันการทำงานรอบ ๆ ': คุณสามารถส่งผ่านวัตถุรอบ ๆ ระบบแบบไดนามิก แต่มีข้อได้เปรียบเพิ่มเติมใด ๆ กับวัตถุที่อยู่เหนือคลาสแบบคงที่ บ่อยครั้งที่ฉันเพิ่ม 'ส่วน' ใหม่ลงในระบบฉันทำได้โดยการสร้างคลาสใหม่และสร้างอินสแตนซ์ของวัตถุจากมัน แต่เมื่อเร็ว ๆ นี้เมื่อฉันหยุดและคิดเกี่ยวกับมันฉันรู้ว่าชั้นคงที่จะทำเช่นเดียวกับวัตถุในสถานที่จำนวนมากที่ฉันมักจะใช้วัตถุ ตัวอย่างเช่นฉันกำลังทำงานเพื่อเพิ่มกลไกการบันทึก / …

9
มี OOP การเรียนรู้ที่แตกต่างกันในภาษาการเขียนโปรแกรมที่แตกต่างกันหรือไม่? [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันต้องการเรียนรู้ OOP ฉันรู้จัก Python และฉันรู้เรื่องเล็ก ๆ น้อย ๆ เกี่ยวกับ OOP แต่เมื่อฉันค้นหา "เรียนรู้ OOP" ในฟอรัมฉันเห็นชายคนหนึ่งพูดว่า "Python ใหม่มากนั่นคือสาเหตุที่คุณไม่สามารถเรียนรู้ OOP บน Python ได้คุณควรเรียนรู้ Java แล้วเข้าใจ OOP บน Java" จริงป้ะ? มีความเข้าใจที่แตกต่างกัน OOP ในภาษาการเขียนโปรแกรมที่แตกต่างกันหรือไม่? ชอบเรียนรู้เกี่ยวกับ Java, C #, C ++, Perl หรือ Python หรือไม่

4
.NET Programming และคลาส POCO
ฉันมีความคิดในคืนนี้ขณะที่ไตร่ตรองเกี่ยวกับแอปพลิเคชันบางอย่างที่ฉันต้องเปลี่ยนและทำให้ฉันคิดได้ เอนทิตีกรอบเอนทิตีเป็น POCO (ธรรมดา CLR วัตถุเก่า) และรูปแบบที่ใช้ใน ASP.NET MVC ก็มักจะ POCO นี่หมายถึงคุณสมบัติโดยทั่วไปไม่มีวิธีการ ตอนนี้การเขียนโปรแกรม OO ตามปกติจะอนุญาตให้วัตถุห่อหุ้มการทำงานของมันซึ่งรวมถึงคุณสมบัติของมันเช่นเดียวกับวิธีการของมันซึ่งจะช่วยให้เกิดความหลากหลาย ด้วยการเพิ่มขึ้นของคลาส POCO ที่ใช้รูปแบบการออกแบบเช่นที่เก็บทั่วไปกลายเป็นที่นิยมมากขึ้น เมื่อก่อนวัตถุของฉันจะมีการดำเนินการ CRUD ของตัวเองตอนนี้ฉันมีพวกเขาในพื้นที่เก็บข้อมูล นี่เป็นเพียงวิวัฒนาการใน OO ที่การดำเนินการ CRUD ถูกลบออกจากวัตถุเพื่อให้สามารถแยกหรือการดำเนินการ CRUD อาจไม่ได้อยู่ในระดับวัตถุในอดีตและฉันผิด ห่าบางทีทั้งสองอย่างถูกต้องตามกฎหมายและได้รับเสมอ มันเป็นเพียงข้อสังเกตที่ทำให้ฉันคิดดังนั้นฉันจึงคิดว่าจะหาความคิดเห็นอื่น

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