SOLID หลักการ 5 ประการของการเขียนโปรแกรมเชิงวัตถุคืออะไร

รูปทรงเรขาคณิตทึบทึบ
การอบรม
1

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

ใครก็ตามที่มีประสบการณ์ในการเขียนโปรแกรมซอฟต์แวร์จะตัดสินโค้ดซอฟต์แวร์ที่เขียนโดยผู้อื่นโดยใช้พารามิเตอร์การตัดสินตามเส้นทางอาชีพของตน

ตลอดอาชีพการงานของฉันฉันรู้จักนักพัฒนามากมายและฉันได้เห็นโค้ดหลายพันบรรทัดและเมื่อฉันต้องการประเมินทักษะของนักพัฒนาฉันจะพิจารณาปัจจัยสองประการเป็นหลัก:

  • ความเรียบง่ายในการอ่านรหัส
  • โค้ดของพวกเขามีแนวโน้มที่จะทำงานและพัฒนาไปตามกาลเวลาเพียงใด

โชคดีที่มีพื้นฐานหรือหลักการบางอย่างที่ช่วยให้เขียนโค้ดได้ง่ายขึ้น

ตัวย่อ SOLID ย่อมาจาก:
S: หลักความรับผิดชอบเดียว
O: หลักการเปิด - ปิด
L: หลักการเปลี่ยนตัว Liskov
I: หลักการแยกส่วนต่อประสาน
D: หลักการผกผันของการพึ่งพา

เริ่มต้นด้วยการเจาะลึกหลักการ SOLID แรกคือ

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

คลาส (หรือโมดูล) ควรมีเพียงเหตุผลเดียวในการเปลี่ยนแปลงเพื่อพัฒนา

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

แต่ทำไม? 

เหตุใดการมีเหตุผลเดียวที่จะเปลี่ยนแปลงจึงสำคัญมาก

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

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

การระบุคุณลักษณะเดียวที่คลาสหรือโมดูลควรมีนั้นซับซ้อนกว่าการดูรายการตรวจสอบเพื่อเรียกใช้การทดสอบ 

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

ตัวอย่างบางส่วนของโมดูลและการใช้งาน:

  • โมดูลการบำรุงรักษา: ผู้ใช้ประกอบด้วยผู้ดูแลระบบฐานข้อมูลและสถาปนิกซอฟต์แวร์
  • โมดูลการรายงาน: ผู้ใช้ประกอบด้วยพนักงานออฟฟิศนักบัญชีและการผลิต
  • โมดูลการคำนวณการชำระเงินสำหรับระบบการจัดการเงินเดือน: ผู้ใช้สามารถรวมทนายความผู้จัดการและนักบัญชี
  • โมดูลการค้นหาข้อความสำหรับระบบการจัดการไลบรารี: ผู้ใช้สามารถเป็นตัวแทนของบรรณารักษ์หรือโดยผู้เยี่ยมชมและลูกค้าของห้องสมุดเอง

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

ดูเหมือนว่าจะมีเหตุผลมากกว่าที่จะระบุบทบาทมากกว่าผู้คนหรือผู้ใช้

ดังนั้น:

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

หลักการที่เป็นของแข็ง

มาดูตัวอย่างกัน

สมมติว่าเรามีชั้นหนังสือที่สรุปแนวคิดของหนังสือและฟังก์ชันการทำงาน

หนังสือเรียน {

    ฟังก์ชัน getTitle () {

        คืน "หนังสือเล่มใหญ่";

    }

    ฟังก์ชัน getAuthor () {

        กลับ“ Alessandro Baricco”;

    }

    function nextpage () {

        // หน้าต่อไป

    }

    ฟังก์ชัน printCurrent Page () {

        สะท้อน "เนื้อหาของหน้าปัจจุบัน";

    }

}

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

อย่างไรก็ตามมีปัญหาเล็กน้อย 

เมื่อนึกถึงนักแสดงที่เกี่ยวข้องกับการจัดการวัตถุหนังสือพวกเขาจะเป็นใคร? 

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

เราจึงมีนักแสดงสองคนที่มีปฏิสัมพันธ์กับชั้นเรียนที่แตกต่างกันมาก

สรุปคลาสนี้เป็นการผสมผสานระหว่าง:

  • ตรรกะทางธุรกิจด้วย 
  • การนำเสนอ 

สิ่งนี้อาจเป็นปัญหาได้เนื่องจากละเมิดหลักการรับผิดเดียว (SRP) 

เราจะเปลี่ยนแปลงได้อย่างไรเราจะปรับปรุงรหัสนี้ให้เคารพหลักความรับผิดชอบเดียวได้อย่างไร

ดูรหัสต่อไปนี้:

หนังสือเรียน {

    ฟังก์ชัน getTitle () {

        คืน "Oceano Mare";

    }

    ฟังก์ชัน getAuthor () {

        กลับ“ Alessandro Baricco”;

    }

    ฟังก์ชันเทิร์นเพจ () {

        // หน้าต่อไป

    }

    ฟังก์ชัน getCurrentPage () {

        สะท้อน "เนื้อหาของหน้าปัจจุบัน";

    }

}

เครื่องพิมพ์อินเทอร์เฟซ {

    ฟังก์ชัน printPage ($ page);

}

คลาส StampaLibro ใช้เครื่องพิมพ์ {

    ฟังก์ชัน printPages ($ page) {

        ก้อง $ หน้า;

    }

}

 

class HtmlPrinter ใช้เครื่องพิมพ์ {

    ฟังก์ชัน printPages ($ page) {

        ก้อง ' '. หน้า $ ' ';

    }

}

ตัวอย่างง่ายๆนี้แสดงให้เห็นถึงวิธีแยกการนำเสนอออกจากตรรกะทางธุรกิจและในการปฏิบัติตาม SRP จะมีข้อดีอย่างมากในความยืดหยุ่นของโครงการของเรา

ลองดูตัวอย่างอื่น:

ตัวอย่างที่คล้ายกับตัวอย่างข้างต้นคือเมื่อวัตถุสามารถบันทึกและดึงข้อมูลจากงานนำเสนอได้

หนังสือเรียน {

    ฟังก์ชัน getTitle () {

        คืน "Oceano Mare";

    }

    ฟังก์ชัน getAuthor () {

        กลับ“ Alessandro Baricco”;

    }

    ฟังก์ชันเทิร์นเพจ () {

        // หน้าต่อไป

    }

    ฟังก์ชัน getCurrentPage () {

        กลับ "เนื้อหาของหน้าปัจจุบัน";

    }

    function save () {

        $ filename = '/ เอกสาร /' $ this-> getTitolo () '-'. $ this-> getAuthor ();

        file_put_contents ($ filename, serialize ($ this));

    }

}

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

หนังสือเรียน {

    ฟังก์ชัน getTitle () {

        คืน "Oceano Mare";

    }

    ฟังก์ชัน getAuthor () {

        กลับ“ Alessandro Baricco”;

    }

    ฟังก์ชันเทิร์นเพจ () {

        // หน้าต่อไป

    }

    ฟังก์ชัน getCurrentPage () {

        กลับ "เนื้อหาของหน้าปัจจุบัน";

    }

}

คลาส SimpleFilePersistence {

    function save (จอง $ book) {

        $ filename = '/ เอกสาร /' $ book-> getTitle () '-'. $ book-> getAuthor ();

        file_put_contents ($ filename, serialize ($ book));

    }

}

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

ดำเนินการต่อโดยอ่านหลักการที่สองเปิด / ปิด ->

ฮิตความคิดเห็น

แสดงความคิดเห็น

ที่อยู่อีเมลของคุณจะไม่ถูกเผยแพร่ I campi obbligatori sono contrassegnati *

หลักการ liskov
การอบรม
หลักการของการแทนที่ Liskov หลักการ SOLID ที่สาม

คลาสย่อยไม่ควรส่งผลกระทบหรือเปลี่ยนนิยามประเภทของคลาสพาเรนต์ แนวคิดของหลักการนี้ได้รับการแนะนำโดย Barbara Liskov ในประเด็นสำคัญของการประชุมปี 1987 และได้รับการตีพิมพ์ในบทความร่วมกับ Jannette Wing ในปี 1994 คำจำกัดความดั้งเดิมของพวกเขา ...

แนวโน้มการตลาดของ Google
การอบรม
วิธีใช้ Google Trends สำหรับการตลาดแบบเรียลไทม์

ความยากลำบากที่สุดอย่างหนึ่งของ บริษัท ในปี 2020 คือการทำความเข้าใจว่าภาคส่วนผลิตภัณฑ์ใดที่จะกระจายธุรกิจของตน: อันที่จริงแล้วภาคอุตสาหกรรมส่วนใหญ่ได้รับผลกระทบอย่างหนักทำให้ บริษัท ต่างๆแทบจะไม่สามารถเจาะเข้าไปได้โดยเฉพาะในฐานะผู้เล่นรายใหม่ ภาคการผลิตน้อยมาก ...

กลยุทธ์ธุรกิจอัจฉริยะ
Metodi
กลยุทธ์สำหรับ Business Intelligence ที่ประสบความสำเร็จ

การสร้างกลยุทธ์ที่ประสบความสำเร็จสำหรับ Business Intelligence ของคุณเริ่มต้นด้วยวิสัยทัศน์ที่ถูกต้องของวัตถุประสงค์ เราเห็นประเด็นพื้นฐานบางประการด้านล่าง การประเมินสถานการณ์ปัจจุบันเป็นความผิดพลาดอย่างร้ายแรงที่จะประเมินด้านนี้ต่ำไป การประเมินสถานการณ์ปัจจุบันหมายถึงการวิเคราะห์กระบวนการโครงสร้าง ...