หลักการแยกอินเทอร์เฟซหลักการแยกอินเตอร์เฟส ISP สนับสนุนว่าการใช้อินเทอร์เฟซที่ทุ่มเทหลายรายการนั้นดีกว่าการใช้อินเทอร์เฟซทั้งหมดเดียว
การพึ่งพาของคลาสหนึ่งในคลาสอื่นควรได้รับการจัดตั้งขึ้นในอินเทอร์เฟซที่เล็กที่สุด
อินเทอร์เฟซแสดงถึงบทบาทและไม่ควรส่งบทบาทที่แตกต่างกันไปยังอินเทอร์เฟซ อินเทอร์เฟซที่ไม่เกี่ยวข้องจะถูกรวมเข้าด้วยกันเพื่อสร้างอินเทอร์เฟซขนาดใหญ่ที่ป่องซึ่งเป็นมลพิษต่อบทบาทและอินเทอร์เฟซ
"ลูกค้าไม่ควรถูกบังคับให้พึ่งพาวิธีการที่พวกเขาไม่ได้ใช้อินเตอร์เฟสเป็นของลูกค้าไม่ใช่ลำดับชั้นของชั้นเรียนที่พวกเขาอยู่" สิ่งนี้ชัดเจนมาก กล่าวง่ายๆว่าอย่าบังคับให้ลูกค้าใช้วิธีการที่ไม่ได้ใช้ หากผู้ใช้ถูกบังคับให้ใช้วิธีการที่ไม่ได้ใช้ลูกค้าเหล่านี้จะเผชิญกับการเปลี่ยนแปลงที่เกิดจากการเปลี่ยนแปลงในวิธีการเหล่านี้ที่พวกเขาไม่ได้ใช้
ในกรณีการใช้งานให้วิธีการที่ผู้โทรและบล็อกวิธีการที่ไม่จำเป็น มันเป็นไปตามหลักการของการแยกอินเทอร์เฟซ ตัวอย่างเช่นในระบบอีคอมเมิร์ซมีสามสถานที่ที่จะใช้ในหมวดหมู่คำสั่งซื้อ
ตามหลักการแยกอินเทอร์เฟซ (ISP) การพึ่งพาของคลาสหนึ่งในคลาสอื่นควรได้รับการจัดตั้งขึ้นในอินเทอร์เฟซที่เล็กที่สุด
กล่าวคือสำหรับพอร์ทัลมันสามารถพึ่งพาอินเทอร์เฟซด้วยวิธีการสืบค้นเท่านั้น
โครงสร้าง UML มีดังนี้:
ลองดูตัวอย่างของการเขียนอินเทอร์เฟซ Java ที่ไม่สนใจหลักการของการแยกอินเทอร์เฟซ:
อินเตอร์เฟส I {โมฆะสาธารณะวิธีการ 1 (); โมฆะสาธารณะวิธีการ 2 (); โมฆะสาธารณะวิธีการ 3 (); โมฆะสาธารณะวิธีการ 4 (); โมฆะสาธารณะวิธีการ 5 (); } คลาส A {โมฆะสาธารณะขึ้นอยู่กับ 1 (i i) {i.method1 (); } โมฆะสาธารณะขึ้นอยู่กับ 2 (i i) {i.method2 (); } โมฆะสาธารณะขึ้นอยู่กับ 3 (i i) {i.method3 (); }} คลาส B ใช้ i {โมฆะสาธารณะวิธีการ 1 () {system.out.println ("method1" เพื่อใช้อินเทอร์เฟซ i ");} โมฆะสาธารณะวิธีการ 2 () {system.out.println (" วิธีการ 2 ของคลาส B ใช้ interface i "); ไม่จำเป็นต้องใช้ Method4 และ Method5 แต่เนื่องจากมีวิธีการสองวิธีในอินเทอร์เฟซ A, // ในกระบวนการดำเนินการแม้ว่าวิธีการของสองวิธีนี้จะว่างเปล่าทั้งสองวิธีจะต้องดำเนินการ I.Method4 ();} โมฆะสาธารณะขึ้นอยู่กับ 3 (i) {i.method5 (); } // สำหรับคลาส D, method2 และ method3 ไม่จำเป็น แต่เนื่องจากมีสองวิธีในอินเทอร์เฟซ A, // ดังนั้นแม้ว่าวิธีการของวิธีการทั้งสองวิธีนี้จะว่างเปล่าในระหว่างกระบวนการดำเนินการ แต่วิธีการทั้งสองที่ไม่มีผล โมฆะสาธารณะวิธีการ 2 () {} โมฆะสาธารณะวิธีการ 3 () {} โมฆะโมฆะสาธารณะ method4 () {system.out.println ("วิธีที่ 4 ของคลาส D ใช้อินเทอร์เฟซ I"); } โมฆะสาธารณะวิธีการ 5 () {system.out.println ("วิธีการ 5 ของคลาส D ใช้อินเทอร์เฟซ I"); }} ไคลเอนต์คลาสสาธารณะ {โมฆะคงที่สาธารณะหลัก (สตริง [] args) {a = new a (); A.Depend1 (ใหม่ B ()); A.Depend2 (ใหม่ B ()); A.Depend3 (ใหม่ b ()); c c = ใหม่ c (); C.Depend1 (ใหม่ d ()); C.Depend2 (ใหม่ d ()); C.Depend3 (ใหม่ d ()); - จะเห็นได้ว่าหากอินเทอร์เฟซป่องเกินไปตราบใดที่วิธีการปรากฏในอินเทอร์เฟซไม่ว่าจะเป็นประโยชน์กับคลาสที่ขึ้นอยู่กับมันหรือไม่วิธีการเหล่านี้จะต้องนำไปใช้ในคลาสการใช้งาน เห็นได้ชัดว่านี่ไม่ใช่การออกแบบที่ดี หากการออกแบบนี้ได้รับการแก้ไขเพื่อให้สอดคล้องกับหลักการของการแยกอินเทอร์เฟซอินเทอร์เฟซที่ฉันต้องแยก ที่นี่เราแบ่งอินเทอร์เฟซดั้งเดิม I เป็นสามอินเทอร์เฟซ การออกแบบแบบแยกจะแสดงในรูปด้านล่าง:
ตามปกติโพสต์รหัสโปรแกรมสำหรับการอ้างอิงสำหรับเพื่อนที่ไม่คุ้นเคยกับแผนภาพคลาส:
อินเตอร์เฟส i1 {โมฆะสาธารณะวิธีการ 1 (); } อินเตอร์เฟส i2 {โมฆะสาธารณะวิธีการ 2 (); โมฆะสาธารณะวิธีการ 3 (); } อินเตอร์เฟส i3 {โมฆะสาธารณะวิธีการ 4 (); โมฆะสาธารณะวิธีการ 5 (); } คลาส A {โมฆะสาธารณะขึ้นอยู่กับ 1 (i1 i) {i.method1 (); } โมฆะสาธารณะขึ้นอยู่กับ 2 (i2 i) {i.method2 (); } โมฆะสาธารณะขึ้นอยู่กับ 3 (i2 i) {i.method3 (); }} คลาส B ใช้ i1, i2 {โมฆะสาธารณะวิธีการ 1 () {system.out.println ("วิธีที่ 1 ของคลาส B ใช้อินเทอร์เฟซ I1"); } โมฆะสาธารณะวิธีการ 2 () {system.out.println ("วิธีที่ 2 ของคลาส B ใช้อินเทอร์เฟซ I2"); } โมฆะสาธารณะวิธีการ 3 () {system.out.println ("วิธีที่ 3 ของคลาส B ใช้อินเทอร์เฟซ I2"); }} คลาส C {โมฆะสาธารณะขึ้นอยู่กับ 1 (i1 i) {i.method1 (); } โมฆะสาธารณะขึ้นอยู่กับ 2 (i3 i) {i.method4 (); } โมฆะสาธารณะขึ้นอยู่กับ 3 (i3 i) {i.method5 (); }} คลาส D ใช้ i1, i3 {โมฆะสาธารณะวิธีการ 1 () {system.out.println ("วิธีที่ 1 ของคลาส D ใช้อินเทอร์เฟซ I1"); } โมฆะสาธารณะวิธีการ 4 () {system.out.println ("วิธีการ 4 ของคลาส D ใช้อินเทอร์เฟซ I3"); } โมฆะสาธารณะวิธีการ 5 () {system.out.println ("วิธีการ 5 ของคลาส D ใช้อินเทอร์เฟซ I3"); - ความหมายของหลักการของการแยกอินเทอร์เฟซคือ: สร้างอินเทอร์เฟซเดียวอย่าสร้างอินเทอร์เฟซขนาดใหญ่และป่องพยายามปรับแต่งอินเทอร์เฟซและลองใช้วิธีการน้อยลงในอินเทอร์เฟซ กล่าวอีกนัยหนึ่งเราต้องสร้างอินเทอร์เฟซเฉพาะสำหรับแต่ละคลาสแทนที่จะพยายามสร้างอินเทอร์เฟซขนาดใหญ่สำหรับทุกคลาสที่ขึ้นอยู่กับการโทร ในตัวอย่างนี้หลักการของการแยกอินเทอร์เฟซจะถูกนำมาใช้เมื่อเปลี่ยนอินเทอร์เฟซขนาดใหญ่เป็นอินเทอร์เฟซเฉพาะสามตัว ในการเขียนโปรแกรมการพึ่งพาอินเทอร์เฟซเฉพาะหลายอย่างมีความยืดหยุ่นมากกว่าการใช้อินเทอร์เฟซที่ครอบคลุม อินเทอร์เฟซคือ "สัญญา" ที่ตั้งไว้สำหรับการตั้งค่าภายนอกระหว่างการออกแบบ โดยการกำหนดหลายอินเทอร์เฟซการแพร่กระจายของการเปลี่ยนแปลงภายนอกสามารถป้องกันได้และความยืดหยุ่นและความสามารถในการบำรุงรักษาของระบบสามารถปรับปรุงได้
เมื่อพูดถึงสิ่งนี้หลายคนจะรู้สึกว่าหลักการของการแยกอินเทอร์เฟซนั้นคล้ายกับหลักการความรับผิดชอบเดี่ยวก่อนหน้านี้ แต่ไม่ใช่ ประการแรกหลักการของความรับผิดชอบเดี่ยวมุ่งเน้นไปที่ความรับผิดชอบ; ในขณะที่หลักการของการแยกอินเทอร์เฟซมุ่งเน้นไปที่การแยกการพึ่งพาอินเตอร์เฟส ประการที่สองหลักการของความรับผิดชอบเดี่ยวส่วนใหญ่เป็นคลาสข้อ จำกัด ตามด้วยอินเทอร์เฟซและวิธีการซึ่งมุ่งเป้าไปที่การใช้งานและรายละเอียดในโปรแกรม ในขณะที่หลักการของการแยกอินเทอร์เฟซส่วนใหญ่ จำกัด อินเตอร์เฟสอินเทอร์เฟซส่วนใหญ่มุ่งเป้าไปที่สิ่งที่เป็นนามธรรมและมุ่งเป้าไปที่การสร้างกรอบโปรแกรมโดยรวม
เมื่อใช้หลักการของการแยกอินเทอร์เฟซเพื่อ จำกัด อินเทอร์เฟซประเด็นต่อไปนี้ควรให้ความสนใจกับ:
อินเทอร์เฟซควรมีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ แต่ควรมี จำกัด การปรับแต่งอินเทอร์เฟซสามารถปรับปรุงความยืดหยุ่นในการเขียนโปรแกรมเป็นความจริงที่ว่ามันไม่ได้ผลกำไร แต่ถ้ามันเล็กเกินไปมันจะทำให้เกิดอินเทอร์เฟซมากเกินไปและทำให้การออกแบบมีความซับซ้อน ดังนั้นจึงต้องอยู่ในระดับปานกลาง
บริการที่กำหนดเองสำหรับคลาสที่ขึ้นอยู่กับอินเทอร์เฟซเฉพาะวิธีการที่จะต้องสัมผัสกับคลาสที่เรียกว่าและวิธีการที่ไม่จำเป็นต้องซ่อนอยู่ โดยมุ่งเน้นที่การให้บริการที่กำหนดเองสำหรับโมดูลคุณสามารถสร้างความสัมพันธ์การพึ่งพาขั้นต่ำได้
ปรับปรุงการทำงานร่วมกันและลดปฏิสัมพันธ์ภายนอก ใช้จำนวนอินเทอร์เฟซน้อยที่สุดเพื่อทำสิ่งต่าง ๆ ให้สำเร็จ
เมื่อใช้หลักการของการแยกอินเทอร์เฟซจะต้องปานกลาง มันไม่ดีที่จะมีการออกแบบอินเทอร์เฟซขนาดใหญ่หรือเล็กเกินไป เมื่อออกแบบอินเทอร์เฟซโดยใช้เวลาคิดและการวางแผนมากขึ้นหลักการนี้สามารถฝึกฝนได้อย่างแม่นยำ