Giao diện là gì

Giao diện là một hợp đồng (thỏa thuận) công khai, được chấp nhận rộng rãi, mô tả một số hành vi. Họ cần chúng để làm gì? Ví dụ: giả sử chúng ta có một liên kết trỏ đến danh sách các chuỗi. Giả sử rằng nhiều phần tử được thêm vào danh sách này ngay từ đầu và sau đó toàn bộ danh sách được xử lý một lần. Giả sử chúng tôi quyết định làm theo khuyến nghị nổi tiếng và sử dụng lớpArrayList:

ArrayList<String> list = new ArrayList<>();

Chúng tôi đã viết hành vi của chương trình bằng 100.500 dòng mã sử dụng danh sách chuỗi này và sử dụng các phương thức dành riêng cho từng lớp để tối ưu hóa hiệu suất ArrayList. Ví dụ: EnsureCapacity() . Miễn là các dòng được thêm vào cuối danh sách, mọi thứ sẽ hoạt động tốt và nhanh chóng. Nhưng bây giờ chúng ta cần định hướng lại chương trình của mình sang một loại công việc hơi khác, trong đó các dòng chủ yếu được thêm vào đầu danh sách. Đối với loại tải này thì phù hợp hơn nhiều LinkedList. Nhưng nếu chúng ta muốn dịch chương trình gồm 100.500 dòng mã của mình sang Rails LinkedListthì chúng ta sẽ cần tìm và loại bỏ việc sử dụng ArrayListcác phương thức cụ thể, có thể ở một số nơi sẽ làm thay đổi đáng kể logic của từng phần riêng lẻ của chương trình. Nếu chúng ta chỉ sử dụng những phương thức có sẵn trong cả ArrayList, và in LinkedList, thì chúng ta sẽ không phải làm điều này. Chúng ta chỉ có thể thay đổi một dòng mã - khai báo danh sách:

LinkedList<String> list = new LinkedList<>();

Chúng ta có thể nhận thấy rằng sẽ thuận tiện hơn nếu đặt khai báo các phương thức chung cho các lớp này trong một lớp tổ tiên, có thể là lớp trừu tượng, chẳng hạn như AbstractList. Trong trường hợp này, chúng ta có thể khai báo danh sách của mình như thế này:

AbstractList<String> list = new ArrayList<>();

Và chúng ta có thể nhanh chóng chuyển đổi cách triển khai như thế này:

AbstractList<String> list = new LinkedList<>();

Nhưng trong trường hợp này, các lớp mà chúng ta có thể sử dụng trong chương trình của mình chỉ giới hạn ở các lớp con của lớp đó AbstractList, ngay cả khi có những lớp phù hợp hơn không phải là lớp con của lớp đó AbstractListnhưng có cùng phương thức với cùng hành vi. Tôi nên làm gì? Đây là lý do tại sao các giao diện được phát minh . Giao diện là một quy ước về một tập hợp các phương thức và hành vi của chúng mà các lớp hoàn toàn không liên quan có thể cam kết thực hiện, cho phép bất kỳ phương thức nào trong số chúng được tham chiếu bởi một tham chiếu duy nhất. Ví dụ như thế này:

List<String> list;
list = new ArrayList<>();
list = new LinkedList<>();
list = new AnotherListClass<>();

Ngay cả khi AnotherListClasscác lớp không có lớp tổ tiên chung, ArrayListngoại trừ . Một ví dụ điển hình về giao diện là hệ thống lái của ô tô - ô tô có vô lăng, bàn đạp và hộp số. Trong phần lớn ô tô, những yếu tố này tuân theo quy ước hành vi giống nhau. Ví dụ: nếu bạn quay vô lăng ngược chiều kim đồng hồ, xe sẽ rẽ trái thay vì tăng tốc, bất kể hãng sản xuất. Nếu bạn biết cách sử dụng các điều khiển này, bạn có thể dễ dàng điều khiển bất kỳ chiếc ô tô nào, bất kể kiểu dáng, năm sản xuất, hãng sản xuất hay loại động cơ. Hơn nữa, người ta có thể tưởng tượng một tình huống trong đó một loại phương tiện giao thông hoàn toàn khác (ví dụ: tàu vũ trụ) có giao diện điều khiển giống như ô tô. Nếu bạn biết lái ô tô, ngồi vào ghế lái của một con tàu như vậy, bạn sẽ có thể tránh bị lạc trong tình huống này. Hãy lặp lại một lần nữa:LinkedListObject

• Giao diện là một hợp đồng (thỏa thuận) về hành vi.
• Nhiều lớp, ngay cả những lớp không liên quan đến kế thừa, có thể tuyên bố rằng họ đồng ý tuân theo hợp đồng này (triển khai giao diện).
• Việc đặt mô tả hành vi trong một giao diện riêng biệt rất thuận tiện, vì nó làm tăng tính linh hoạt của mã, cho phép bạn chuyển đổi cách triển khai (lớp triển khai giao diện) của giao diện sang các lớp không liên quan đến kế thừa.