Neden PHP 5.2 + soyut statik sınıf yöntemleri vermemek nedir?

5 Cevap php

PHP 5.2 sıkı uyarıları etkinleştirdikten sonra, başlangıçta sıkı bir uyarı olmadan yazılmış bir proje sıkı standartlar uyarıları bir yük gördüm:

Strict Standards, Static function Program getSelectSQL :: () should not be abstract Program.class.inc bölgesindeki

Söz konusu fonksiyon soyut bir üst sınıf Programı aittir ve bu tür TvProgram olarak çocuk sınıflarında uygulanması gerektiğini, çünkü soyut statik ilan edilir.

Bu değişikliğe başvurular buldun here:

Soyut statik sınıf fonksiyonları düştü. Nedeniyle sınıflarında soyut statik fonksiyonları izin verilen bir gözetim, PHP 5.0.x ve 5.1.x için. PHP 5.2.x itibariyle, sadece arayüzleri onları olabilir.

Benim soru: Birisi PHP bir soyut statik işlev olmamalıdır neden net bir şekilde açıklayabilir?

5 Cevap

Statik yöntemler onları beyan sınıfına aittir. Sınıf uzanan zaman, aynı adı statik bir yöntem oluşturabilir, ancak statik bir soyut yöntemi uygulayan aslında değildir.

Aynı statik yöntemleri ile herhangi bir sınıfını genişleten için de geçerli. Eğer bu sınıfı genişletir ve aynı imza statik bir yöntem oluşturmak, aslında süper sınıfın statik yöntemi geçersiz değil

EDIT (Sept. 16th, 2009)
Update on this. Running PHP 5.3, I see abstract static is back, for good or ill. (see http://php.net/lsb for more info)

CORRECTION (by philfreo)
abstract static is still not allowed in PHP 5.3, LSB is related but different.

PHP'nin 'Late Statik Bağlama' konuları içine bakmak. Soyut sınıflar statik yöntemler koyarak yapıyorsanız, muhtemelen er yerine daha sonra içine çalıştırmak için gidiyoruz. Bu sıkı uyarılar kırık dil özelliklerini kullanmaktan kaçınmak için söylüyorum ki mantıklı.

Aslında görünümünde bir tasarım açısından mantıklı bu konuda etrafında çok basit bir iş var. Jonathan yazdığı gibi:

Aynı statik yöntemleri ile herhangi bir sınıfını genişleten için de geçerli. Eğer bu sınıfı genişletir ve aynı imza statik bir yöntem oluşturmak, aslında süper sınıfın statik yöntemi geçersiz değil

Yani, senin etrafında bir iş olarak bunu yapabilirsiniz:

<?php
abstract class MyFoo implements iMyFoo {

    public static final function factory($type, $someData) {
        // don't forget checking and do whatever else you would
        // like to do inside a factory method
        $class = get_called_class()."_".$type;
        $inst = $class::getInstance($someData);
        return $inst;
    }
}


interface iMyFoo {
    static function factory($type, $someData);
    static function getInstance();
    function getSomeData();
}
?>

Ve şimdi herhangi bir sınıf sınıflara MyFoo bir getInstance statik bir yöntem ve bir kamu getSomeData yöntemi uygulayan zorlamak. Eğer MyFoo alt sınıf yoksa Ve, yine benzer işlevlere sahip bir sınıf oluşturmak için iMyFoo uygulayabilirsiniz.

Ben soyut bir sınıf / arayüzü programcılar arasında bir sözleşme olarak görülebilir olduğunu iddia ediyorum. Bu işler nasıl görünmelidir / gerçek işlevini uygulamak gibi davranır ve ile değil daha çok ilgilenir. Php5.0 ve 5.1.x de görüldüğü gibi bunu yapmaktan php geliştiricileri önleyen doğal bir kanun değil, ama dürtü diğer dillerde diğer OO tasarım desenleri ile birlikte gitmek için. Biri zaten diğer dillerde aşina ise temelde bu fikirler, beklenmeyen davranışları önlemeye çalışın.

Ben bu eski olduğunu biliyorum ama ....

Eğer durum neden olur bunu geçersiz yoksa Neden sadece bir istisna olduğunu, ana sınıfının statik yöntem, bu şekilde atmak değil.

etiketler