การเขียนโปรแกรมเชิงวัตถุ (การแปลบทความ)

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

• เป็นสีแดง (ซึ่งไม่เปลี่ยนแปลงเมื่อเวลาผ่านไป)
• ตอนนี้มีความยาว 10 เซนติเมตร (ซึ่งอาจเปลี่ยนแปลงได้หากเหลาดินสอ)

และมีพฤติกรรมดังต่อไปนี้:

• มันจะทิ้งรอยไว้หากใช้อย่างถูกต้อง
• ร่องรอยอาจแตกต่างกันไปขึ้นอยู่กับแรงกดดัน (ขึ้นอยู่กับปัจจัยภายนอก)
• ความยาวจะสั้นลงหากลับให้คม (พฤติกรรมถาวร)

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

นามธรรม

นามธรรมถูกกำหนดให้เป็นคุณภาพของปฏิสัมพันธ์กับความคิดมากกว่าเหตุการณ์หรือกล่าวอีกนัยหนึ่งคืออิสรภาพจากคุณสมบัติการเป็นตัวแทน ซึ่งช่วยให้โปรแกรมเมอร์สามารถมุ่งความสนใจไปที่ว่าจะเขียนโปรแกรมอะไรมากกว่าจะ เขียนโปรแกรม อย่างไร สิ่งที่เป็นนามธรรมถือได้ว่าเป็นสัญญาที่เราจัดให้มีฟังก์ชันการทำงาน รายละเอียดการใช้งานอาจถูกซ่อนไว้เมื่อใช้แนวคิดนี้ ตัวอย่างเช่นหากเราต้องการคลาสที่เขียนเราต้องแน่ใจว่าคลาสนั้นมีเมธอด "write" abstract class writer { write (); } เราทำอะไรไปบ้าง? เราได้ออกแบบคลาสระดับสูงที่เป็นนามธรรม กล่าวอีกนัยหนึ่งก็คือ มันรู้ว่าเราต้องการฟังก์ชันอะไร แต่วิธีการนำไปใช้นั้นอยู่นอกขอบเขตของคลาสนี้ สิ่งนี้มีประโยชน์มากมาย:

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

มรดก

"มรดก" ในภาษาอังกฤษทั่วไปหมายถึง "ได้รับและส่งต่อ" คำนี้มีอยู่ในวัฒนธรรมของเรามาเป็นเวลานาน บรรพบุรุษได้มาซึ่งที่ดินผ่านการทำงานหนักและส่งต่อให้ลูกหลาน แม้แต่ธรรมชาติก็ยังสนับสนุนมรดกอีกด้วย คุณสมบัติของร่างกายทั้งหมด เช่น ส่วนสูง สีผิว/ตา/สีผม เป็นต้น ขึ้นอยู่กับยีนที่เราสืบทอดมาจากพ่อแม่ของเรา การสืบทอดช่วยป้องกันการสร้างวงล้อใหม่และเร่งความก้าวหน้า มันก็เหมือนกันใน OOP เราสร้างคลาสพาเรนต์ที่มีคุณสมบัติ/พฤติกรรมพื้นฐานบางประการ คลาสทั้งหมดที่สืบทอดมาจากพาเรนต์นี้จะมีคุณสมบัติ/พฤติกรรมเหมือนกับคลาสพาเรนต์ อย่างไรก็ตาม คลาสที่สืบทอดมาอาจได้รับคุณสมบัติ/พฤติกรรมเพิ่มขึ้น หรือเปลี่ยนแปลงการนำพฤติกรรมไปใช้ class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } ในตัวอย่างข้างต้น คลาสพาเรนต์ (WritingInstrument) มีคุณสมบัติ "สี" และลักษณะการทำงาน "เขียน" เมื่อมีการประกาศคลาสลูกหลาน (หมายเลขอ้างอิง) คุณสมบัติ "สี" และลักษณะการทำงาน "เขียน" ไม่จำเป็นต้องประกาศอีกครั้ง มีอยู่ในคลาส "handle" เนื่องจากการสืบทอด อย่างไรก็ตาม คลาสลูกหลานสามารถประกาศคุณสมบัติ/พฤติกรรมเพิ่มเติมของตนเองได้ เราจะใช้สิ่งนี้ในทางปฏิบัติได้อย่างไร? นักพัฒนาเราขี้เกียจมาก เราไม่อยากพิมพ์อะไรซ้ำแล้วซ้ำเล่า การมีอยู่ของรหัสเดียวกันหลายชุดไม่สนับสนุนเนื่องจากการพิจารณาดังต่อไปนี้:

• ยิ่งสำเนาโค้ดน้อยเท่าไร การดูแลรักษาก็จะยิ่งง่ายขึ้นเท่านั้น
• หากมีสำเนาโค้ดไม่มาก การเปลี่ยนแปลงในที่เดียวจะปรากฏทุกที่
• รหัสน้อยลงข้อผิดพลาดก็จะน้อยลง
• หากใช้รหัสเดียวในหลาย ๆ ที่ การวางนัยทั่วไปก็จะสำเร็จได้
• เราเน้นการเขียนโค้ด
• เราเน้นการทดสอบ

การสืบทอดใน Java ทำได้โดยใช้คำหลัก "extends" และ "implements" class WritingInstrument { } class Pen extends WritingInstrument { }

ความแตกต่าง

คำว่า "polymorphism" มาจากคำสองคำ: "Poly"คือ “หลาย” / “มากกว่าหนึ่ง” “morph”เช่น “รูปแบบ” ตามตัวอักษร คำว่า “ความหลากหลาย” หมายถึงความสามารถของวัตถุที่จะประพฤติในลักษณะที่แตกต่างกันขึ้นอยู่กับเงื่อนไข ในการเขียนโปรแกรม polymorphism สามารถนำไปใช้ได้หลายแห่ง:

• ชั้นเรียน
• วิธีการ
• ผู้ประกอบการ

สิ่งที่กล่าวมาทั้งหมดอาจมีการทำงานที่แตกต่างกันไปขึ้นอยู่กับเงื่อนไข หรือบริบทที่ใช้งาน สิ่งนี้มีประโยชน์เนื่องจากไคลเอนต์ (โปรแกรมเมอร์ที่ใช้ไลบรารีของคุณ) ไม่จำเป็นต้องรู้รายละเอียดปลีกย่อยมากมาย และฟังก์ชันที่ต้องการนั้นถูกนำไปใช้โดยการเลือกข้อมูลที่จำเป็นจากบริบท Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } ตัวอย่างด้านบนมีการใช้งานเริ่มต้นใน WritingObject ซึ่งได้รับการขยาย/แทนที่โดยปากกาและปากกาคลาสที่สืบทอด เมธอด write() ถูกเรียกสามครั้งในคลาส Main แต่ละครั้งที่มีการเรียกใช้การใช้งานที่แตกต่างกัน ขึ้นอยู่กับออบเจ็กต์ที่เรียกใช้เมธอด ในกรณีนี้ เมธอด write() มีพฤติกรรมหลายประเภทเนื่องจากเป็นแบบโพลีมอร์ฟิก

การห่อหุ้ม

การห่อหุ้มหมายถึงการรวบรวมข้อมูล/ฟังก์ชันการทำงานที่เกี่ยวข้องในหน่วยเดียว ซึ่งช่วยในการอำนวยความสะดวกในการเข้าถึง/แก้ไขข้อมูล ตัวอย่างเช่น หากเราต้องการพิมพ์คุณสมบัติทั้งหมดที่ผู้ใช้กำหนด เรามีทางเลือกดังต่อไปนี้: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) เราสร้างวิธีการที่นำคุณสมบัติทั้งหมดมาพิมพ์ทีละรายการ เมื่อจำนวนองค์ประกอบในรายการเพิ่มขึ้น จะไม่สามารถระบุฟิลด์ที่ถูกต้องได้อีกต่อไป และการเพิ่ม/ลบฟิลด์หนึ่งฟิลด์จะเปลี่ยนลายเซ็นวิธีการ ดังนั้นเราจึงจำเป็นต้องแทนที่ผู้ใช้ทั้งหมดของวิธีนี้ แม้ว่าพวกเขาจะไม่ต้องการฟิลด์ที่เพิ่มล่าสุดก็ตาม เพื่อให้โค้ดอ่านง่ายขึ้นและทำให้การแก้ไขในอนาคตง่ายขึ้น เราได้สรุปคุณสมบัติในคลาสและเปลี่ยนให้เป็นวัตถุแบบรวม อ็อบเจ็กต์ class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} คือชุดซอฟต์แวร์ของตัวแปรและวิธีการที่เกี่ยวข้อง คุณสามารถแสดงวัตถุในโลกแห่งความเป็นจริงได้โดยใช้วัตถุของโปรแกรม คุณสามารถจินตนาการถึงสุนัขตัวจริงในโปรแกรมแอนิเมชั่น หรือจักรยานจริงเป็นวัตถุซอฟต์แวร์ภายในจักรยานออกกำลังกาย ใน OOP คลาสคือเทมเพลตที่ขยายได้ (เทมเพลตโค้ดโปรแกรม) สำหรับการสร้างออบเจ็กต์ โดยจัดให้มีสถานะเริ่มต้น (ตัวแปร) และพฤติกรรมการใช้งาน (ฟังก์ชัน วิธีการ) ตัวย่อ SOLID ได้รับการประกาศเกียรติคุณโดย Michael Feather สำหรับ "หลักการห้าประการแรก" ซึ่งตั้งชื่อโดย Robert C. Martin ในช่วงต้นทศวรรษ 2000 เป้าหมายของหลักการเมื่อนำไปใช้ร่วมกันคือเพื่อเพิ่มโอกาสที่โปรแกรมเมอร์จะสร้างระบบที่ง่ายต่อการบำรุงรักษาและขยาย หลักการ SOLIDเป็นแนวทางในการพัฒนาโปรแกรมที่จำเป็นในการลบโค้ดที่ "เน่าเสีย" ออกด้วยการปรับโครงสร้างใหม่ ซึ่งส่งผลให้โค้ดสามารถอ่านและขยายได้ง่าย นี่เป็นส่วนหนึ่งของกลยุทธ์การเขียนโปรแกรมแบบคล่องตัวและปรับเปลี่ยนได้

หลักการความรับผิดชอบเดียว

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

หลักการเปิด/ปิด

ใน OOP หลักการเปิด/ปิดระบุว่า “เอนทิตีซอฟต์แวร์ (คลาส โมดูล วิธีการ ฯลฯ) ควรเปิดให้ขยาย แต่ปิดเพื่อเปลี่ยนแปลง” กล่าวอีกนัยหนึ่ง เอนทิตีต้องอนุญาตให้ขยายลักษณะการทำงานโดยไม่ต้องเปลี่ยนซอร์สโค้ด

หลักการทดแทนลิสคอฟ

การทดแทนเป็นหลักการใน OOP โดยระบุว่าถ้า S ในโปรแกรมคอมพิวเตอร์เป็นชนิดย่อยของ T ดังนั้นวัตถุประเภท T จะต้องสามารถถูกแทนที่ด้วยวัตถุประเภท S ได้ (เช่น วัตถุประเภท S สามารถถูกแทนที่ด้วยวัตถุประเภท T) โดยไม่เปลี่ยนแปลง โปรแกรมคุณสมบัติที่จำเป็น (ความแม่นยำ ความสมบูรณ์ของงาน ฯลฯ)

หลักการแยกส่วนต่อประสาน

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

หลักการผกผันการพึ่งพา

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

• โมดูลระดับสูงไม่ควรขึ้นอยู่กับโมดูลระดับต่ำ โมดูลทั้งสองประเภทต้องขึ้นอยู่กับนามธรรม
• นามธรรมไม่ควรขึ้นอยู่กับรายละเอียดการใช้งาน รายละเอียดจะต้องขึ้นอยู่กับนามธรรม

หลักการนี้จะพลิกกลับวิธีที่ผู้คนสามารถคิดเกี่ยวกับการออกแบบเชิงวัตถุ โดยการโต้แย้งว่าวัตถุระดับสูงและต่ำควรขึ้นอยู่กับนามธรรมเดียวกัน

หลักการของ GRASP

รูปแบบซอฟต์แวร์มอบหมายความรับผิดชอบทั่วไป (GRASP) ให้แนวทางในการกำหนดความรับผิดชอบให้กับคลาสและอ็อบเจ็กต์ในการออกแบบเชิงวัตถุ

คอนโทรลเลอร์

รูปแบบตัวควบคุมกำหนดความรับผิดชอบในการโต้ตอบกับเหตุการณ์ของระบบให้กับคลาสที่ไม่ใช่ GUI ซึ่งเป็นตัวแทนของสถานการณ์ทั้งระบบหรือกรณีการใช้งาน ตัวควบคุม:

• นี่คือออบเจ็กต์ที่ไม่ได้โต้ตอบกับผู้ใช้โดยตรง และมีหน้าที่รับผิดชอบในการรับและตอบสนองต่อเหตุการณ์ของระบบ
• ต้องใช้เพื่อจัดการกับเหตุการณ์ระบบทั้งหมดของกรณีการใช้งานหนึ่ง (หรือหลายกรณีที่เกี่ยวข้องกัน)
• เป็นวัตถุแรกที่อยู่เบื้องหลัง GUI ที่ควบคุมการทำงานของระบบ
• เขาไม่จำเป็นต้องทำงานเอง งานของเขาคือควบคุมการไหลของเหตุการณ์

ผู้สร้าง

งานของคลาส Creator คือการสร้างและเริ่มต้นวัตถุเพื่อใช้ในภายหลัง โดยจะรู้พารามิเตอร์การเริ่มต้น รวมถึงออบเจ็กต์ที่จะถูกสร้างขึ้น บางครั้งคลาสผู้สร้างจะสร้างวัตถุและวางไว้ในแคช และจัดให้มีอินสแตนซ์หนึ่งรายการเมื่อจำเป็น

การทำงานร่วมกันสูง

การทำงานร่วมกันสูงเป็นรูปแบบการประเมิน โดยมีจุดประสงค์เพื่อรักษาวัตถุให้อยู่ในสภาพที่มุ่งเป้าไปที่การปฏิบัติงานที่ชัดเจนเพียงงานเดียว ควบคุมและเข้าใจได้ง่าย High Coupling มักใช้เพื่อรองรับ Low Coupling ความสอดคล้องกันสูงหมายความว่าความรับผิดชอบขององค์ประกอบที่กำหนดได้รับการกำหนดไว้อย่างชัดเจน (เกี่ยวข้องกันอย่างมากและมุ่งเน้นอย่างมาก) การแบ่งโปรแกรมออกเป็นคลาสและระบบย่อยเป็นตัวอย่างของการดำเนินการที่เพิ่มการทำงานร่วมกันของคุณสมบัติของระบบ ในทางกลับกัน การคัปปลิ้งแบบหลวมคือสถานการณ์ที่องค์ประกอบมีงานที่ไม่เกี่ยวข้องมากเกินไป องค์ประกอบที่อยู่คู่กันอย่างหลวมๆ มักจะเข้าใจยาก นำกลับมาใช้ใหม่ ดูแลรักษายาก และเปลี่ยนแปลงได้ยาก

ทางอ้อม

รูปแบบวงเวียนรักษาการเชื่อมต่อแบบหลวมๆ (และการนำกลับมาใช้ใหม่ได้) ระหว่างสององค์ประกอบโดยมอบหมายความรับผิดชอบสำหรับการโต้ตอบระหว่างองค์ประกอบเหล่านั้นกับวัตถุที่อยู่ตรงกลาง ตัวอย่างคือการแนะนำตัวควบคุมเพื่อเป็นสื่อกลางระหว่างข้อมูล (โมเดล) และการแสดงผล (มุมมอง) ในรูปแบบ Model-View-Controller (MVC)

ผู้เชี่ยวชาญด้านข้อมูล

ผู้เชี่ยวชาญด้านข้อมูล (รวมถึงหลักการของผู้เชี่ยวชาญหรือผู้เชี่ยวชาญ) เป็นหลักการที่ใช้ในการกำหนดว่าใครจะมอบหมายความรับผิดชอบให้ ความรับผิดชอบรวมถึงวิธีการ เขตข้อมูลจากการคำนวณ ฯลฯ เมื่อใช้หลักการนี้เมื่อมอบหมายความรับผิดชอบ แนวทางหลักคือลำดับการดำเนินการต่อไปนี้: การวิเคราะห์ความรับผิดชอบ การระบุข้อมูลที่จำเป็นในการตอบสนอง และสุดท้ายคือการกำหนดตำแหน่งของข้อมูลนี้ การใช้หลักการผู้เชี่ยวชาญด้านข้อมูลส่งผลให้มีการมอบหมายความรับผิดชอบให้กับชั้นเรียนที่มีข้อมูลมากที่สุดในการดำเนินการ

คลัปต่ำ

การมีเพศสัมพันธ์แบบหลวมเป็นรูปแบบการประเมินที่ระบุวิธีการกำหนดความรับผิดชอบ: การมีเพศสัมพันธ์แบบหลวมระหว่างคลาสต่างๆ การเปลี่ยนประเภทหนึ่งควรมีผลกระทบน้อยที่สุดต่ออีกประเภทหนึ่ง และเพิ่มความสามารถในการนำกลับมาใช้ใหม่ได้สูงสุด

ความแตกต่าง

ตามความหลากหลาย ความแปรผันของพฤติกรรมตามประเภทถูกกำหนดให้กับประเภทที่การเปลี่ยนแปลงนี้เกิดขึ้น ซึ่งสามารถทำได้โดยการใช้การดำเนินการแบบโพลีมอร์ฟิก

รูปแบบที่ได้รับการคุ้มครอง

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

การผลิตที่บริสุทธิ์

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

การวิพากษ์วิจารณ์

การวิจัยโดย Potok และคณะ ไม่พบความแตกต่างที่มีนัยสำคัญระหว่าง OOP และแนวทางขั้นตอน

การเปรียบเทียบ OOP อย่างมีวิจารณญาณกับเทคโนโลยีอื่นๆ โดยเฉพาะเทคโนโลยีเชิงสัมพันธ์ เป็นเรื่องยากเนื่องจากขาดคำจำกัดความของ OOP ที่เข้มงวดและเป็นที่ยอมรับอย่างกว้างขวาง (Christopher J. Date)

เมื่อเปรียบเทียบกับภาษาอื่น (ภาษาถิ่น LISP ภาษาที่ใช้งานได้ ฯลฯ ) ภาษา OOP ไม่มีข้อได้เปรียบเฉพาะตัวและสร้างความซับซ้อนที่ไม่จำเป็น (ลอว์เรนซ์ ครับเนอร์)

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

ความนิยมของ OOP ในกลุ่มบริษัทขนาดใหญ่นั้นเกิดจาก "กลุ่มโปรแกรมเมอร์ธรรมดาๆ ขนาดใหญ่ (และเปลี่ยนแปลงบ่อย)" วินัยที่กำหนดโดย OOP ป้องกันไม่ให้โปรแกรมเมอร์ทำ "อันตรายมากเกินไป" (พอล เกรแฮม)

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

Rick Hickey ผู้สร้าง Clojure อธิบายว่าระบบวัตถุเป็นแบบจำลองที่เรียบง่ายอย่างยิ่งในโลกแห่งความเป็นจริง เขาเน้นย้ำว่า OOP ไม่สามารถจำลองเวลาได้อย่างถูกต้อง ซึ่งสร้างปัญหาใหญ่เมื่อมัลติเธรดกลายเป็นเรื่องปกติในโปรแกรม Eric S. Raymond โปรแกรมเมอร์ Unix และผู้สนับสนุนซอฟต์แวร์โอเพ่นซอร์ส วิจารณ์คำกล่าวอ้างที่ว่า OOP คือ "The One Solution" และเขียนว่า OOP สนับสนุนโปรแกรมแบบหลายชั้น ซึ่งเป็นอุปสรรคต่อความโปร่งใส ในทางตรงกันข้าม Raymond ได้ยกตัวอย่าง Unix และ C.

ลิงค์

โดย Margaret Rouse @ WhatIs.com วิกิพีเดีย! ( เวอร์ชันรัสเซีย ) การสืบทอดคือความหลากหลาย SOLID (การออกแบบเชิงวัตถุ) ( เวอร์ชันรัสเซีย ) หลักการความรับผิดชอบเดี่ยว ข้อโต้แย้งต่อ OOPS ( เวอร์ชันรัสเซีย ) OOPS คืออะไร (โดยไม่มีการโฆษณาเกินจริง) การแปล: Varygin D.V.