ใครก็ตามที่มีประสบการณ์ในการเขียนโปรแกรมซอฟต์แวร์จะตัดสินโค้ดซอฟต์แวร์ที่เขียนโดยผู้อื่นโดยใช้พารามิเตอร์การตัดสินตามเส้นทางอาชีพของตน
ตลอดอาชีพการงานของฉันฉันรู้จักนักพัฒนามากมายและฉันได้เห็นโค้ดหลายพันบรรทัดและเมื่อฉันต้องการประเมินทักษะของนักพัฒนาฉันจะพิจารณาปัจจัยสองประการเป็นหลัก:
โชคดีที่มีพื้นฐานหรือหลักการบางอย่างที่ช่วยให้เขียนโค้ดได้ง่ายขึ้น
ตัวย่อ 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 จะเป็นเรื่องเล็กน้อยและตรรกะทางธุรกิจของเราที่สร้างขึ้นจากการทำงานของหนังสือจะไม่เปลี่ยนแปลง
ดำเนินการต่อโดยอ่านหลักการที่สองเปิด / ปิด ->
Ercole Palmeri
การพัฒนาทักษะยนต์ปรับผ่านการระบายสีจะช่วยเตรียมเด็กๆ ให้พร้อมสำหรับทักษะที่ซับซ้อนมากขึ้น เช่น การเขียน หากต้องการสี...
ภาคกองทัพเรือเป็นมหาอำนาจทางเศรษฐกิจระดับโลกอย่างแท้จริง ซึ่งได้มุ่งหน้าสู่ตลาดมูลค่า 150 พันล้าน...
เมื่อวันจันทร์ที่แล้ว Financial Times ได้ประกาศข้อตกลงกับ OpenAI FT อนุญาติให้ทำข่าวระดับโลก...
ผู้คนนับล้านชำระค่าบริการสตรีมมิ่ง โดยจ่ายค่าธรรมเนียมการสมัครสมาชิกรายเดือน เป็นความเห็นทั่วไปที่คุณ...
