คำจำกัดความ: ไคลเอนต์ไม่ควรขึ้นอยู่กับอินเทอร์เฟซที่ไม่ต้องการ การพึ่งพาของคลาสหนึ่งในอีกคลาสควรจะถูกสร้างขึ้นในอินเทอร์เฟซที่เล็กที่สุด
ปัญหามีต้นกำเนิด: คลาส A ขึ้นอยู่กับคลาส B ผ่านอินเตอร์เฟส I และคลาส C ขึ้นอยู่กับคลาส D ผ่านอินเตอร์เฟส I. หากอินเทอร์เฟซฉันไม่ใช่อินเตอร์เฟสที่เล็กที่สุดสำหรับคลาส A และคลาส B จากนั้นคลาส B และคลาส D ต้องใช้วิธีการที่ไม่ต้องการ
วิธีแก้ปัญหา: แบ่งอินเทอร์เฟซป่องฉันเป็นอินเทอร์เฟซอิสระหลายอย่างและคลาส A และคลาส C สร้างการอ้างอิงด้วยอินเทอร์เฟซที่ต้องการตามลำดับ นั่นคือหลักการของการแยกอินเทอร์เฟซถูกนำมาใช้
มายกตัวอย่างเพื่อแสดงหลักการของการแยกอินเทอร์เฟซ:
ความหมายของรูปนี้คือ: คลาส A ขึ้นอยู่กับวิธีการที่ 1, วิธีที่ 2, วิธีที่ 3 ในอินเตอร์เฟส I และคลาส B คือการใช้การพึ่งพาคลาส A คลาส C ขึ้นอยู่กับวิธีการที่ 1, วิธีที่ 4, วิธีที่ 5 ในอินเตอร์เฟส I และคลาส D คือการใช้วิธีการที่ไม่ได้ใช้ ดำเนินการ
ก่อนอื่นให้ดูตัวอย่างของการละเมิดการแยกอินเทอร์เฟซ:
อินเทอร์เฟซสาธารณะ iworker {งานโมฆะสาธารณะ (); โมฆะสาธารณะกิน (); } คนงานในชั้นเรียนสาธารณะใช้ iWorker {@Override โมฆะสาธารณะงาน () {// toDo worker work} @Override โมฆะสาธารณะกิน () {// คนงาน todo กิน}} หุ่นยนต์ชั้นเรียนสาธารณะใช้ iworker -
เนื่องจากหุ่นยนต์ไม่จำเป็นต้องกิน Iworker จึงถือว่าเป็นอินเทอร์เฟซป่อง แน่นอนคุณยังสามารถใช้วิธีการกินระยะสั้นในชั้นเรียนหุ่นยนต์ได้ แต่สิ่งนี้อาจทำให้เกิดข้อบกพร่องที่คาดเดาไม่ได้ ตัวอย่างเช่นหากวิธีการกินจำเป็นต้องใช้จำนวนกล่องอาหารกลางวันจะมีปรากฏการณ์ที่ไม่ถูกต้อง
ต่อไปนี้คือการใช้งานที่แก้ไขแล้ว:
อินเทอร์เฟซสาธารณะ iworker {งานโมฆะสาธารณะ (); } ส่วนต่อประสานสาธารณะ idiet {โมฆะสาธารณะ Eat (); } คนงานในชั้นเรียนสาธารณะใช้ iWorker, idiet {@Override public void work () {// toDo work} @Override โมฆะสาธารณะ Eat () {// toDo work}} หุ่นยนต์ชั้นเรียนสาธารณะใช้ iWorker {@Override Void Work () {//
สรุป:
1. อินเทอร์เฟซควรมีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้และเหนียวแน่นสูง แต่ควรเหมาะสมและมีรายละเอียดเกินไปและยากที่จะรักษา
2. หากได้รับการออกแบบเป็นอินเทอร์เฟซป่องมันสามารถแยกได้โดยใช้โหมดอะแดปเตอร์