Có nhiều giao diện hơn là có các phương thức đúng không

Vì vậy, hãy nói rằng tôi có giao diện này:

public interface IBox
{
   public void setSize(int size);
   public int getSize();
   public int getArea();
  //...and so on
}

Và tôi có một lớp thực hiện nó:

public class Rectangle implements IBox
{
   private int size;
   //Methods here
}

Nếu tôi muốn sử dụng giao diện IBox, tôi thực sự không thể tạo một phiên bản của nó, theo cách:

public static void main(String args[])
{
    Ibox myBox=new Ibox();
}

đúng? Vì vậy, tôi thực sự phải làm điều này:

public static void main(String args[])
{
    Rectangle myBox=new Rectangle();
}

Nếu đó là sự thật, thì mục đích duy nhất của các giao diện là để đảm bảo rằng lớp thực hiện một giao diện đã có các phương thức chính xác trong nó như được mô tả bởi một giao diện? Hoặc có sử dụng giao diện nào khác không?

Giao diện là một cách để làm cho mã của bạn linh hoạt hơn. Những gì bạn làm là đây:

Ibox myBox=new Rectangle();

Sau đó, sau này, nếu bạn quyết định bạn muốn sử dụng một loại hộp khác (có thể có một thư viện khác, với loại hộp tốt hơn), bạn chuyển mã của mình sang:

Ibox myBox=new OtherKindOfBox();

Khi bạn đã quen với nó, bạn sẽ thấy đó là một cách tuyệt vời (thực sự cần thiết) để làm việc.

Một lý do khác là, ví dụ, nếu bạn muốn tạo một danh sách các hộp và thực hiện một số thao tác trên mỗi hộp, nhưng bạn muốn danh sách chứa các loại hộp khác nhau. Trên mỗi hộp bạn có thể làm:

myBox.close()

(giả sử IBox có phương thức close ()) mặc dù lớp myBox thực tế thay đổi tùy thuộc vào hộp bạn đang ở trong vòng lặp.

Điều làm cho các giao diện trở nên hữu ích không phải là "bạn có thể thay đổi ý định và sử dụng một triển khai khác sau đó và chỉ phải thay đổi một nơi mà đối tượng được tạo ra". Đó không phải là vấn đề.

Điểm thực sự đã có trong tên: họ xác định một giao diện mà bất kỳ ai cũng có thể thực hiện để sử dụng tất cả các mã hoạt động trên giao diện đó. Ví dụ tốt nhất là java.util.Collectionscung cấp tất cả các loại phương thức hữu ích chỉ hoạt động trên các giao diện, chẳng hạn như sort()hoặc reverse()cho List. Vấn đề ở đây là mã này hiện có thể được sử dụng để sắp xếp hoặc đảo ngược bất kỳ lớp nào thực hiện các Listgiao diện - không chỉ ArrayListvà LinkedList, mà cả các lớp mà bạn tự viết, có thể được thực hiện theo cách mà những người viết java.util.Collectionskhông bao giờ tưởng tượng được.

Theo cách tương tự, bạn có thể viết mã hoạt động trên các giao diện nổi tiếng hoặc giao diện bạn xác định và những người khác có thể sử dụng mã của bạn mà không cần phải yêu cầu bạn hỗ trợ các lớp của họ.

Một cách sử dụng giao diện phổ biến khác là cho Callbacks. Ví dụ: java.swing.table.TableCellRenderer , cho phép bạn tác động đến cách bảng Xoay hiển thị dữ liệu trong một cột nhất định. Bạn thực hiện giao diện đó, truyền một thể hiện cho JTablevà tại một số điểm trong quá trình hiển thị bảng, mã của bạn sẽ được gọi để thực hiện công việc của nó.

Một trong nhiều cách sử dụng mà tôi đã đọc là khó khăn khi không có giao diện sử dụng nhiều kế thừa trong Java:

class Animal
{
void walk() { } 
....
.... //other methods and finally
void chew() { } //concentrate on this
} 

Bây giờ, hãy tưởng tượng một trường hợp:

class Reptile extends Animal 
{ 
//reptile specific code here
} //not a problem here

nhưng,

class Bird extends Animal
{
...... //other Bird specific code
} //now Birds cannot chew so this would a problem in the sense Bird classes can also call chew() method which is unwanted

Thiết kế tốt hơn sẽ là:

class Animal
{
void walk() { } 
....
.... //other methods 
} 

Animal không có phương thức nhai () và thay vào đó được đặt trong một giao diện như:

interface Chewable {
void chew();
}

và có lớp Bò sát thực hiện điều này chứ không phải Chim (vì Chim không thể nhai):

class Reptile extends Animal implements Chewable { } 

và incase of Birds đơn giản:

class Bird extends Animal { }

Mục đích của giao diện là đa hình , còn gọi là thay thế kiểu . Ví dụ, đưa ra phương pháp sau:

public void scale(IBox b, int i) {
   b.setSize(b.getSize() * i);
}

Khi gọi scalephương thức, bạn có thể cung cấp bất kỳ giá trị nào thuộc loại thực hiện IBoxgiao diện. Nói cách khác, nếu Rectanglevà Squarecả hai thực hiện IBox, bạn có thể cung cấp một Rectanglehoặc Squarebất cứ nơi nào IBoxđược mong đợi.

Các giao diện cho phép các ngôn ngữ gõ tĩnh để hỗ trợ đa hình. Một người theo chủ nghĩa thuần túy hướng đối tượng sẽ nhấn mạnh rằng một ngôn ngữ sẽ cung cấp sự kế thừa, đóng gói, mô đun hóa và đa hình để trở thành một ngôn ngữ hướng đối tượng đầy đủ tính năng. Trong kiểu gõ động - hoặc vịt gõ - các ngôn ngữ (như Smalltalk,) tính đa hình là tầm thường; tuy nhiên, trong các ngôn ngữ được gõ tĩnh (như Java hoặc C #,) tính đa hình không phải là tầm thường (trên thực tế, trên bề mặt, nó có vẻ mâu thuẫn với khái niệm gõ mạnh.)

Hãy để tôi chứng minh:

Trong một ngôn ngữ được gõ động (hoặc gõ vịt) (như Smalltalk), tất cả các biến là tham chiếu đến các đối tượng (không có gì và không có gì nữa.) Vì vậy, trong Smalltalk, tôi có thể làm điều này:

|anAnimal|    
anAnimal := Pig new.
anAnimal makeNoise.

anAnimal := Cow new.
anAnimal makeNoise.

Mã đó:

1. Khai báo một biến cục bộ được gọi là anAnimal (lưu ý rằng chúng tôi KHÔNG chỉ định TYPE của biến - tất cả các biến là tham chiếu đến một đối tượng, không hơn không kém.)
2. Tạo một thể hiện mới của lớp có tên là "Pig"
3. Chỉ định rằng phiên bản mới của Pig cho biến anAnimal.
4. Gửi tin nhắn makeNoisecho lợn.
5. Lặp lại toàn bộ bằng cách sử dụng một con bò, nhưng gán nó cho cùng một biến chính xác như Lợn.

Mã Java tương tự sẽ trông giống như thế này (giả định rằng Duck và Cow là các lớp con của Animal:

Animal anAnimal = new Pig();
duck.makeNoise();

anAnimal = new Cow();
cow.makeNoise();

Đó là tất cả tốt và tốt, cho đến khi chúng tôi giới thiệu lớp Rau. Rau có một số hành vi tương tự như Động vật, nhưng không phải tất cả. Ví dụ, cả Động vật và Rau có thể có thể phát triển, nhưng rõ ràng rau không gây ra tiếng ồn và động vật không thể được thu hoạch.

Trong Smalltalk, chúng ta có thể viết điều này:

|aFarmObject|
aFarmObject := Cow new.
aFarmObject grow.
aFarmObject makeNoise.

aFarmObject := Corn new.
aFarmObject grow.
aFarmObject harvest.

Điều này hoạt động hoàn toàn tốt trong Smalltalk vì nó được gõ vịt (nếu nó đi như vịt và quạ như vịt - đó là một con vịt.) Trong trường hợp này, khi một tin nhắn được gửi đến một đối tượng, việc tra cứu được thực hiện trên danh sách phương thức của người nhận và nếu tìm thấy một phương thức phù hợp, nó được gọi. Nếu không, một số loại ngoại lệ NoSuchMethodError sẽ bị ném - nhưng tất cả đều được thực hiện trong thời gian chạy.

Nhưng trong Java, một ngôn ngữ được gõ tĩnh, chúng ta có thể gán loại nào cho biến của mình? Ngô cần được thừa hưởng từ Rau, để hỗ trợ phát triển, nhưng không thể thừa hưởng từ Động vật, vì nó không gây ra tiếng ồn. Bò cần thừa kế từ Động vật để hỗ trợ makeNùa, nhưng không thể thừa kế từ Rau vì không nên thực hiện thu hoạch. Có vẻ như chúng ta cần nhiều kế thừa - khả năng kế thừa từ nhiều hơn một lớp. Nhưng điều đó hóa ra là một tính năng ngôn ngữ khá khó khăn vì tất cả các trường hợp cạnh bật lên (điều gì xảy ra khi có nhiều hơn một siêu lớp song song thực hiện cùng một phương thức?, V.v.)

Giao diện đi kèm ...

Nếu chúng ta tạo các lớp Động vật và Thực vật, với mỗi lớp có thể phát triển, chúng ta có thể tuyên bố rằng Bò của chúng ta là Động vật và Ngô của chúng ta là Rau. Chúng tôi cũng có thể tuyên bố rằng cả Động vật và Rau quả đều có thể trồng được. Điều đó cho phép chúng tôi viết điều này để phát triển mọi thứ:

List<Growable> list = new ArrayList<Growable>();
list.add(new Cow());
list.add(new Corn());
list.add(new Pig());

for(Growable g : list) {
   g.grow();
}

Và nó cho phép chúng ta làm điều này, để tạo ra tiếng động vật:

List<Animal> list = new ArrayList<Animal>();
list.add(new Cow());
list.add(new Pig());
for(Animal a : list) {
  a.makeNoise();
}

Lợi thế của ngôn ngữ gõ vịt là bạn có được tính đa hình thực sự tốt: tất cả một lớp phải làm để cung cấp hành vi là cung cấp phương thức. Miễn là mọi người chơi đẹp và chỉ gửi tin nhắn phù hợp với các phương thức đã xác định, tất cả đều tốt. Nhược điểm là loại lỗi dưới đây không bị bắt cho đến khi chạy:

|aFarmObject|
aFarmObject := Corn new.
aFarmObject makeNoise. // No compiler error - not checked until runtime.

Các ngôn ngữ được nhập tĩnh cung cấp "lập trình theo hợp đồng" tốt hơn nhiều vì chúng sẽ bắt gặp hai loại lỗi dưới đây tại thời điểm biên dịch:

// Compiler error: Corn cannot be cast to Animal.
Animal farmObject = new Corn();  
farmObject makeNoise();

-

// Compiler error: Animal doesn't have the harvest message.
Animal farmObject = new Cow();
farmObject.harvest(); 

Vì vậy, .... để tóm tắt:

1. Giao diện triển khai cho phép bạn chỉ định loại công việc nào mà đối tượng có thể làm (tương tác) và kế thừa lớp cho phép bạn chỉ định cách mọi việc nên được thực hiện (triển khai).

2. Các giao diện cung cấp cho chúng ta nhiều lợi ích của đa hình "thực", mà không phải hy sinh việc kiểm tra kiểu trình biên dịch.

Thông thường Giao diện xác định giao diện bạn nên sử dụng (như tên gọi của nó ;-)). Mẫu vật

public void foo(List l) {
   ... do something
}

Bây giờ chức năng của bạn foochấp nhận ArrayLists, LinkedLists, ... không chỉ một loại.

Điều quan trọng nhất trong Java là bạn có thể triển khai nhiều giao diện nhưng bạn chỉ có thể mở rộng MỘT lớp! Mẫu vật:

class Test extends Foo implements Comparable, Serializable, Formattable {
...
}

class Test extends Foo, Bar, Buz {
...
}

Mã của bạn ở trên cũng có thể là : IBox myBox = new Rectangle();. Điều quan trọng bây giờ là CHỈ myBox chứa các phương thức / trường từ IBox chứ không phải các phương thức khác (có thể hiện có) từ đó Rectangle.

Tôi nghĩ bạn hiểu mọi thứ Giao diện làm, nhưng bạn chưa tưởng tượng ra các tình huống trong đó Giao diện hữu ích.

Nếu bạn đang khởi tạo, sử dụng và giải phóng tất cả một đối tượng trong phạm vi hẹp (ví dụ: trong một cuộc gọi phương thức), Giao diện không thực sự thêm bất cứ điều gì. Giống như bạn lưu ý, lớp bê tông được biết đến.

Trường hợp Giao diện hữu ích là khi một đối tượng cần được tạo một nơi và trả lại cho người gọi có thể không quan tâm đến các chi tiết triển khai. Hãy thay đổi ví dụ IBox của bạn thành Hình dạng. Bây giờ chúng ta có thể có các triển khai Hình dạng như Hình chữ nhật, Hình tròn, Tam giác, v.v., Việc triển khai các phương thức getArea () và getSize () sẽ hoàn toàn khác nhau đối với mỗi lớp cụ thể.

Bây giờ bạn có thể sử dụng một nhà máy với nhiều phương thức createShape (params) sẽ trả về một Hình dạng phù hợp tùy thuộc vào các thông số được truyền vào. Rõ ràng, nhà máy sẽ biết về loại Hình dạng nào đang được tạo, nhưng người gọi sẽ không có để quan tâm xem đó là hình tròn, hay hình vuông, v.v.

Bây giờ, hãy tưởng tượng bạn có một loạt các hoạt động bạn phải thực hiện trên hình dạng của bạn. Có thể bạn cần sắp xếp chúng theo khu vực, đặt tất cả chúng thành một kích thước mới và sau đó hiển thị chúng trong giao diện người dùng. Tất cả các Hình dạng đều được tạo bởi nhà máy và sau đó có thể được chuyển đến các lớp Sắp xếp, Trình tạo và Hiển thị rất dễ dàng. Nếu bạn cần thêm một lớp lục giác một thời gian trong tương lai, bạn không phải thay đổi bất cứ điều gì ngoài nhà máy. Không có Giao diện, việc thêm hình dạng khác trở thành một quá trình rất lộn xộn.

bạn có thể làm

Ibox myBox = new Rectangle();

theo cách đó bạn đang sử dụng đối tượng này như Ibox và bạn không quan tâm rằng nó thực sự Rectangle.

TẠI SAO GIAO DỊCH ??????

Nó bắt đầu với một con chó. Đặc biệt, một con pug .

Chó pug có nhiều hành vi khác nhau:

public class Pug { 
private String name;
public Pug(String n) { name = n; } 
public String getName() { return name; }  
public String bark() { return  "Arf!"; } 
public boolean hasCurlyTail() { return true; } }

Và bạn có một Labrador, người cũng có một tập hợp các hành vi.

public class Lab { 
private String name; 
public Lab(String n) { name = n; } 
public String getName() { return name; } 
public String bark() { return "Woof!"; } 
public boolean hasCurlyTail() { return false; } }

Chúng tôi có thể làm một số pugs và phòng thí nghiệm:

Pug pug = new Pug("Spot"); 
Lab lab = new Lab("Fido");

Và chúng ta có thể viện dẫn hành vi của họ:

pug.bark() -> "Arf!" 
lab.bark() -> "Woof!" 
pug.hasCurlyTail() -> true 
lab.hasCurlyTail() -> false 
pug.getName() -> "Spot"

Giả sử tôi chạy cũi chó và tôi cần theo dõi tất cả những con chó tôi đang ở. Tôi cần lưu trữ pugs và labradors của mình trong các mảng riêng biệt :

public class Kennel { 
Pug[] pugs = new Pug[10]; 
Lab[] labs = new Lab[10];  
public void addPug(Pug p) { ... } 
public void addLab(Lab l) { ... } 
public void printDogs() { // Display names of all the dogs } }

Nhưng điều này rõ ràng là không tối ưu. Nếu tôi cũng muốn nuôi một số poodle , tôi phải thay đổi định nghĩa Cũ của tôi để thêm một mảng Poodles. Trong thực tế, tôi cần một mảng riêng cho từng loại chó.

Cái nhìn sâu sắc: cả pugs và labradors (và poodle) là những loại chó và chúng có cùng một tập hợp hành vi. Đó là, chúng ta có thể nói (với mục đích của ví dụ này) rằng tất cả các con chó có thể sủa, có tên và có thể có hoặc không có đuôi xoăn. Chúng ta có thể sử dụng một giao diện để xác định những gì tất cả những con chó có thể làm, nhưng hãy để nó tùy thuộc vào các loại chó cụ thể để thực hiện những hành vi cụ thể đó. Giao diện cho biết "đây là những điều mà tất cả các con chó có thể làm" nhưng không cho biết mỗi hành vi được thực hiện như thế nào.

public interface Dog 
{
public String bark(); 
public String getName(); 
public boolean hasCurlyTail(); }

Sau đó, tôi thay đổi một chút các lớp Pug và Lab để thực hiện các hành vi của Chó. Chúng ta có thể nói rằng Pug là Chó và Lab là chó.

public class Pug implements Dog {
// the rest is the same as before } 

public class Lab implements Dog { 
// the rest is the same as before 
}

Tôi vẫn có thể khởi tạo Pugs và Labs như trước đây, nhưng bây giờ tôi cũng có một cách mới để làm điều đó:

Dog d1 = new Pug("Spot"); 
Dog d2 = new Lab("Fido");

Điều này nói rằng d1 không chỉ là một con chó, mà cụ thể là Pug. Và d2 cũng là một Dog, cụ thể là Lab. Chúng ta có thể gọi các hành vi và chúng hoạt động như trước:

d1.bark() -> "Arf!" 
d2.bark() -> "Woof!" 
d1.hasCurlyTail() -> true 
d2.hasCurlyTail() -> false 
d1.getName() -> "Spot"

Đây là nơi mà tất cả các công việc làm thêm được đền đáp. Lớp học cũ trở nên đơn giản hơn nhiều. Tôi chỉ cần một mảng và một phương thức addDog. Cả hai sẽ làm việc với bất kỳ đối tượng nào là một con chó; đó là các đối tượng thực hiện giao diện Dog.

public class Kennel {
Dog[] dogs = new Dog[20]; 
public void addDog(Dog d) { ... } 
public void printDogs() {
// Display names of all the dogs } }

Đây là cách sử dụng nó:

Kennel k = new Kennel(); 
Dog d1 = new Pug("Spot"); 
Dog d2 = new Lab("Fido"); 
k.addDog(d1); 
k.addDog(d2); 
k.printDogs();

Tuyên bố cuối cùng sẽ hiển thị: Spot Fido

Một giao diện cung cấp cho bạn khả năng chỉ định một tập hợp các hành vi mà tất cả các lớp thực hiện giao diện sẽ chia sẻ chung. Do đó, chúng ta có thể định nghĩa các biến và bộ sưu tập (chẳng hạn như mảng) mà không cần phải biết trước loại đối tượng cụ thể nào họ sẽ giữ, chỉ có điều họ sẽ giữ các đối tượng thực hiện giao diện.

Một ví dụ tuyệt vời về cách các giao diện được sử dụng là trong khung Bộ sưu tập. Nếu bạn viết một hàm mà phải mất một List, sau đó nó không quan trọng nếu người dùng đi vào một Vectorhoặc một ArrayListhoặc một HashListhoặc bất cứ điều gì. Và bạn có thể chuyển nó Listcho bất kỳ chức năng nào yêu cầu một giao diện Collectionhoặc Iterablequá.

Điều này làm cho các chức năng như Collections.sort(List list)có thể, bất kể cách thức Listđược thực hiện.

Đây là lý do tại sao các Mô hình nhà máy và các mẫu sáng tạo khác rất phổ biến trong Java. Bạn đúng rằng nếu không có chúng, Java sẽ không cung cấp cơ chế vượt trội để dễ dàng trừu tượng hóa việc khởi tạo. Tuy nhiên, bạn vẫn có được sự trừu tượng ở mọi nơi mà bạn không tạo một đối tượng trong phương thức của mình, đó là phần lớn mã của bạn.

Bên cạnh đó, tôi thường khuyến khích mọi người không tuân theo cơ chế "IRealname" để đặt tên giao diện. Đó là một thứ Windows / COM đặt một chân vào ký hiệu tiếng Hungary và thực sự không cần thiết (Java đã được gõ mạnh và toàn bộ quan điểm của việc có các giao diện là không thể phân biệt được với các loại lớp càng nhiều càng tốt).

Đừng quên rằng vào một ngày sau đó, bạn có thể lấy một lớp hiện có và làm cho nó thực hiện IBox, và sau đó nó sẽ có sẵn cho tất cả các mã nhận biết hộp của bạn.

Điều này trở nên rõ ràng hơn một chút nếu giao diện được đặt tên -able . ví dụ

public interface Saveable {
....

public interface Printable {
....

vv (Các kế hoạch đặt tên không phải lúc nào cũng hoạt động, ví dụ: Tôi không chắc Boxablelà phù hợp ở đây)

Mục đích duy nhất của các giao diện là để đảm bảo rằng lớp thực hiện một giao diện đã có các phương thức chính xác trong nó như được mô tả bởi một giao diện? Hoặc có sử dụng giao diện nào khác không?

Tôi đang cập nhật câu trả lời với các tính năng mới của giao diện, đã được giới thiệu với phiên bản java 8 .

Từ trang tài liệu oracle về tóm tắt giao diện :

Một khai báo giao diện có thể chứa

1. chữ ký phương thức
2. phương thức mặc định
3. phương pháp tĩnh
4. định nghĩa không đổi.

Các phương thức duy nhất có triển khai là các phương thức mặc định và tĩnh.

Công dụng của giao diện :

1. Xác định hợp đồng
2. Để liên kết các lớp không liên quan với có một khả năng (ví dụ: các lớp triển khai Serializablegiao diện có thể có hoặc không có bất kỳ mối quan hệ nào giữa chúng ngoại trừ việc thực hiện giao diện đó
3. Để cung cấp thực hiện hoán đổi cho nhau, ví dụ như mẫu chiến lược
4. Các phương thức mặc định cho phép bạn thêm chức năng mới vào các giao diện của thư viện và đảm bảo khả năng tương thích nhị phân với mã được viết cho các phiên bản cũ hơn của các giao diện đó
5. Sắp xếp các phương thức của trình trợ giúp trong các thư viện của bạn bằng các phương thức tĩnh (bạn có thể giữ các phương thức tĩnh cụ thể cho một giao diện trong cùng một giao diện thay vì trong một lớp riêng biệt)

Một số câu hỏi SE liên quan liên quan đến sự khác biệt giữa lớp trừu tượng và giao diện và các trường hợp sử dụng với các ví dụ hoạt động:

Sự khác biệt giữa một giao diện và lớp trừu tượng là gì?

Làm thế nào tôi có thể giải thích sự khác biệt giữa một lớp Giao diện và lớp Trừu tượng?

Hãy xem trang tài liệu để hiểu các tính năng mới được thêm vào trong java 8: phương thức mặc định và phương thức tĩnh .

Mục đích của các giao diện là trừu tượng hóa hoặc tách rời khỏi việc thực hiện.

Nếu bạn giới thiệu một sự trừu tượng trong chương trình của mình, bạn không quan tâm đến việc triển khai có thể. Bạn quan tâm đến những gì nó có thể làm và không làm như thế nào và bạn sử dụng một interfaceđể diễn đạt điều này trong Java.

Nếu bạn có CardboardBox và HtmlBox (cả hai đều triển khai IBox), bạn có thể chuyển cả hai phương thức này cho bất kỳ phương thức nào chấp nhận IBox. Mặc dù cả hai đều rất khác nhau và không hoàn toàn có thể hoán đổi cho nhau, các phương thức không quan tâm đến "mở" hoặc "thay đổi kích thước" vẫn có thể sử dụng các lớp của bạn (có lẽ vì chúng quan tâm đến việc cần bao nhiêu pixel để hiển thị thứ gì đó trên màn hình).

Các giao diện nơi một bào thai được thêm vào java để cho phép nhiều kế thừa. Các nhà phát triển của Java mặc dù / nhận ra rằng có nhiều kế thừa là một tính năng "nguy hiểm", đó là lý do tại sao lại nảy ra ý tưởng về giao diện.

nhiều kế thừa là nguy hiểm vì bạn có thể có một lớp như sau:

class Box{
    public int getSize(){
       return 0;
    }
    public int getArea(){
       return 1;
    }

}

class Triangle{
    public int getSize(){
       return 1;
    }
    public int getArea(){
       return 0;
    }

}

class FunckyFigure extends Box, Triable{
   // we do not implement the methods we will used the inherited ones
}

Đó sẽ là phương thức nên được gọi khi chúng ta sử dụng

   FunckyFigure.GetArea(); 

Tất cả các vấn đề được giải quyết với các giao diện, bởi vì bạn biết rằng bạn có thể mở rộng các giao diện và chúng sẽ không có các phương thức phân loại ... vì trình biên dịch rất hay và cho bạn biết nếu bạn không thực hiện một phương thức, nhưng tôi muốn nghĩ rằng đó là một tác dụng phụ của một ý tưởng thú vị hơn.

Dưới đây là sự hiểu biết của tôi về lợi thế giao diện. Đúng nếu tôi đã sai lầm. Hãy tưởng tượng chúng tôi đang phát triển HĐH và nhóm khác đang phát triển trình điều khiển cho một số thiết bị. Vì vậy, chúng tôi đã phát triển một giao diện StorageDevice. Chúng tôi có hai triển khai của nó (FDD và HDD) được cung cấp bởi nhóm các nhà phát triển khác.

Sau đó, chúng ta có một lớp OperationsSystem có thể gọi các phương thức giao diện như saveData bằng cách chỉ cần truyền một thể hiện của lớp đã triển khai giao diện StorageDevice.

Ưu điểm ở đây là chúng tôi không quan tâm đến việc triển khai giao diện. Nhóm khác sẽ thực hiện công việc bằng cách triển khai giao diện StorageDevice.

package mypack;

interface StorageDevice {
    void saveData (String data);
}


class FDD implements StorageDevice {
    public void saveData (String data) {
        System.out.println("Save to floppy drive! Data: "+data);
    }
}

class HDD implements StorageDevice {
    public void saveData (String data) {
        System.out.println("Save to hard disk drive! Data: "+data);
    }
}

class OperatingSystem {
    public String name;
    StorageDevice[] devices;
    public OperatingSystem(String name, StorageDevice[] devices) {

        this.name = name;
        this.devices = devices.clone();

        System.out.println("Running OS " + this.name);
        System.out.println("List with storage devices available:");
        for (StorageDevice s: devices) {
            System.out.println(s);
        }

    }

    public void saveSomeDataToStorageDevice (StorageDevice storage, String data) {
        storage.saveData(data);
    }
}

public class Main {

    public static void main(String[] args) {

        StorageDevice fdd0 = new FDD();
        StorageDevice hdd0 = new HDD();     
        StorageDevice[] devs = {fdd0, hdd0};        
        OperatingSystem os = new OperatingSystem("Linux", devs);
        os.saveSomeDataToStorageDevice(fdd0, "blah, blah, blah...");    
    }
}