Điểm của giao diện trong PHP là gì?


224

Giao diện cho phép bạn tạo mã xác định các phương thức của các lớp thực hiện nó. Tuy nhiên, bạn không thể thêm bất kỳ mã nào vào các phương thức đó.

Các lớp trừu tượng cho phép bạn làm điều tương tự, cùng với việc thêm mã vào phương thức.

Bây giờ nếu bạn có thể đạt được cùng một mục tiêu với các lớp trừu tượng, tại sao chúng ta thậm chí cần khái niệm về giao diện?

Tôi đã được bảo rằng nó phải liên quan đến lý thuyết OO từ C ++ đến Java, đó là những gì công cụ OO của PHP dựa trên. Là khái niệm hữu ích trong Java nhưng không phải trong PHP? Có phải đó chỉ là một cách để tránh bị giữ chỗ trong lớp trừu tượng? Tui bỏ lỡ điều gì vậy?


4
Bạn phải đọc cái này: stackoverflow.com/a/384067/14673
Luc M

khá chắc chắn đó là một trợ giúp tinh thần, và một trợ giúp giao tiếp. các giao diện đóng vai trò là công cụ giảng dạy tuyệt vời cho api của bạn, vì chúng đóng gói các dịch vụ mà api của bạn tiếp xúc với nhau theo một cách trừu tượng có thể được đọc mà không cần biết về việc triển khai. Điều này rất tốn kém, nhưng vì những người cảm thấy thoải mái với giao diện, đã có thể sử dụng các chức năng trực tiếp mà không cần các lớp, do đó tiết kiệm được một con trỏ. không có giao diện xác định ngôn ngữ, có thể khó lập kế hoạch trước cho nhiều lập trình viên, vì mọi người thường sử dụng "ngôn ngữ oop" thường thích thiết kế với giao diện hơn là trên giấy.
Dmitry

Câu trả lời:


142

Toàn bộ quan điểm của các giao diện là cung cấp cho bạn sự linh hoạt để lớp của bạn bị buộc phải thực hiện nhiều giao diện, nhưng vẫn không cho phép nhiều kế thừa. Các vấn đề với việc kế thừa từ nhiều lớp rất nhiều và đa dạng và trang wikipedia trên đó tổng hợp chúng khá tốt.

Giao diện là một sự thỏa hiệp. Hầu hết các vấn đề với nhiều kế thừa không áp dụng cho các lớp cơ sở trừu tượng, vì vậy hầu hết các ngôn ngữ hiện đại ngày nay vô hiệu hóa nhiều kế thừa nhưng gọi các giao diện lớp cơ sở trừu tượng và cho phép một lớp "thực hiện" bao nhiêu tùy ý.


39
Cũng có thể nói rằng * Các giao diện cung cấp thiết kế cho một lớp với việc thực hiện bằng không. * Các lớp trừu tượng cung cấp một số thiết kế, với một số thực hiện. Các lớp trừu tượng là hữu ích nhất khi các lớp con chia sẻ một số điểm tương đồng triển khai, nhưng khác nhau trong các triển khai nhất định.
Jrgns

@Craig, Không có vấn đề cố hữu với nhiều kế thừa, chỉ là các ngôn ngữ hiện tại không đủ mạnh để thực hiện chúng đúng cách. "Các vấn đề" thực sự có thể được khắc phục khá dễ dàng, ví dụ, nêu rõ đường dẫn kế thừa rõ ràng cho các chức năng được kế thừa cùng tên có thể giải quyết tình trạng khó xử kim cương.
Pacerier 7/03/2015

15
Đó hoàn toàn không phải là giao diện. Nó không phải là một sự thỏa hiệp đối với nhiều kế thừa, đó là về việc tạo ra một hợp đồng trừu tượng và khái niệm cho các đối tượng để thực hiện và cho các đối tượng / phương thức khác để tiêu thụ. giao diện là một công cụ cho đa hình, và không phải để kế thừa trực tiếp.
Ma của Madara

123

Khái niệm này hữu ích xung quanh trong lập trình hướng đối tượng. Đối với tôi, tôi nghĩ về một giao diện như một hợp đồng. Vì vậy, lớp tôi và lớp của bạn đồng ý về hợp đồng chữ ký phương thức này, chúng tôi có thể "giao diện". Đối với các lớp trừu tượng mà tôi thấy là nhiều lớp cơ sở khai thác một số phương thức và tôi cần điền chi tiết.


Điều này làm tôi hiểu nó một chút. Nó giống như với các không gian tên - vì vậy mã được chia sẻ dễ sử dụng hơn và không có xung đột. Thật dễ dàng hơn khi hai người tạo ra các lớp học trên cùng một cơ sở, phải không?
RedClover

Chúng ta không cần phân biệt khái niệm chung về một 'giao diện' với các giao diện cụ thể trong một ngôn ngữ như PHP? Bất kỳ chức năng nào, chẳng hạn, có một "giao diện" xác định cách bạn sử dụng nó và ẩn việc thực hiện nó. Vì vậy, loại giao diện "hợp đồng" đó không yêu cầu tính năng ngôn ngữ đặc biệt. Do đó, tính năng ngôn ngữ phải dành cho thứ khác (hoặc thêm vào đó).,
UuDdLrLrSs

70

Tại sao bạn cần một giao diện, nếu đã có các lớp trừu tượng? Để ngăn chặn nhiều kế thừa (có thể gây ra nhiều vấn đề được biết đến).

Một trong những vấn đề như vậy:

"Vấn đề kim cương" (đôi khi được gọi là "kim cương chết chóc") là một sự mơ hồ phát sinh khi hai lớp B và C thừa hưởng từ A và lớp D thừa hưởng từ cả B và C. Nếu có một phương pháp trong A mà B và C đã ghi đè và D không ghi đè lên nó, thì phiên bản nào của phương thức mà D kế thừa: phiên bản của B hoặc của C?

Nguồn: https://en.wikipedia.org/wiki/Mult Môn_inherribution#The_diamond_propet

Tại sao / Khi nào nên sử dụng giao diện? Một ví dụ ... Tất cả các xe trên thế giới đều có cùng giao diện (phương thức) ... AccelerationPedalIsOnTheRight(), BrakePedalISOnTheLeft(). Hãy tưởng tượng rằng mỗi thương hiệu xe hơi sẽ có những "phương pháp" khác với một thương hiệu khác. BMW sẽ có Phanh ở bên phải và Honda sẽ có phanh ở bên trái bánh xe. Mọi người sẽ phải học cách những "phương pháp" này hoạt động mỗi khi họ mua một thương hiệu xe hơi khác. Đó là lý do tại sao nên có cùng một giao diện ở nhiều "địa điểm".

Giao diện làm gì cho bạn (tại sao ai đó thậm chí sẽ sử dụng một giao diện)? Một giao diện ngăn bạn khỏi "lỗi" (nó đảm bảo với bạn rằng tất cả các lớp thực hiện một giao diện cụ thể, tất cả sẽ có các phương thức trong giao diện).

// Methods inside this interface must be implemented in all classes which implement this interface.
interface IPersonService
{   
    public function Create($personObject);
}

class MySqlPerson implements IPersonService
{
    public function Create($personObject)
    {
        // Create a new person in MySql database.
    }
}

class MongoPerson implements IPersonService
{
    public function Create($personObject)
    {
        // Mongo database creates a new person differently then MySQL does. But the code outside of this method doesn't care how a person will be added to the database, all it has to know is that the method Create() has 1 parameter (the person object).
    }
}

Bằng cách này, Create()phương thức sẽ luôn được sử dụng theo cùng một cách. Không có vấn đề gì nếu chúng ta đang sử dụng MySqlPersonlớp học hoặc MongoPersonlớp học. Cách chúng ta đang sử dụng một phương thức giữ nguyên (giao diện giữ nguyên).

Ví dụ: nó sẽ được sử dụng như thế này (ở mọi nơi trong mã của chúng tôi):

new MySqlPerson()->Create($personObject);
new MongoPerson()->Create($personObject);

Bằng cách này, một cái gì đó như thế này không thể xảy ra:

new MySqlPerson()->Create($personObject)
new MongoPerson()->Create($personsName, $personsAge);

Việc nhớ một giao diện dễ dàng hơn nhiều và sử dụng cùng một giao diện ở mọi nơi, hơn nhiều giao diện khác nhau.

Theo cách này, bên trong Create()phương thức có thể khác nhau đối với các lớp khác nhau, mà không ảnh hưởng đến mã "bên ngoài", gọi phương thức này. Tất cả các mã bên ngoài phải biết là phương thức Create()có 1 tham số ( $personObject), vì đó là cách mã bên ngoài sẽ sử dụng / gọi phương thức. Mã bên ngoài không quan tâm những gì xảy ra bên trong phương thức; nó chỉ phải biết cách sử dụng / gọi nó.

Bạn cũng có thể làm điều này mà không cần giao diện, nhưng nếu bạn sử dụng giao diện thì sẽ "an toàn" hơn (vì nó ngăn bạn mắc lỗi). Giao diện đảm bảo với bạn rằng phương thức Create()sẽ có cùng chữ ký (cùng loại và cùng số tham số) trong tất cả các lớp thực hiện giao diện. Bằng cách này, bạn có thể chắc chắn rằng BẤT K class lớp nào thực hiện IPersonServicegiao diện, sẽ có phương thức Create()(trong ví dụ này) và sẽ chỉ cần 1 tham số ( $personObject) để được gọi / sử dụng.

Một lớp thực hiện một giao diện phải thực hiện tất cả các phương thức mà giao diện đó có / có.

Tôi hy vọng rằng tôi đã không lặp lại quá nhiều.


Tương tự thực sự tốt đẹp với bàn đạp xe!
James

24

Sự khác biệt giữa việc sử dụng một giao diện và một lớp trừu tượng có liên quan nhiều đến tổ chức mã đối với tôi, hơn là việc thực thi bằng chính ngôn ngữ. Tôi sử dụng chúng rất nhiều khi chuẩn bị mã cho các nhà phát triển khác làm việc để chúng nằm trong các mẫu thiết kế dự định. Các giao diện là một loại "thiết kế theo hợp đồng", theo đó mã của bạn đồng ý trả lời một nhóm các lệnh gọi API được quy định có thể đến từ mã mà bạn không có.

Mặc dù sự kế thừa từ lớp trừu tượng là một mối quan hệ "là một", nhưng đó không phải lúc nào cũng là điều bạn muốn và việc thực hiện một giao diện giống như một mối quan hệ "hoạt động như một". Sự khác biệt này có thể khá đáng kể trong các bối cảnh nhất định.

Ví dụ: giả sử bạn có Tài khoản lớp trừu tượng từ đó nhiều lớp khác mở rộng (loại tài khoản, v.v.). Nó có một tập hợp các phương thức cụ thể chỉ áp dụng cho nhóm loại đó. Tuy nhiên, một số trong các lớp con tài khoản này triển khai Phiên bản, hoặc Có thể liệt kê hoặc Có thể chỉnh sửa để chúng có thể được ném vào các bộ điều khiển dự kiến ​​sẽ sử dụng các API đó. Bộ điều khiển không quan tâm nó là loại đối tượng nào

Ngược lại, tôi cũng có thể tạo một đối tượng không mở rộng từ Tài khoản, giả sử lớp trừu tượng Người dùng và vẫn triển khai Listable và Editable, nhưng không phải là Versionable, điều này không có ý nghĩa ở đây.

Theo cách này, tôi đang nói rằng lớp con FooUser KHÔNG phải là một tài khoản, nhưng DOES hoạt động như một đối tượng có thể chỉnh sửa. Tương tự như vậy, BarAccount mở rộng từ Tài khoản, nhưng không phải là lớp con Người dùng, nhưng thực hiện Có thể chỉnh sửa, Có thể nghe và cũng có thể Phiên bản.

Việc thêm tất cả các API này để có thể chỉnh sửa, có thể nghe và có thể phiên bản vào các lớp trừu tượng sẽ không chỉ lộn xộn và xấu xí, mà còn nhân đôi các giao diện phổ biến trong Tài khoản và Người dùng hoặc buộc đối tượng Người dùng của tôi phải triển khai Phiên bản, có thể chỉ để ném ngoại lệ.


Đây là nó ngay tại đây. Thực thi một cách cứng nhắc các nhà phát triển sử dụng các phương thức của bạn mà không cần mở rộng hoặc ghi đè lên chúng
Nick

21

Các giao diện về cơ bản là một bản thiết kế cho những gì bạn có thể tạo ra. Chúng định nghĩa các phương thức mà một lớp phải có , nhưng bạn có thể tạo các phương thức bổ sung bên ngoài các giới hạn đó.

Tôi không chắc ý của bạn là gì khi không thể thêm mã vào các phương thức - bởi vì bạn có thể. Bạn đang áp dụng giao diện cho một lớp trừu tượng hay lớp mở rộng nó?

Một phương thức trong giao diện được áp dụng cho lớp trừu tượng sẽ cần được thực hiện trong lớp trừu tượng đó. Tuy nhiên, áp dụng giao diện đó cho lớp mở rộng và phương thức chỉ cần thực hiện trong lớp mở rộng. Tôi có thể sai ở đây - Tôi không sử dụng giao diện thường xuyên như tôi có thể / nên làm.

Tôi đã luôn nghĩ các giao diện là một mô hình cho các nhà phát triển bên ngoài hoặc một quy tắc bổ sung để đảm bảo mọi thứ đều chính xác.


9
Trong PHP, các giao diện chỉ chứa khai báo phương thức và không triển khai thực tế. Tuy nhiên, các lớp trừu tượng cho phép bạn "thêm mã" vào các phương thức được kế thừa bởi các lớp mở rộng nó. Tôi tin rằng sự khác biệt này là những gì mk đã đề cập.
nocash

13

Bạn sẽ sử dụng các giao diện trong PHP:

  1. Để ẩn triển khai - thiết lập giao thức truy cập cho một lớp đối tượng, thay đổi triển khai cơ bản mà không tái cấu trúc ở tất cả các vị trí bạn đã sử dụng đối tượng đó
  2. Để kiểm tra loại - như đảm bảo rằng một tham số có một loại cụ thể $object instanceof MyInterface
  3. Để thực thi kiểm tra tham số trong thời gian chạy
  4. Để thực hiện nhiều hành vi thành một lớp duy nhất (xây dựng các kiểu phức tạp)

    class Car triển khai EngineInterface, BodyInterface, Chỉ đạo {

để Carbây giờ một đối tượng ca start(), stop()(EngineInterface) hoặc goRight(), goLeft()(Giao diện lái)

và những thứ khác tôi không thể nghĩ ra ngay bây giờ

Số 4 có lẽ là trường hợp sử dụng rõ ràng nhất mà bạn không thể giải quyết với các lớp trừu tượng.

Từ tư duy trong Java:

Một giao diện cho biết, Đây là những gì tất cả các lớp thực hiện giao diện cụ thể này sẽ trông như thế nào. Do đó, bất kỳ mã nào sử dụng một giao diện cụ thể đều biết phương thức nào có thể được gọi cho giao diện đó và đó là tất cả. Vì vậy, giao diện được sử dụng để thiết lập một giao thức GIAO giữa các lớp.


10

Các giao diện tồn tại không phải là cơ sở mà các lớp có thể mở rộng mà là bản đồ của các chức năng được yêu cầu.

Sau đây là một ví dụ về việc sử dụng giao diện trong đó một lớp trừu tượng không phù hợp:
Hãy nói rằng tôi có một ứng dụng lịch cho phép người dùng nhập dữ liệu lịch từ các nguồn bên ngoài. Tôi sẽ viết các lớp để xử lý nhập từng loại nguồn dữ liệu (ical, rss, nguyên tử, json) Mỗi ​​lớp đó sẽ thực hiện một giao diện chung để đảm bảo tất cả chúng đều có các phương thức chung mà ứng dụng của tôi cần để lấy dữ liệu.

<?php

interface ImportableFeed 
{
    public function getEvents();
}

Sau đó, khi người dùng thêm một nguồn cấp dữ liệu mới, tôi có thể xác định loại nguồn cấp dữ liệu đó và sử dụng lớp được phát triển cho loại đó để nhập dữ liệu. Mỗi lớp được viết để nhập dữ liệu cho một nguồn cấp dữ liệu cụ thể sẽ có mã hoàn toàn khác nhau, có thể có rất ít điểm tương đồng giữa các lớp bên ngoài thực tế là chúng được yêu cầu thực hiện giao diện cho phép ứng dụng của tôi tiêu thụ chúng. Nếu tôi sử dụng một lớp trừu tượng, tôi có thể dễ dàng bỏ qua thực tế là tôi đã không ghi đè phương thức getEvents () sẽ phá vỡ ứng dụng của tôi trong trường hợp này trong khi sử dụng giao diện sẽ không cho phép ứng dụng của tôi chạy nếu BẤT K of phương thức nào được định nghĩa trong giao diện không tồn tại trong lớp đã triển khai nó. Ứng dụng của tôi không phải quan tâm lớp nào sử dụng để lấy dữ liệu từ nguồn cấp dữ liệu,

Để tiến thêm một bước này, giao diện chứng tỏ là cực kỳ hữu ích khi tôi quay lại ứng dụng lịch của mình với mục đích thêm một loại nguồn cấp dữ liệu khác. Sử dụng giao diện ImportableFeed có nghĩa là tôi có thể tiếp tục thêm nhiều lớp nhập các loại nguồn cấp dữ liệu khác nhau bằng cách thêm các lớp mới thực hiện giao diện này. Điều này cho phép tôi thêm hàng tấn chức năng mà không phải thêm số lượng lớn không cần thiết vào ứng dụng cốt lõi của mình vì ứng dụng cốt lõi của tôi chỉ dựa vào các phương thức công khai có sẵn mà giao diện yêu cầu miễn là các lớp nhập nguồn cấp dữ liệu mới của tôi thực hiện giao diện ImportableFeed biết tôi chỉ có thể thả nó vào vị trí và tiếp tục di chuyển.

Đây chỉ là một khởi đầu rất đơn giản. Sau đó tôi có thể tạo một giao diện khác mà tất cả các lớp lịch của tôi có thể được yêu cầu để triển khai cung cấp nhiều chức năng cụ thể hơn cho loại nguồn cấp mà lớp xử lý. Một ví dụ điển hình khác là phương pháp xác minh loại nguồn cấp dữ liệu, v.v.

Điều này vượt ra ngoài câu hỏi nhưng vì tôi đã sử dụng ví dụ trên: Giao diện đi kèm với bộ vấn đề của riêng họ nếu được sử dụng theo cách này. Tôi thấy mình cần phải đảm bảo đầu ra được trả về từ các phương thức được triển khai để khớp với giao diện và để đạt được điều này, tôi sử dụng một IDE đọc các khối PHPDoc và thêm kiểu trả về như một gợi ý kiểu trong khối PHPDoc của giao diện. dịch sang lớp cụ thể thực hiện nó. Các lớp của tôi tiêu thụ đầu ra dữ liệu từ các lớp thực hiện giao diện này sau đó ít nhất sẽ biết rằng nó mong đợi một mảng được trả về trong ví dụ này:

<?php
interface ImportableFeed 
{
    /**
     * @return array
     */
    public function getEvents();
}

Không có nhiều chỗ để so sánh các lớp và giao diện trừu tượng. Các giao diện đơn giản là các bản đồ mà khi được triển khai yêu cầu lớp phải có một bộ giao diện công cộng.


Giải thích tốt :) Cảm ơn!
Razvan.432

Chỉ cần thêm thông tin: Trong lớp trừu tượng, nếu bạn khai báo phương thức là trừu tượng, nó hoạt động giống như giao diện, vì vậy bạn không thể bỏ qua thực tế là bạn đã không ghi đè getEvents (). Ứng dụng sẽ thất bại giống như với giao diện.
Rikudou_Sennin

8

Các giao diện không chỉ để đảm bảo các nhà phát triển triển khai các phương thức nhất định. Ý tưởng là bởi vì các lớp này được đảm bảo có một số phương thức nhất định, bạn có thể sử dụng các phương thức này ngay cả khi bạn không biết loại thực tế của lớp. Thí dụ:

interface Readable {
  String read();
}

List<Readable> readables; // dunno what these actually are, but we know they have read();
for(Readable reader : readables)
  System.out.println(reader.read());

Trong nhiều trường hợp, việc cung cấp một lớp cơ sở, trừu tượng hay không là không hợp lý, bởi vì việc triển khai rất khác nhau và không chia sẻ bất cứ điều gì chung ngoài một vài phương thức.

Các ngôn ngữ được gõ động có khái niệm "gõ vịt" nơi bạn không cần giao diện; bạn có thể tự do cho rằng đối tượng có phương thức mà bạn đang gọi trên đó. Điều này giải quyết vấn đề bằng các ngôn ngữ được nhập tĩnh trong đó đối tượng của bạn có một số phương thức (trong ví dụ của tôi, read ()), nhưng không thực hiện giao diện.


6

Theo tôi, các giao diện nên được ưu tiên hơn các lớp trừu tượng không có chức năng. Tôi sẽ không ngạc nhiên nếu thậm chí sẽ có một màn trình diễn xuất hiện ở đó, vì chỉ có một đối tượng được khởi tạo, thay vì phân tích hai, kết hợp chúng (mặc dù, tôi không thể chắc chắn, tôi không quen với hoạt động bên trong của OOP PHP).

Đúng là các giao diện ít hữu ích / có ý nghĩa hơn so với, nói, Java. Mặt khác, PHP6 sẽ giới thiệu nhiều gợi ý kiểu hơn, bao gồm cả gợi ý kiểu cho các giá trị trả về. Điều này sẽ thêm một số giá trị cho các giao diện PHP.

tl; dr: giao diện xác định danh sách các phương thức cần phải tuân theo (nghĩ API), trong khi một lớp trừu tượng cung cấp một số chức năng cơ bản / phổ biến, mà các lớp con tinh chỉnh cho các nhu cầu cụ thể.


PHP 6 sẽ không bao giờ được phát hành. PHP 6 là một dự án đang được phát triển từ năm 2005-2010, nhưng nó đã bị trì hoãn và cuối cùng bị hủy bỏ. PHP 7 là phiên bản tiếp theo, chủ yếu là để tránh nhầm lẫn với dự án PHP 6 trước đây.
Ashu Jha

5

Tôi không thể nhớ nếu PHP khác về mặt này, nhưng trong Java, bạn có thể triển khai nhiều Giao diện, nhưng bạn không thể kế thừa nhiều lớp trừu tượng. Tôi cho rằng PHP hoạt động theo cùng một cách.

Trong PHP, bạn có thể áp dụng nhiều giao diện bằng cách tách chúng bằng dấu phẩy (tôi nghĩ rằng, tôi không thấy rằng đó là một giải pháp rõ ràng).

Đối với nhiều lớp trừu tượng, bạn có thể có nhiều tóm tắt mở rộng lẫn nhau (một lần nữa, tôi không hoàn toàn chắc chắn về điều đó nhưng tôi nghĩ rằng tôi đã thấy điều đó ở đâu đó trước đây). Điều duy nhất bạn không thể mở rộng là một lớp học cuối cùng.


4

Các giao diện sẽ không cung cấp cho mã của bạn bất kỳ tăng hiệu suất hoặc bất cứ thứ gì tương tự, nhưng chúng có thể đi một chặng đường dài để làm cho nó có thể duy trì được. Đúng là một lớp trừu tượng (hoặc thậm chí là một lớp không trừu tượng) có thể được sử dụng để thiết lập giao diện cho mã của bạn, nhưng các giao diện thích hợp (những giao diện bạn xác định bằng từ khóa và chỉ chứa chữ ký phương thức) thì dễ dàng hơn sắp xếp và đọc.

Điều đó đang được nói, tôi có xu hướng sử dụng thận trọng khi quyết định có sử dụng giao diện trên một lớp hay không. Đôi khi tôi muốn triển khai phương thức mặc định hoặc các biến sẽ phổ biến cho tất cả các lớp con.

Tất nhiên, điểm về việc thực hiện nhiều giao diện cũng là một âm thanh. Nếu bạn có một lớp thực hiện nhiều giao diện, bạn có thể sử dụng một đối tượng của lớp đó làm các loại khác nhau trong cùng một ứng dụng.

Tuy nhiên, thực tế rằng câu hỏi của bạn là về PHP, làm cho mọi thứ thú vị hơn một chút. Việc gõ vào các giao diện vẫn không thực sự cần thiết trong PHP, nơi bạn có thể cung cấp khá nhiều thứ cho bất kỳ phương thức nào, bất kể kiểu của nó là gì. Bạn có thể nhập tĩnh các tham số phương thức, nhưng một số trong đó bị hỏng (Chuỗi, tôi tin rằng, gây ra một số trục trặc). Kết hợp điều này với thực tế là bạn không thể gõ hầu hết các tài liệu tham khảo khác và không có nhiều giá trị trong việc cố gắng gõ tĩnh trong PHP ( tại thời điểm này ). Và do đó, giá trị của các giao diện trong PHP , tại thời điểm nàyít hơn nhiều so với các ngôn ngữ được gõ mạnh hơn. Họ có lợi ích của khả năng đọc, nhưng ít khác. Nhiều triển khai thậm chí không có lợi, bởi vì bạn vẫn phải khai báo các phương thức và cung cấp cho chúng các cơ quan trong trình triển khai.


2

Dưới đây là những điểm cho Giao diện PHP

  1. Nó được sử dụng để xác định yêu cầu không có phương thức nào trong lớp [nếu bạn muốn tải html thì id và tên là bắt buộc, vì vậy trong trường hợp này giao diện bao gồm setID và setName].
  2. Giao diện buộc lớp nghiêm ngặt bao gồm tất cả các phương thức định nghĩa trong nó.
  3. Bạn chỉ có thể xác định phương thức trong giao diện với khả năng truy cập công cộng.
  4. Bạn cũng có thể mở rộng giao diện như lớp. Bạn có thể mở rộng giao diện trong php bằng cách sử dụng từ khóa mở rộng.
  5. Mở rộng nhiều giao diện.
  6. Bạn không thể thực hiện 2 giao diện nếu cả hai chia sẻ chức năng có cùng tên. Nó sẽ ném lỗi.

Mã ví dụ:

interface test{
    public function A($i);
    public function B($j = 20);
}

class xyz implements test{
    public function A($a){
        echo "CLASS A Value is ".$a;
    }
    public function B($b){
        echo "CLASS B Value is ".$b;
    }
}
$x = new xyz();
echo $x->A(11);
echo "<br/>";
echo $x->B(10);

2

Chúng tôi đã thấy rằng các lớp và giao diện trừu tượng tương tự nhau ở chỗ chúng cung cấp các phương thức trừu tượng phải được thực hiện trong các lớp con. Tuy nhiên, chúng vẫn có những điểm khác biệt sau:

1. Các giao diện có thể bao gồm các phương thức và hằng trừu tượng, nhưng không thể chứa các phương thức và biến cụ thể.

2.Tất cả các phương thức trong giao diện phải nằm trong phạm vi hiển thị công khai .

3. Một lớp có thể thực hiện nhiều giao diện, trong khi nó chỉ có thể kế thừa từ một lớp trừu tượng.

                                  interface                      abstract class
the code                     - abstract methods               - abstract methods
                             - constants                      - constants                  
                                                              - concrete methods
                                                              - concrete variables

access modifiers             
                             - public                         - public
                                                              - protected
                                                              - private
                                                                etc.
number of parents          The same class can implement
                           more than 1 interface              The child class can 
                                                              inherit only from 1 abstract class

Hy vọng điều này sẽ giúp bất cứ ai hiểu!


2

Giao diện giống như gen của bạn.

Các lớp học trừu tượng giống như cha mẹ thực tế của bạn.

Mục đích của chúng là di truyền, nhưng trong trường hợp các lớp trừu tượng so với giao diện, những gì được kế thừa sẽ cụ thể hơn.


2

Tôi không biết về các ngôn ngữ khác, khái niệm giao diện ở đó là gì. Nhưng đối với PHP, tôi sẽ cố gắng hết sức để giải thích nó. Chỉ cần kiên nhẫn, và hãy bình luận nếu điều này có ích.

Một giao diện hoạt động như một "hợp đồng", chỉ định những gì một nhóm các lớp con làm, nhưng không phải là cách chúng thực hiện nó.

Quy tắc

  1. Một giao diện không thể được khởi tạo.

  2. Bạn không thể thực hiện bất kỳ phương thức nào trong một giao diện, tức là nó chỉ chứa .signature của phương thức chứ không chứa chi tiết (phần thân).

  3. Các giao diện có thể chứa các phương thức và / hoặc hằng, nhưng không có thuộc tính. Các hằng số giao diện có các hạn chế giống như các hằng lớp. Phương pháp giao diện là ngầm trừu tượng.

  4. Các giao diện không được khai báo các hàm tạo hoặc hàm hủy, vì đây là các chi tiết triển khai ở cấp độ lớp.

  5. Tất cả các phương thức trong một giao diện phải có khả năng hiển thị công khai.

Bây giờ hãy lấy một ví dụ. Giả sử chúng ta có hai món đồ chơi: một là Chó và một là Mèo.

Như chúng ta biết một con chó sủa và mèo mews. Hai người này có cùng một phương thức nói, nhưng với chức năng hoặc cách thực hiện khác nhau. Giả sử chúng tôi đang cung cấp cho người dùng một điều khiển từ xa có nút nói.

Khi người dùng nhấn nút nói, đồ chơi phải nói không thành vấn đề nếu đó là Chó hay Mèo.

Đây là một trường hợp tốt để sử dụng một giao diện, không phải là một lớp trừu tượng bởi vì các triển khai là khác nhau. Tại sao? Nhớ lại

Nếu bạn cần hỗ trợ các lớp con bằng cách thêm một số phương thức không trừu tượng, bạn nên sử dụng các lớp trừu tượng. Nếu không, giao diện sẽ là sự lựa chọn của bạ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.