Lớp trừu tượng so với Giao diện trong Java


87

Tôi đã được hỏi một câu hỏi, tôi muốn xem lại câu trả lời của mình ở đây.

Hỏi: Trong trường hợp nào thì thích hợp hơn để mở rộng một lớp trừu tượng hơn là triển khai (các) giao diện?

A: Nếu chúng tôi đang sử dụng mẫu thiết kế phương pháp mẫu.

Tôi có đúng không?

Tôi xin lỗi nếu tôi không thể nói rõ câu hỏi.
Tôi biết sự khác biệt cơ bản giữa lớp trừu tượng và giao diện.

1) sử dụng lớp trừu tượng khi yêu cầu là chúng ta cần triển khai cùng một chức năng trong mọi lớp con cho một hoạt động cụ thể (triển khai phương thức) và chức năng khác cho một số hoạt động khác (chỉ ký hiệu phương thức)

2) sử dụng giao diện nếu bạn cần đặt chữ ký giống nhau (và triển khai khác nhau) để bạn có thể tuân thủ việc triển khai giao diện

3) chúng ta có thể mở rộng tối đa một lớp trừu tượng, nhưng có thể triển khai nhiều hơn một giao diện

Nhắc lại câu hỏi: Có bất kỳ kịch bản nào khác, ngoài những tình huống được đề cập ở trên, mà chúng ta yêu cầu sử dụng lớp trừu tượng một cách cụ thể (một trong những trường hợp được xem là mẫu thiết kế phương pháp mẫu chỉ dựa trên khái niệm này)?

Giao diện so với lớp trừu tượng

Lựa chọn giữa hai điều này thực sự phụ thuộc vào những gì bạn muốn làm, nhưng may mắn cho chúng tôi, Erich Gamma có thể giúp chúng tôi một chút.

Như mọi khi luôn có sự đánh đổi, một giao diện cho phép bạn tự do đối với lớp cơ sở, một lớp trừu tượng cho phép bạn tự do thêm các phương thức mới sau này . - Erich Gamma

Bạn không thể đi và thay đổi Giao diện mà không phải thay đổi nhiều thứ khác trong mã của mình, vì vậy cách duy nhất để tránh điều này là tạo một Giao diện hoàn toàn mới, điều này có thể không phải lúc nào cũng tốt.

Abstract classeschủ yếu nên được sử dụng cho các đối tượng có liên quan chặt chẽ với nhau. Interfacestốt hơn trong việc cung cấp chức năng chung cho các lớp không liên quan.




Đây không phải là bản sao. OP muốn biết khi nào nên mở rộng lớp trừu tượng hơn là triển khai một giao diện. Anh ta không muốn biết khi nào viết lớp trừu tượng hoặc giao diện. Lớp trừu tượng và giao diện của anh ấy đã được viết sẵn. Hd muốn biết nên gia hạn hoặc thực hiện.
Shiplu Mokaddim

1
@ shiplu.mokadd.im Đó là sự phân biệt không có sự khác biệt. Bạn không thể sử dụng một lớp trừu tượng mà không mở rộng nó. Nitpicking của bạn ở đây dường như hoàn toàn vô nghĩa.
Marquis of Lorne

Câu trả lời:


86

Khi nào sử dụng giao diện

Giao diện cho phép ai đó bắt đầu từ đầu để triển khai giao diện của bạn hoặc triển khai giao diện của bạn trong một số mã khác có mục đích ban đầu hoặc mục đích chính hoàn toàn khác với giao diện của bạn. Đối với họ, giao diện của bạn chỉ là ngẫu nhiên, một cái gì đó phải thêm vào mã của họ để có thể sử dụng gói của bạn. Điểm bất lợi là mọi phương thức trong giao diện phải được công khai. Bạn có thể không muốn phơi bày mọi thứ.

Khi nào sử dụng các lớp trừu tượng

Ngược lại, một lớp trừu tượng cung cấp nhiều cấu trúc hơn. Nó thường xác định một số triển khai mặc định và cung cấp một số công cụ hữu ích để triển khai đầy đủ. Vấn đề là, mã sử dụng nó phải sử dụng lớp của bạn làm cơ sở. Điều đó có thể rất bất tiện nếu các lập trình viên khác muốn sử dụng gói của bạn đã phát triển hệ thống phân cấp lớp của riêng họ một cách độc lập. Trong Java, một lớp chỉ có thể kế thừa từ một lớp cơ sở.

Khi nào sử dụng cả hai

Bạn có thể cung cấp những thứ tốt nhất của cả hai thế giới, một giao diện và một lớp trừu tượng. Người triển khai có thể bỏ qua lớp trừu tượng của bạn nếu họ chọn. Hạn chế duy nhất của việc làm đó là việc gọi các phương thức thông qua tên giao diện của chúng hơi chậm hơn so với việc gọi chúng qua tên lớp trừu tượng của chúng.


Tôi nghĩ rằng OP muốn biết khi nào nên mở rộng lớp trừu tượng hơn là thực hiện một giao diện
Shiplu Mokaddim

@ shiplu.mokadd.im Trên thực tế, OP đã hỏi một câu hỏi rất cụ thể, mà câu trả lời là 'có' hoặc 'không'.
Marquis of Lorne

4
Bạn đúng. Nhưng trong SO chúng tôi trả lời có / không với lời giải thích thích hợp.
Shiplu Mokaddim

1
@ shiplu.mokadd.im Tôi không hiểu bằng cách nào mà bạn có thể cho phép bạn nêu sai câu hỏi của anh ấy.
Marquis of Lorne

Chỉ trên cơ sở tuyên bố duy nhất này If we are using template method design patternchúng ta không thể nói YEShayNO
DivineDesert

31

nhắc lại câu hỏi: có bất kỳ tình huống nào khác ngoài những trường hợp được đề cập ở trên mà chúng tôi yêu cầu cụ thể sử dụng lớp trừu tượng (một trong những điều được thấy là mẫu thiết kế phương thức mẫu chỉ dựa trên khái niệm này)

Có, nếu bạn sử dụng JAXB. Nó không thích giao diện. Bạn nên sử dụng các lớp trừu tượng hoặc khắc phục hạn chế này với các lớp generic.

Từ một bài đăng trên blog cá nhân :

Giao diện:

  1. Một lớp có thể triển khai nhiều giao diện
  2. Một giao diện không thể cung cấp bất kỳ mã nào cả
  3. Một giao diện chỉ có thể xác định các hằng số cuối cùng tĩnh công khai
  4. Một giao diện không thể xác định các biến phiên bản
  5. Việc thêm một phương thức mới có tác dụng gợn sóng đối với việc triển khai các lớp (bảo trì thiết kế)
  6. JAXB không thể xử lý các giao diện
  7. Một giao diện không thể mở rộng hoặc triển khai một lớp trừu tượng
  8. Tất cả các phương thức giao diện là công khai

Nói chung, các giao diện nên được sử dụng để xác định các hợp đồng (những gì sẽ đạt được, không phải làm thế nào để đạt được nó).

Lớp Tóm tắt:

  1. Một lớp có thể mở rộng nhiều nhất một lớp trừu tượng
  2. Một lớp trừu tượng có thể chứa mã
  3. Một lớp trừu tượng có thể xác định cả hằng số tĩnh và hằng số thể hiện (cuối cùng)
  4. Một lớp trừu tượng có thể xác định các biến phiên bản
  5. Việc sửa đổi mã lớp trừu tượng hiện có có tác động gợn sóng đối với việc mở rộng các lớp (bảo trì triển khai)
  6. Việc thêm một phương thức mới vào một lớp trừu tượng không có tác dụng gợn sóng khi mở rộng các lớp
  7. Một lớp trừu tượng có thể triển khai một giao diện
  8. Các lớp trừu tượng có thể triển khai các phương thức riêng tư và được bảo vệ

Các lớp trừu tượng nên được sử dụng để triển khai (một phần). Chúng có thể là một phương tiện để hạn chế cách các hợp đồng API nên được thực hiện.


3
Trong Java 8 cho giao diện # 8, bạn cũng có thể có defaultstaticcác phương thức.
Người dùng mới làm quen với

15

Giao diện được sử dụng khi bạn có kịch bản mà tất cả các lớp có cấu trúc giống nhau nhưng hoàn toàn có chức năng khác nhau.

Lớp trừu tượng được sử dụng khi bạn có kịch bản mà tất cả các lớp có cấu trúc giống nhau nhưng một số chức năng giống nhau và khác nhau.

Hãy xem bài viết: http://shoaibmk.blogspot.com/2011/09/abstract-class-is-class-which-cannot-be.html


9

Có rất nhiều câu trả lời tuyệt vời ở đây, nhưng tôi thường thấy sử dụng CẢ HAI giao diện và các lớp trừu tượng là cách tốt nhất. Hãy xem xét ví dụ giả định này:

Bạn là nhà phát triển phần mềm tại một ngân hàng đầu tư và cần xây dựng một hệ thống đặt hàng vào thị trường. Giao diện của bạn nắm bắt được ý tưởng chung hầu hết những gì một hệ thống giao dịch thực hiện ,

1) Trading system places orders
2) Trading system receives acknowledgements

và có thể được chụp trong một giao diện, ITradeSystem

public interface ITradeSystem{

     public void placeOrder(IOrder order);
     public void ackOrder(IOrder order);

}

Giờ đây, các kỹ sư làm việc tại quầy bán hàng và dọc theo các ngành kinh doanh khác có thể bắt đầu giao tiếp với hệ thống của bạn để thêm chức năng đặt hàng vào các ứng dụng hiện có của họ. Và bạn thậm chí còn chưa bắt đầu xây dựng! Đây là sức mạnh của giao diện.

Vì vậy, bạn tiếp tục và xây dựng hệ thống cho các nhà giao dịch chứng khoán ; họ nghe nói rằng hệ thống của bạn có tính năng tìm cổ phiếu giá rẻ và rất háo hức dùng thử! Bạn nắm bắt được hành vi này trong một phương pháp được gọi là findGoodDeals(), nhưng cũng nhận ra rằng có rất nhiều thứ lộn xộn liên quan đến việc kết nối với thị trường. Ví dụ, bạn phải mở SocketChannel,

public class StockTradeSystem implements ITradeSystem{    

    @Override 
    public void placeOrder(IOrder order);
         getMarket().place(order);

    @Override 
    public void ackOrder(IOrder order);
         System.out.println("Order received" + order);    

    private void connectToMarket();
       SocketChannel sock = Socket.open();
       sock.bind(marketAddress); 
       <LOTS MORE MESSY CODE>
    }

    public void findGoodDeals();
       deals = <apply magic wizardry>
       System.out.println("The best stocks to buy are: " + deals);
    }

Việc triển khai cụ thể sẽ có rất nhiều phương pháp lộn xộn như thế này connectToMarket(), nhưng liệu findGoodDeals()các nhà giao dịch có thực sự quan tâm hay không.

Bây giờ đây là nơi các lớp trừu tượng phát huy tác dụng. Sếp của bạn thông báo với bạn rằng các nhà giao dịch tiền tệ cũng muốn sử dụng hệ thống của bạn. Và nhìn vào thị trường tiền tệ, bạn thấy hệ thống ống nước gần giống với thị trường chứng khoán. Trong thực tế, connectToMarket()có thể được sử dụng lại nguyên văn để kết nối với thị trường ngoại hối. Tuy nhiên, findGoodDeals()là một khái niệm khác nhiều trong lĩnh vực tiền tệ. Vì vậy, trước khi bạn vượt qua khỏi sự codebase đến ngoại hối Wiz đứa trẻ bên kia đại dương, bạn Refactor đầu tiên vào một abstractlớp, để lại findGoodDeals()unimplmented

public abstract class ABCTradeSystem implements ITradeSystem{    

    public abstract void findGoodDeals();

    @Override 
    public void placeOrder(IOrder order);
         getMarket().place(order);

    @Override 
    public void ackOrder(IOrder order);
         System.out.println("Order received" + order);    

    private void connectToMarket();
       SocketChannel sock = Socket.open();
       sock.bind(marketAddress); 
       <LOTS MORE MESSY CODE>
    }

Hệ thống giao dịch chứng khoán của bạn triển khai findGoodDeals()như bạn đã xác định,

public class StockTradeSystem extends ABCTradeSystem{    

    public void findGoodDeals();
       deals = <apply magic wizardry>
       System.out.println("The best stocks to buy are: " + deals);
    }

nhưng giờ đây, FX whiz kid có thể xây dựng hệ thống của mình bằng cách đơn giản cung cấp triển khai findGoodDeals()cho các loại tiền tệ; cô ấy không cần phải thực hiện lại các kết nối socket hoặc thậm chí các phương thức giao diện!

public class CurrencyTradeSystem extends ABCTradeSystem{    

    public void findGoodDeals();
       ccys = <Genius stuff to find undervalued currencies>
       System.out.println("The best FX spot rates are: " + ccys);
    }

Việc lập trình cho một giao diện rất mạnh mẽ, nhưng các ứng dụng tương tự thường thực hiện lại các phương pháp theo những cách gần giống nhau. Việc sử dụng một lớp trừu tượng sẽ tránh được các mô tả lại, đồng thời bảo toàn sức mạnh của giao diện.

Lưu ý: người ta có thể thắc mắc tại sao findGreatDeals()không phải là một phần của giao diện. Hãy nhớ rằng, giao diện xác định các thành phần chung nhất của hệ thống giao dịch. Một kỹ sư khác có thể phát triển một hệ thống giao dịch HOÀN TOÀN KHÁC BIỆT, nơi họ không quan tâm đến việc tìm kiếm những giao dịch tốt. Giao diện đảm bảo rằng bàn bán hàng cũng có thể giao tiếp với hệ thống của họ, vì vậy bạn không nên để giao diện của mình vướng vào các khái niệm ứng dụng như "ưu đãi lớn".


6

Bạn nên sử dụng cái nào, lớp trừu tượng hay giao diện?

Cân nhắc sử dụng các lớp trừu tượng nếu bất kỳ câu lệnh nào trong số này áp dụng cho trường hợp sử dụng của bạn:

Bạn muốn chia sẻ mã giữa một số lớp có liên quan chặt chẽ.

Bạn mong đợi rằng các lớp mở rộng lớp trừu tượng của bạn có nhiều phương thức hoặc trường phổ biến hoặc yêu cầu các công cụ sửa đổi truy cập không phải là công khai (chẳng hạn như bảo vệ và riêng tư).

Bạn muốn khai báo các trường không tĩnh hoặc không phải là trường cuối cùng. Điều này cho phép bạn xác định các phương thức có thể truy cập và sửa đổi trạng thái của đối tượng mà chúng thuộc về.

Cân nhắc sử dụng các giao diện nếu bất kỳ câu lệnh nào sau đây áp dụng cho trường hợp sử dụng của bạn:

Bạn mong đợi rằng các lớp không liên quan sẽ triển khai giao diện của bạn. Ví dụ, các giao diện có thể so sánh và nhân bản được thực hiện bởi nhiều lớp không liên quan.

Bạn muốn chỉ định hành vi của một kiểu dữ liệu cụ thể, nhưng không quan tâm đến việc ai thực hiện hành vi của nó.

Bạn muốn tận dụng đa kế thừa của kiểu.

http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html


4

Mọi thứ đã thay đổi rất nhiều trong ba năm qua với việc bổ sung các tính năng mới để giao diện với bản phát hành Java 8.

Từ trang tài liệu oracle trên giao diện:

Giao diện là một kiểu tham chiếu, tương tự như một lớp, chỉ có thể chứa hằng số, ký hiệu phương thức, phương thức mặc định, phương thức tĩnh và kiểu lồng nhau. Các thân phương thức chỉ tồn tại cho các phương thức mặc định và phương thức tĩnh.

Như bạn đã trích dẫn trong câu hỏi của mình, lớp trừu tượng phù hợp nhất với mẫu phương thức mẫu nơi bạn phải tạo khung. Giao diện không thể được sử dụng ở đây.

Một cân nhắc nữa để thích lớp trừu tượng hơn giao diện:

Bạn không có triển khai trong lớp cơ sở và chỉ các lớp con phải xác định việc triển khai của chính chúng. Bạn cần lớp trừu tượng thay vì giao diện vì bạn muốn chia sẻ trạng thái với các lớp con.

Thiết lập lớp trừu tượng "là một" mối quan hệ giữa các lớp liên quan và giao diện cung cấp khả năng "có một" khả năng giữa các lớp không liên quan .


Về phần thứ hai của câu hỏi của bạn, phần này hợp lệ với hầu hết các ngôn ngữ lập trình bao gồm java trước khi phát hành java-8

Như mọi khi luôn có sự đánh đổi, một giao diện cho phép bạn tự do đối với lớp cơ sở, một lớp trừu tượng cho phép bạn tự do thêm các phương thức mới sau này. - Erich Gamma

Bạn không thể đi và thay đổi Giao diện mà không cần phải thay đổi nhiều thứ khác trong mã của mình

Nếu bạn thích lớp trừu tượng để giao diện sớm hơn với hai điều trên, bạn phải suy nghĩ lại ngay bây giờ vì các phương thức mặc định đã thêm các khả năng mạnh mẽ cho giao diện.

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 tính 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 đó.

Để chọn một trong số chúng giữa giao diện và lớp trừu tượng, trang tài liệu oracle trích dẫn rằng:

Các lớp trừu tượng tương tự như các giao diện. Bạn không thể khởi tạo chúng và chúng có thể chứa hỗn hợp các phương thức được khai báo có hoặc không có triển khai. Tuy nhiên, với các lớp trừu tượng, bạn có thể khai báo các trường không phải là trường tĩnh và cuối cùng, đồng thời xác định các phương thức cụ thể công khai, bảo vệ và riêng tư.

Với giao diện, tất cả các trường tự động là công khai, tĩnh và cuối cùng và tất cả các phương thức mà bạn khai báo hoặc xác định (làm phương thức mặc định) là công khai. Ngoài ra, bạn chỉ có thể mở rộng một lớp, cho dù nó có trừu tượng hay không, trong khi bạn có thể triển khai bất kỳ số lượng giao diện nào.

Tham khảo các câu hỏi liên quan này để biết thêm chi tiết:

Giao diện so với Lớp trừu tượng (OO chung)

Tôi nên giải thích sự khác biệt giữa Giao diện và lớp Tóm tắt như thế nào?

Tóm lại: Sự cân bằng đang nghiêng nhiều hơn về các giao diện .

Có bất kỳ kịch bản nào khác, ngoài những kịch bản đã đề cập ở trên, trong đó chúng tôi yêu cầu sử dụng lớp trừu tượng một cách cụ thể (một trong đó là mẫu thiết kế phương thức mẫu chỉ dựa trên khái niệm này)?

Một số mẫu thiết kế sử dụng các lớp trừu tượng (trên các giao diện) ngoài mẫu phương thức Mẫu.

Các mẫu sáng tạo:

Abstract_factory_pattern

Các mẫu cấu trúc:

Decorator_pattern

Mẫu hành vi:

Mediator_pattern


Điều này: "Thiết lập lớp trừu tượng" là một "mối quan hệ giữa các lớp liên quan và cung cấp giao diện" có khả năng "giữa các lớp không liên quan."
Gabriel

3

Bạn không chính xác. Có rất nhiều kịch bản. Không thể giảm nó thành một quy tắc 8 từ duy nhất.


1
Trừ khi bạn mơ hồ như; Sử dụng giao diện bất cứ khi nào bạn có thể;)
Peter Lawrey

@PeterLawrey Yeah, đừng để đối số tròn chậm bạn xuống ;-)
Marquis của Lorne

Rốt cuộc đây là "tràn ngăn xếp". ;) Quan điểm của tôi là nếu bạn có thể sử dụng giao diện đơn giản hơn, hãy làm như vậy. Nếu không, bạn không có lựa chọn nào khác ngoài việc sử dụng một lớp trừu tượng. Tôi không thấy nó phức tạp lắm.
Peter Lawrey

tôi nghĩ bạn có thể đưa ra một ý tưởng mang tính xây dựng hơn. như nói về một số kịch bản đại diện /
Adams.H

3

Câu trả lời ngắn gọn nhất là, mở rộng lớp trừu tượng khi một số chức năng mà bạn tìm kiếm đã được triển khai trong nó.

Nếu bạn triển khai giao diện, bạn phải thực hiện tất cả các phương pháp. Nhưng đối với lớp trừu tượng, số phương thức bạn cần triển khai có thể ít hơn.

Trong mẫu thiết kế mẫu phải có một hành vi được xác định. Hành vi này phụ thuộc vào các phương thức trừu tượng khác. Bằng cách tạo lớp con và xác định các phương thức đó, bạn thực sự xác định hành vi chính. Hành vi cơ bản không thể có trong một giao diện vì giao diện không định nghĩa bất cứ điều gì, nó chỉ khai báo. Vì vậy, một mẫu thiết kế mẫu luôn đi kèm với một lớp trừu tượng. Nếu bạn muốn giữ nguyên luồng của hành vi, bạn phải mở rộng lớp trừu tượng nhưng không ghi đè hành vi chính.


Tài liệu tham khảo bổ sung cho hàm ảo thuần tuý sẽ bổ sung thêm những hiểu biết về hội tụ của Abstract class và Interface , Pure virtual functions can also be used where the method declarations are being used to define an interface - similar to what the interface keyword in Java explicitly specifies. In such a use, derived classes will supply all implementations. In such a design pattern, the abstract class which serves as an interface will contain only pure virtual functions, but no data members or ordinary methods. Phần (1/2)
Abhijeet

Phần (2/2) Sự phân kỳ của Lớp & Giao diện Trừu tượng được giải thích ở dòng cuối cùng ở trên no data members or ordinary methods[trong Lớp Trừu tượng].
Abhijeet

3

Theo tôi, sự khác biệt cơ bản là an interface can't contain non abstract methods while an abstract class can . Vì vậy, nếu các lớp con có chung một hành vi, hành vi này có thể được thực hiện trong lớp siêu và do đó được kế thừa trong các lớp con

Ngoài ra, tôi trích dẫn phần sau từ cuốn sách "ppatterns thiết kế kiến ​​trúc phần mềm trong java"

"Trong ngôn ngữ lập trình Java không có hỗ trợ đa kế thừa. Điều đó có nghĩa là một lớp chỉ có thể kế thừa từ một lớp duy nhất. Do đó, kế thừa chỉ nên được sử dụng khi thực sự cần thiết. Bất cứ khi nào có thể, các phương thức biểu thị hành vi chung phải được khai báo trong dạng giao diện Java được các lớp trình triển khai khác nhau triển khai. Nhưng các giao diện có hạn chế là chúng không thể cung cấp các triển khai phương thức. Điều này có nghĩa là mọi người triển khai giao diện phải triển khai rõ ràng tất cả các phương thức được khai báo trong một giao diện, ngay cả khi một số các phương thức đại diện cho phần bất biến của chức năng và có cách triển khai giống hệt nhau trong tất cả các lớp của trình triển khai. Điều này dẫn đến mã dư thừa.Ví dụ sau minh họa cách sử dụng mẫu Lớp cha trừu tượng trong những trường hợp như vậy mà không yêu cầu triển khai phương thức thừa. "


2

Các lớp trừu tượng khác với các giao diện ở hai khía cạnh quan trọng

  • chúng cung cấp triển khai mặc định cho các phương pháp đã chọn (được đề cập trong câu trả lời của bạn)
  • các lớp trừu tượng có thể có trạng thái (biến cá thể) - vì vậy đây là một tình huống nữa bạn muốn sử dụng chúng thay cho giao diện

Tôi sẽ hoàn thành rằng các giao diện có thể có các biến nhưng chúng theo mặc định là cuối cùng.
Tomasz Mularczyk

1

Đây là một câu hỏi hay Hai trong số này không giống nhau nhưng có thể được sử dụng cho một số lý do giống nhau, giống như viết lại. Khi tạo tốt nhất là sử dụng Giao diện. Khi nó xuống lớp, nó rất tốt cho việc gỡ lỗi.


0

Abstract classes should be extended when you want to some common behavior to get extended. Siêu lớp trừu tượng sẽ có hành vi chung và sẽ định nghĩa phương thức trừu tượng / hành vi cụ thể mà các lớp con sẽ thực hiện.

Interfaces allows you to change the implementation anytime allowing the interface to be intact.


0

Đây là sự hiểu biết của tôi, hy vọng điều này sẽ giúp

Các lớp trừu tượng:

  1. Có thể có các biến thành viên được kế thừa (không thể thực hiện trong giao diện)
  2. Có thể có các hàm tạo (giao diện không thể)
  3. Các phương thức của nó có thể có bất kỳ khả năng hiển thị nào (ví dụ: riêng tư, được bảo vệ, v.v. - trong khi tất cả các phương thức giao diện đều là công khai)
  4. Có thể có các phương thức được xác định (các phương pháp có triển khai)

Giao diện:

  1. Có thể có các biến, nhưng chúng đều là các biến cuối cùng tĩnh công khai
    • các giá trị không đổi không bao giờ thay đổi với một phạm vi tĩnh
    • các biến không tĩnh yêu cầu một phiên bản và bạn không thể khởi tạo một giao diện
  2. Tất cả các phương thức là trừu tượng (không có mã trong các phương thức trừu tượng)
    • tất cả mã phải thực sự được viết trong lớp triển khai giao diện cụ thể

0

Cách sử dụng tóm tắt và giao diện:

Một cái có "Is-A-Relationship" và một cái khác có "Has-A-Relationship"

Các thuộc tính mặc định đã được thiết lập ở dạng trừu tượng và các thuộc tính phụ có thể được thể hiện thông qua giao diện.

Ví dụ: -> Ở con người chúng ta có một số thuộc tính mặc định là ăn, ngủ, v.v. nhưng nếu ai có bất kỳ hoạt động ngoại khóa nào khác như bơi lội, chơi đùa, v.v. thì những thuộc tính đó có thể được thể hiện bằng Giao diện.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.