การสร้างโค้ดโมดูลาร์อย่างแท้จริงโดยไม่มีการขึ้นต่อกัน

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

กรอไปข้างหน้าสองสามเดือนและความเร็วในการพัฒนาของคุณลดลง เป็นเพราะคุณไม่ได้ทำงานหนักเหมือนเมื่อก่อนหรือเปล่า? ไม่เชิง. ก้าวไปข้างหน้าอีกสองสามเดือนอย่างรวดเร็ว และความเร็วในการพัฒนาของคุณลดลงอีก การทำงานในโครงการนี้ไม่สนุกอีกต่อไปและกลายเป็นสิ่งที่น่าเบื่อหน่าย

มันแย่ลง คุณเริ่มพบข้อบกพร่องหลายอย่างในแอปพลิเคชันของคุณ บ่อยครั้ง การแก้จุดบกพร่องหนึ่งจุดทำให้เกิดจุดใหม่สองจุด ณ จุดนี้คุณสามารถเริ่มร้องเพลง:

99 ข้อบกพร่องเล็ก ๆ น้อย ๆ ในรหัส 99 แมลงตัวน้อย ลงหนึ่งอัน ปะไว้รอบ ๆ

…127 บั๊กเล็กน้อยในโค้ด

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

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

เหตุผลที่การพัฒนาซอฟต์แวร์ช้าลงเมื่อเวลาผ่านไป

แล้วสาเหตุของปัญหานี้คืออะไร?

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

คุณมีมัน; สาเหตุที่แท้จริงของปัญหาของเราคือการเพิ่มความซับซ้อนที่มาจากการขึ้นต่อกันทั้งหมดที่โค้ดของเรามี

ก้อนโคลนก้อนโตและวิธีลดมัน

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

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

โซลูชันด้วยรหัสโมดูลาร์

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

อุตสาหกรรมอื่นกำลังแก้ปัญหานี้อย่างไร

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

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

เราสามารถทำซ้ำได้ในอุตสาหกรรมซอฟต์แวร์หรือไม่?

แน่นอนว่าเราทำได้! โดยใช้ส่วนต่อประสานและการผกผันของหลักการควบคุม ส่วนที่ดีที่สุดคือความจริงที่ว่าวิธีนี้สามารถใช้ได้ในภาษาเชิงวัตถุใดๆ: Java, C#, Swift, TypeScript, JavaScript, PHP—รายการจะดำเนินต่อไป คุณไม่จำเป็นต้องมีกรอบงานแฟนซีเพื่อใช้วิธีนี้ คุณเพียงแค่ต้องปฏิบัติตามกฎง่ายๆ ไม่กี่ข้อและอยู่ในระเบียบวินัย

การผกผันของการควบคุมคือเพื่อนของคุณ

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

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

ปัญหา

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

ทำไมการพึ่งพาการฉีดจึงผิดพลาด

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

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

โซลูชันสำหรับโค้ดโมดูลาร์

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

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

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

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

รูปแบบองค์ประกอบ

มากำหนดรูปแบบองค์ประกอบโครงสร้างกัน เพื่อที่เราจะสามารถสร้างมันขึ้นมาได้ในลักษณะที่ทำซ้ำได้

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

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

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

มาดูตัวอย่างง่ายๆ ของ “Hello World” ที่สร้างขึ้นใน Java

 public class Main { interface ElementListener { void printOutput(String message); } static class Element { private ElementListener listener; public Element(ElementListener listener) { this.listener = listener; } public void sayHello() { String message = "Hello World of Elements!"; this.listener.printOutput(message); } } static class App { public App() { } public void start() { // Build listener ElementListener elementListener = message -> System.out.println(message); // Assemble element Element element = new Element(elementListener); element.sayHello(); } } public static void main(String[] args) { App app = new App(); app.start(); } }

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

ตอนนี้ให้ดูที่คลาส App หลัก มันใช้ผู้ฟังและประกอบองค์ประกอบร่วมกับการดำเนินการที่เป็นรูปธรรม ตอนนี้เราสามารถเริ่มใช้งานได้แล้ว

คุณสามารถเรียกใช้ตัวอย่างนี้ใน JavaScript ได้ที่นี่

สถาปัตยกรรมองค์ประกอบ

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

โครงสร้างของเว็บแอปพลิเคชันฟูลสแตกที่ฉันชอบใช้มีลักษณะดังนี้:

 src ├── client │ ├── app │ └── elements │ └── server ├── app └── elements

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

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

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

ตัวอย่างการใช้งานจริง

เชื่อว่าการฝึกฝนนั้นเหนือกว่าทฤษฎีเสมอ มาดูตัวอย่างในชีวิตจริงที่สร้างขึ้นใน Node.js และ TypeScript

ตัวอย่างชีวิตจริง

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

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

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

พัฒนาเร็วขึ้น ใช้ซ้ำได้บ่อยขึ้น!

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

• ปัญหามากมายในซอฟต์แวร์เกิดขึ้นเนื่องจากการขึ้นต่อกันระหว่างหลายองค์ประกอบ

• การเปลี่ยนแปลงในที่เดียวจะทำให้คุณสามารถแนะนำพฤติกรรมที่คาดเดาไม่ได้ในที่อื่น

แนวทางสถาปัตยกรรมทั่วไปสามวิธีคือ:

• ลูกใหญ่ของโคลน เหมาะอย่างยิ่งสำหรับการพัฒนาอย่างรวดเร็ว แต่ไม่ค่อยดีนักสำหรับการผลิตที่มีเสถียรภาพ

• การฉีดพึ่งพา เป็นสารละลายกึ่งสำเร็จรูปที่คุณควรหลีกเลี่ยง

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

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

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

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

นอกจากนี้ หากคุณพบว่าตัวเองปรับโค้ดของคุณให้เหมาะสมก่อนเวลาอันควร โปรดอ่าน วิธีหลีกเลี่ยงคำสาปของการเพิ่มประสิทธิภาพก่อนกำหนด โดยเพื่อน Toptaler Kevin Bloch