PHP'deki arayüzlerin anlamı nedir?


224

Arabirimler , onu uygulayan sınıfların yöntemlerini tanımlayan bir kod oluşturmanıza olanak tanır. Ancak bu yöntemlere herhangi bir kod ekleyemezsiniz.

Soyut sınıflar , yönteme kod eklemenin yanı sıra aynı şeyi yapmanızı sağlar.

Şimdi soyut sınıflarla aynı hedefe ulaşabilirseniz, neden arayüzler konseptine bile ihtiyacımız var?

Bana PHP'nin OO şeyler dayalı C ++ Java, OO teorisi ile ilgili olduğu söylendi. Kavram Java'da yararlı, ancak PHP'de değil mi? Soyut sınıfta yer tutucuların çöp bırakmasını önlemenin bir yolu mu? Bir şey mi kaçırıyorum?


4
Bunu okumak zorundasınız: stackoverflow.com/a/384067/14673
Luc M

bunun zihinsel bir yardım ve bir iletişim yardımı olduğuna eminim. arayüzler api'niz için mükemmel öğretim araçları görevi görür, çünkü api'nizin ortaya koyduğu hizmetleri, uygulamayı bilmeden okunabilecek soyut bir şekilde bir araya getirir. Bu pahalıdır, ancak arabirimden rahat olan insanlar, sınıflara ihtiyaç duymadan işlevleri doğrudan kullanabilir ve böylece bir işaretçi kaydedebilir. dil tanımlı arayüzler olmadan, birçok programcı için ileriye dönük plan yapmak zor olabilir, çünkü insanlar “oop dillerini” kullandılar, genellikle kağıt yerine arayüzlerle tasarım yapmayı tercih ederler.
Dmitry

Yanıtlar:


142

Arayüzlerin tamamı, sınıfınızın birden fazla arayüz uygulamak zorunda kalmasına esneklik kazandırmak, ancak yine de çoklu kalıtıma izin vermemek için esneklik sağlamaktır. Birden fazla sınıftan kalıtımla ilgili sorunlar çok ve çeşitlidir ve wikipedia sayfası onları oldukça iyi özetlemektedir.

Arayüzler bir uzlaşmadır. Çoklu kalıtımla ilgili sorunların çoğu soyut temel sınıflar için geçerli değildir, bu yüzden günümüzde çoğu modern dil çoklu kalıtımı devre dışı bırakır, ancak soyut temel sınıf arayüzlerini çağırır ve bir sınıfın istedikleri kadarını "uygulamasına" izin verir.


39
Ayrıca * Arayüzler sıfır uygulamaya sahip bir sınıfın tasarımını sağladığı söylenebilir. * Soyut sınıflar bazı tasarımlar ve bazı uygulamalar sağlar. Soyut sınıflar, çocuk sınıflarının bazı uygulama benzerliklerini paylaştığı ancak bazı uygulamalarda farklılık gösterdiği durumlarda en kullanışlıdır.
Jrgns

@Craig, Birden fazla kalıtımla ilgili doğal bir sorun yok, sadece mevcut diller bunları doğru şekilde uygulayacak kadar güçlü değil. "Sorunlar" aslında oldukça kolay bir şekilde düzeltilebilir, örneğin, aynı ismin kalıtsal fonksiyonları için açık miras yolunu belirtmek elmas ikilemini çözebilir.
Pacerier

15
Arayüzler hiç de öyle değil. Birden fazla mirastan ödün vermek değil, nesnelerin uygulanması ve diğer nesnelerin / yöntemlerin tüketilmesi için kavramsal ve soyut bir sözleşme oluşturmakla ilgilidir. arayüzler, doğrudan kalıtım için değil, polimorfizm için bir araçtır.
Madara'nın Hayaleti

123

Kavram, nesne yönelimli programlamada her yerde yararlıdır. Bana göre bir arayüzü bir sözleşme olarak düşünüyorum. Benim sınıf ve sınıf bu yöntem imza sözleşmesi üzerinde anlaştıkça biz "arayüz" olabilir. Soyut sınıflara gelince, bazı yöntemleri saplayan temel sınıflar olarak görüyorum ve ayrıntıları doldurmam gerekiyor.


Bu beni biraz anlamamı sağladı. Ad alanlarında olduğu gibi - paylaşılan kodun kullanımı daha kolaydır ve çakışma olmadan. İki kişi aynı temelde ders yaparken daha kolay, değil mi?
RedClover

Genel bir 'arayüz' kavramını PHP gibi bir dilde somut arayüzlerden ayırmamız gerekmez mi? Örneğin herhangi bir işlevin, onu nasıl kullandığınızı tanımlayan ve uygulanmasını gizleyen bir "arabirimi" vardır. Böylece bu tür "sözleşmeye dayalı" arayüz özel bir dil özelliği gerektirmez. Bu nedenle dil özelliği başka bir şey (veya ek olarak bir şey) için olmalıdır.,
UuDdLrLrSs

70

Zaten soyut sınıflar varsa neden bir arayüze ihtiyacınız var? Çoklu kalıtımın önlenmesi (bilinen birden fazla soruna neden olabilir).

Bu tür problemlerden biri:

"Elmas problemi" (bazen "ölümcül ölüm pırlantası" olarak da anılır), iki B ve C sınıfı A'dan ve D sınıfı hem B hem de C'den miras alındığında ortaya çıkan bir belirsizliktir. A'da bir yöntem varsa B ve C geçersiz kılındı ​​ve D onu geçersiz kılmadı, o zaman D yöntemin hangi sürümü miras alır: B'nin mi yoksa C'nin mi?

Kaynak: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem

Neden / ne zaman bir arayüz kullanılır? Bir örnek ... Dünyadaki tüm arabalar aynı arayüze (yöntemlere) sahiptir ... AccelerationPedalIsOnTheRight(), BrakePedalISOnTheLeft(). Her otomobil markasının bu "yöntemlere" başka bir markadan farklı olacağını düşünün. BMW'nin sağ tarafında frenler ve Honda'da tekerleğin sol tarafında frenler olurdu. İnsanlar farklı bir marka otomobil satın aldıklarında bu "yöntemlerin" nasıl çalıştığını öğrenmek zorunda kalacaklardı. Bu yüzden aynı arayüzü birden çok "yerde" kullanmak iyi bir fikirdir.

Bir arayüz sizin için ne yapar (neden biri bile bir tane kullansın)? Bir arabirim "hatalar" yapmanızı engeller (belirli bir arabirimi uygulayan tüm sınıfların, arabirimde bulunan yöntemlere sahip olmasını sağlar).

// 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).
    }
}

Bu şekilde, Create()yöntem her zaman aynı şekilde kullanılacaktır. MySqlPersonSınıfı mı yoksa sınıfı mı kullanmamız önemli değil MongoPerson. Bir yöntemi kullanma şeklimiz aynı kalır (arayüz aynı kalır).

Örneğin, şu şekilde kullanılacaktır (kodumuzun her yerinde):

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

Bu şekilde, böyle bir şey olamaz:

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

Bir arayüzü hatırlamak ve aynı arayüzü her yerde kullanmak, birden fazla farklı arayüzden çok daha kolaydır.

Bu şekilde, Create()yöntemin içi, bu yöntemi çağıran "dış" kodu etkilemeden farklı sınıflar için farklı olabilir. Dış kodun bilmesi gereken, yöntemin Create()1 parametresine ( $personObject) sahip olmasıdır, çünkü dış kod bu yöntemi kullanacak / çağıracaktır. Dış kod, yöntemin içinde neler olduğunu umursamıyor; sadece onu nasıl kullanacağını / arayacağını bilmelidir.

Bunu bir arabirim olmadan da yapabilirsiniz, ancak bir arabirim kullanırsanız, "daha güvenlidir" (çünkü hata yapmanızı engeller). Arayüz, yöntemin Create(), arabirimi uygulayan tüm sınıflarda aynı imzayı (aynı tür ve aynı sayıda parametre) sahip olmasını sağlar. Bu şekilde, IPersonServicearabirimi uygulayan HERHANGİ sınıfın yönteme Create()(bu örnekte) sahip olduğundan ve $personObjectçağrılacak / kullanılacak yalnızca 1 parametreye ( ) ihtiyaç duyacağından emin olabilirsiniz .

Bir arabirimi uygulayan bir sınıf, arabirimin sahip olduğu / sahip olduğu tüm yöntemleri uygulamalıdır.

Umarım kendimi fazla tekrarlamamıştım.


Araba pedalları ile gerçekten güzel bir benzetme!
James

24

Bir arayüz ve soyut bir sınıf kullanma arasındaki farkın, kod organizasyonu ile benim için, dilin uygulamasından çok daha fazlası vardır. Diğer geliştiricilerin çalışacakları kodları hazırlarken, onları tasarlanan tasarım desenleri içinde kalmaları için çok kullanıyorum. Arayüzler, kodunuzun, sahip olmadığınız koddan gelebilecek bir dizi API çağrısına yanıt vermeyi kabul ettiği bir tür "sözleşme ile tasarım" dır.

Soyut sınıftan miras "bir" ilişkidir, ancak her zaman istediğiniz şey değildir ve bir arayüz uygulamak daha çok "gibi davranır" ilişkisidir. Bu fark bazı bağlamlarda oldukça önemli olabilir.

Örneğin, diğer birçok sınıfın genişlettiği (hesap türleri vb.) Soyut bir sınıf Hesabınız olduğunu varsayalım. Yalnızca bu tür grup için geçerli olan belirli bir yöntem kümesi vardır. Bununla birlikte, bu hesap alt sınıflarının bazıları, bu API'ları kullanmayı bekleyen denetleyicilere atılabilmeleri için Sürümlenebilir veya Düzenlenebilir veya Düzenlenebilir özelliklerini uygular. Denetleyici ne tür bir nesne olduğunu umursamıyor

Buna karşılık, Hesaptan genişlemeyen bir nesne oluşturabilir, bir Kullanıcı soyut sınıfı söyleyebilir ve yine de burada Mantıklı ve Düzenlenebilir, ancak Sürümlenebilir olmayan bir nesne uygulayabilirim.

Bu şekilde, FooUser alt sınıfının bir hesap DEĞİL olduğunu, ancak Düzenlenebilir bir nesne gibi davrantığını söylüyorum. Aynı şekilde BarAccount, Hesaptan genişler, ancak bir Kullanıcı alt sınıfı değildir, ancak Düzenlenebilir, Düzenlenebilir ve Sürümlendirilebilir de uygular.

Düzenlenebilir, Düzenlenebilir ve Sürdürülebilir için bu API'lerin tümünü soyut sınıflara eklemek sadece karmaşık ve çirkin olmakla kalmaz, aynı zamanda Hesap ve Kullanıcı'daki ortak arayüzleri çoğaltır veya Kullanıcı nesnesini muhtemelen sadece bir istisna.


İşte tam burada. Geliştirme veya yöntemlerinizin üzerine yazmadan yöntemlerinizi kullanmak için geliştiricileri sıkı bir şekilde zorlayın
Nick

21

Arayüzler, oluşturabileceğiniz şeyler için bir taslak niteliğindedir. Bir sınıfın hangi yöntemlere sahip olması gerektiğini tanımlarlar , ancak bu sınırlamaların dışında ek yöntemler oluşturabilirsiniz.

Çünkü sen-ebilmek yapmak yöntemleri - kod ekleyerek ne demek emin değilim. Arabirimi soyut bir sınıfa veya onu genişleten sınıfa mı uyguluyorsunuz?

Soyut sınıfa uygulanan arayüzde bir yöntemin o soyut sınıfa uygulanması gerekecektir. Ancak bu arabirimi genişletme sınıfına uygulayın ve yöntemin yalnızca genişletme sınıfında uygulanması gerekir. Burada yanlış olabilirim - arayüzleri olabildiğince / kullanmam gerektiği kadar kullanmıyorum.

Arabirimleri her zaman harici geliştiriciler için bir model veya şeylerin doğru olmasını sağlamak için ekstra bir kural kümesi olarak düşündüm.


9
PHP'de, arayüzler gerçek yöntemi değil, sadece yöntem bildirimini içerir. Ancak soyut sınıflar, onu genişleten sınıflar tarafından devralınacak yöntemlere "kod eklemenize" izin verir. Bu farkın mk'ın bahsettiği şey olduğuna inanıyorum.
nocash

13

PHP'de arayüzler kullanacaksınız:

  1. Uygulamayı gizlemek için - bir nesne sınıfına erişim protokolü oluşturun, bu nesneleri kullandığınız tüm yerlerde yeniden düzenleme yapmadan temel uygulamayı değiştirin
  2. Türü kontrol etmek için - bir parametrenin belirli bir türe sahip olduğundan emin olarak $object instanceof MyInterface
  3. Çalışma zamanında parametre kontrolünü zorunlu kılmak için
  4. Tek bir sınıfa birden çok davranış uygulamak (karmaşık türler oluşturmak)

    sınıf Araba EngineInterface, BodyInterface, SteeringInterface {

böylece bir Carnesne ca şimdi start(), stop()(EngineInterface) veya goRight(),goLeft() (Direksiyon arayüzü)

ve şu an düşünemediğim diğer şeyler

4 numara, muhtemelen soyut sınıflarla ele alamayacağınız en belirgin kullanım örneğidir.

Java'da Düşünmeden:

Bir arabirim, “Bu arabirimi uygulayan tüm sınıflar böyle görünecektir” diyor. Böylece, belirli bir arabirimi kullanan herhangi bir kod, o arabirim için hangi yöntemlerin çağrılabileceğini bilir ve hepsi bu. Dolayısıyla arayüz sınıflar arasında bir “protokol” oluşturmak için kullanılır.


10

Arayüzler, sınıfların genişletilebileceği bir temel olarak değil, gerekli işlevlerin bir haritası olarak mevcuttur.

Aşağıda, soyut bir sınıfın sığmadığı bir arabirim kullanımına bir örnek verilmiştir:
Kullanıcıların, takvim verilerini harici kaynaklardan içe aktarmasına olanak tanıyan bir takvim uygulamam olduğunu varsayalım. Ben her tür veri kaynağı (ical, rss, atom, json) alma işlemek için sınıflar yazmak istiyorum Bu sınıfların her biri hepsi benim uygulama veri almak için gereken ortak genel yöntemlere sahip olmasını sağlayacak ortak bir arabirim uygulamak.

<?php

interface ImportableFeed 
{
    public function getEvents();
}

Daha sonra bir kullanıcı yeni bir feed eklediğinde, bu feed'in türünü belirleyebilir ve verileri almak için bu tür için geliştirilen sınıfı kullanabilirim. Belirli bir feed için veri içe aktarmak için yazılan her sınıf tamamen farklı bir koda sahip olur, aksi takdirde sınıflarım arasında uygulamanızın bunları tüketmesine izin veren arabirimi uygulamak için gerekli olmaları dışında çok az benzerlik olabilir. Soyut bir sınıf kullanacak olsaydım, getEvents () yöntemini geçersiz kılmadığım gerçeğini kolayca görmezden gelebilirdim. arabirimde tanımlanan, onu uygulayan sınıfta mevcut değildir. Uygulamamın bir feed'den veri almak için hangi sınıfı kullandığını önemsemesi gerekmez,

Bunu bir adım daha ileri götürmek için, başka bir yayın türü eklemek amacıyla takvim uygulamama geri döndüğümde arayüz son derece yararlı oluyor. ImportableFeed arabirimini kullanmak, yalnızca bu arabirimi uygulayan yeni sınıflar ekleyerek farklı feed türlerini içe aktaran daha fazla sınıf eklemeye devam edebileceğim anlamına gelir. Bu, çekirdek uygulamama gereksiz yere toplu eklemeye gerek kalmadan tonlarca işlevsellik eklememe izin veriyor, çünkü çekirdek uygulamam yalnızca yeni yem içe aktarma sınıflarım ImportableFeed arayüzünü uyguladığı sürece arayüzün gerektirdiği genel yöntemler olmasına dayanıyor. biliyorum sadece yere bırakıp hareket etmeye devam edebilirim.

Bu sadece çok basit bir başlangıç. Daha sonra sınıfın işlediği feed türüne özgü daha fazla işlevsellik sunan tüm takvim sınıflarımın uygulanabileceği başka bir arabirim oluşturabilirim. Başka bir iyi örnek, feed türünü vb. Doğrulamak için bir yöntem olabilir.

Bu, sorunun ötesine geçmektedir, ancak yukarıdaki örneği kullandığımdan beri: Arayüzler, bu şekilde kullanıldığında kendi sorunları ile birlikte gelir. Kendimi arabirim eşleştirmek için uygulanan yöntemlerden döndürülen çıktı sağlamak ve bunu başarmak için gerekli bulmak PHPDoc blokları okuyan ve daha sonra olacak bir PHPDoc bloğunda bir tür ipucu olarak dönüş türü eklemek bir IDE kullanın onu uygulayan somut sınıfa çevirir. Bu arabirimi uygulayan sınıflardan veri çıktısını tüketen sınıflarım, en azından bu örnekte döndürülen bir dizi beklediğini bilecektir:

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

Soyut sınıfları ve arayüzleri karşılaştırmak için çok fazla yer yoktur. Arayüzler, uygulandığında sınıfın bir dizi genel arayüze sahip olmasını gerektiren haritalardır.


İyi açıklama :) Teşekkürler!
Razvan.432

Sadece bilgi eklemek için: Soyut sınıfta, yöntemi soyut olarak bildirirseniz, arayüz gibi davranır, böylece getEvents () 'i geçersiz kılmadığınız gerçeğini göz ardı edemezsiniz. Uygulama, arayüzde olduğu gibi başarısız olur.
Rikudou_Sennin

8

Arabirimler yalnızca geliştiricilerin belirli yöntemleri uyguladığından emin olmak için değildir. Fikir şu ki, bu sınıfların belirli yöntemlere sahip oldukları garanti edildiğinden, sınıfın gerçek türünü bilmeseniz bile bu yöntemleri kullanabilirsiniz. Misal:

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());

Birçok durumda, soyut ya da soyut bir temel sınıf sağlamak mantıklı değildir, çünkü uygulamalar çılgınca değişir ve birkaç yöntemin yanı sıra ortak bir şey paylaşmaz.

Dinamik olarak yazılmış diller, arayüzlere ihtiyaç duymadığınız "ördek yazma" kavramına sahiptir; nesnenin üzerinde çağırdığınız yönteme sahip olduğunu varsayabilirsiniz. Bu, nesnenizin bazı yöntemlere (örneğimde read ()) sahip olduğu, ancak arabirimi uygulamadığı statik olarak yazılan dillerde sorun etrafında çalışır.


6

Bence arayüzler fonksiyonel olmayan soyut sınıflara göre tercih edilmelidir. Orada bir performans çarpması olsa bile şaşırmam, çünkü iki parçayı ayrıştırmak, onları birleştirmek yerine somutlaştırılan tek bir nesne var (emin değilim, iç işlere aşina değilim) PHP OOP PHP).

Arayüzlerin, örneğin Java ile karşılaştırıldığında daha az yararlı / anlamlı olduğu doğrudur. Öte yandan PHP6, dönüş değerleri için tür ipucu da dahil olmak üzere daha fazla tür ipucu ekleyecektir. Bu, PHP arabirimlerine biraz değer katmalıdır.

tl; dr: arabirimleri, takip edilmesi gereken yöntemlerin bir listesini tanımlar (Think API), soyut bir sınıf ise alt sınıfların belirli ihtiyaçlara göre düzelttiği bazı temel / ortak işlevler verir.


PHP 6 asla yayınlanmayacak. PHP 6, 2005-2010 yılları arasında geliştirilmekte olan bir projeydi, ancak ertelendi ve sonuçta iptal edildi. PHP 7, çoğunlukla eski PHP 6 projesi ile karışıklığı önlemek için bir sonraki sürümdür.
Ashu Jha

5

PHP'nin bu açıdan farklı olup olmadığını hatırlayamıyorum, ancak Java'da birden çok Arayüz uygulayabilirsiniz, ancak birden fazla soyut sınıfı devralamazsınız. PHP'nin aynı şekilde çalıştığını varsayabilirim.

PHP'de birden çok arabirimi virgülle ayırarak uygulayabilirsiniz (Bence temiz bir solum bulamıyorum).

Çoklu soyut sınıflara gelince, birbirinizi uzatan birden fazla özete sahip olabilirsiniz (yine, bundan tam olarak emin değilim ama sanırım daha önce bir yerde gördüm). Genişletemeyeceğiniz tek şey bir final sınıfıdır.


4

Arabirimler kodunuza herhangi bir performans artışı veya bunun gibi bir şey vermez, ancak bunu sürdürülebilir hale getirmek için uzun bir yol kat edebilirler. Kodunuza bir arabirim oluşturmak için soyut bir sınıfın (hatta soyut olmayan bir sınıfın) kullanılabileceği doğrudur, ancak uygun arabirimlerin (anahtar sözcükle tanımladığınız ve yalnızca yöntem imzaları içeren) arayüzlerin kullanımı daha kolaydır. sıralayın ve okuyun.

Bununla birlikte, sınıf üzerinde bir arabirim kullanıp kullanmayacağınıza karar verirken takdir yetkisini kullanma eğilimindeyim. Bazen varsayılan yöntem uygulamaları veya tüm alt sınıflar için ortak olacak değişkenler istiyorum.

Tabii ki, çoklu arayüz uygulamasıyla ilgili nokta da sağlamdır. Birden çok arabirim uygulayan bir sınıfınız varsa, o sınıftaki bir nesneyi aynı uygulamada farklı türler olarak kullanabilirsiniz.

Sorunuzun PHP ile ilgili olması, işleri biraz daha ilginç hale getiriyor. Arayüzlere yazmak, türüne bakılmaksızın herhangi bir yönteme hemen hemen her şeyi besleyebileceğiniz PHP'de hala inanılmaz derecede gerekli değildir. Statik yöntem parametrelerini statik olarak yazabilirsiniz, ancak bazıları bozuk (String, bazı hıçkırıklara neden olduğuna inanıyorum). Bunu diğer referansların çoğunu yazamayacağınız gerçeğiyle birleştirin ve PHP'de statik yazmayı zorlamaya çalışmanın pek bir değeri yoktur ( bu noktada ). Ve bu nedenle, PHP'deki arayüzlerin değeri , bu noktadadaha güçlü yazılan dillerde olduğundan çok daha azdır. Okunabilirlik avantajına sahipler, ama çok az. Çoklu uygulama bile yararlı değildir, çünkü hala yöntemleri beyan etmeli ve uygulayıcı içindeki organları vermelisiniz.


2

PHP Arayüzü için puanlar

  1. Sınıfta gerekli yöntem sayısını tanımlamak için kullanılır [eğer html yüklemek istiyorsanız id ve isim gereklidir, bu durumda arayüz setID ve setName'i içerir].
  2. Arayüz sınıfı kesinlikle içinde tanımlanan tüm yöntemleri içermeye zorlar.
  3. Yöntemi yalnızca genel erişilebilirliğe sahip arayüzde tanımlayabilirsiniz.
  4. Sınıf gibi arayüzü de genişletebilirsiniz. Extends anahtar sözcüğünü kullanarak php arayüzünü genişletebilirsiniz.
  5. Çoklu arayüzü genişlet.
  6. Her ikisi de aynı ada sahip işlevi paylaşıyorsa 2 arabirim uygulayamazsınız. Hata verir.

Örnek kod:

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

Soyut sınıfların ve arayüzlerin çocuk sınıflarında uygulanması gereken soyut yöntemler sağlamaları bakımından benzer olduğunu gördük. Bununla birlikte, hala aşağıdaki farklara sahiptirler:

1.Interfaces soyut yöntemleri ve sabitleri içerebilir, ancak somut yöntemleri ve değişkenleri içeremez.

2. Arayüzdeki tüm yöntemler kamusal görünürlük kapsamında olmalıdır.

Bir sınıf birden fazla arabirim uygulayabilirken, yalnızca bir soyut sınıftan miras alabilir.

                                  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

Umarım bu irade anlamak için herkese yardımcı olur!


2

Arayüzler genleriniz gibidir.

Soyut dersler gerçek ebeveynleriniz gibidir.

Amaçları kalıtsaldır, ancak soyut sınıflar ve arabirimler karşısında, kalıtsal olan daha spesifiktir.


2

Diğer dilleri bilmiyorum, oradaki arayüz kavramı nedir. Ama PHP için, açıklamak için elimden geleni yapacağım. Sabırlı olun ve lütfen yardımcı olduysa yorum yapın.

Bir arabirim, bir dizi alt sınıfın ne yaptığını, ancak nasıl yaptığını belirten bir "sözleşmeler" olarak çalışır.

Kural

  1. Bir Arayüz somutlaştırılamaz.

  2. Bir arabirimde hiçbir yöntemi uygulayamazsınız, yani yalnızca yöntemin yalnızca. İmzasını içerir, ancak ayrıntıları (gövde) içermez.

  3. Arayüzler yöntemler ve / veya sabitler içerebilir, ancak nitelik içermez. Arabirim sabitleri, sınıf sabitleriyle aynı kısıtlamalara sahiptir. Arayüz yöntemleri dolaylı olarak soyuttur.

  4. Arabirimler, sınıf düzeyinde uygulama ayrıntıları olduğu için kurucuları veya yıkıcıları bildirmemelidir.

  5. Bir arabirimdeki tüm yöntemlerin herkese görünür olması gerekir.

Şimdi bir örnek verelim. İki oyuncağımız olduğunu varsayalım: biri Köpek, diğeri Kedi.

Bildiğimiz gibi bir köpek havlıyor ve kedi mews. Bu ikisi aynı konuşma yöntemine sahip, ancak farklı işlevsellik veya uygulama ile. Kullanıcıya konuş düğmesi olan bir uzaktan kumanda verdiğimizi varsayalım.

Kullanıcı konuş düğmesine bastığında, oyuncak Köpek ya da Kedi olup olmadığı önemli değildir.

Bu, uygulamalar farklı olduğu için soyut bir sınıf değil, bir arayüz kullanmak için iyi bir durumdur. Neden? Hatırlamak

Soyut olmayan bir yöntem ekleyerek alt sınıfları desteklemeniz gerekiyorsa, soyut sınıfları kullanmalısınız. Aksi takdirde, arayüzler sizin seçiminiz olacaktır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.