Korunan yöntemlere neden müdahale edilemiyor?

protectedYöntemler için neden eklenti oluşturmanın mümkün olmadığını merak ediyordum . Bu kod parçası Magento\Framework\Interception\Code\Generator\Interceptor:

protected function _getClassMethods()
{
    $methods = [$this->_getDefaultConstructorDefinition()];

    $reflectionClass = new \ReflectionClass($this->getSourceClassName());
    $publicMethods = $reflectionClass->getMethods(\ReflectionMethod::IS_PUBLIC);
    foreach ($publicMethods as $method) {
        if ($this->isInterceptedMethod($method)) {
            $methods[] = $this->_getMethodInfo($method);
        }
    }
    return $methods;
}

Yöntemin publicele geçirilmesine izin vermeden önce olup olmadığını kontrol eder . Elbette, kendi modülünün preferenceiçinde bir oluşturularak kolayca değiştirilebilir di.xml:

<?xml version="1.0"?>
<config>
    <preference for="Magento\Framework\Interception\Code\Generator\Interceptor" type="MyVendor\MyModule\Model\MyInterceptorModel" />
</config>

ve yöntemin içine değiştirilen _getClassMethodsile yeniden yazma .\ReflectionMethod::IS_PUBLIC\ReflectionMethod::IS_PUBLIC | \ReflectionMethod::IS_PROTECTED

Ama merak ediyorum neden orijinal yöntem tanımında korunan yöntemlere müdahale etmek mümkün değil? Performans üzerinde büyük bir etkisi var mı, yoksa bunun 3. parti modüllerinin Magento mantığını da "dağınık" hale getirmesine izin vermek gibi başka bir nedeni var mı?

Magento belgelerine göre korumalı bir yöntemde bir eklenti kullanmak "mümkün" değildir.

( http://devdocs.magento.com/guides/v2.0/extension-dev-guide/plugins.html )

Eklentileri uygulayamazsınız:

• Son yöntemler
• Final dersleri
• En az bir nihai genel yöntem içeren herhangi bir sınıf
• Herkese açık olmayan yöntemler
• Sınıf yöntemleri (statik yöntemler gibi)
• __construct Sanal türler

Ancak amacınız doğrudur, ___callPluginsiçindeki tanıma göre Magento\Framework\Interception\Interceptor, korumalı yöntemleri kullanırken herhangi bir sorun görmüyorum.

İlk tahminim, yüksek kod karmaşıklığından kaçınmak için sınırlandırdıklarıdır çünkü Magento herhangi bir korumalı yöntemi yeniden yazmalı ve ___callPluginsher birini çağırmalıdır ... IMHO'yu çok yavaşlatacaktır.

Ama bence asıl sebep mantıklı bir tutarlılıktır: eklentiler , iç davranışları yeniden yazmak için değil sınıf yöntemleri çıktı / girdi değiştirmek için kullanılmalıdır , bu yüzden sadece genel yöntemlere erişmelidirler .

Dahili davranışı yeniden yazmak için bir tercih kullanmanız gerekir. Mantıklı.

Anton Krill'in bir sunumundan doğru bir şekilde hatırlarsam, teknik olarak korunan yöntemlerin ele geçirilebileceğini, ancak bunların "korunma" amacını yendiğini söyledi.
Otomatik olarak oluşturulan yakalama sınıfı, orijinal sınıfı, korumalı yöntemlere erişebilmesi için genişletir.
Ancak ... Korumalı yöntemler sınıf dışında mevcut olmamalıdır.
Yani bu bir sınırlamadan çok bir karardır.

Macentaya özgü olmayan OOPS güvenlik özelliğidir.

Herkese açık olarak etiketlenen genel yöntemler her sınıfa açıktır. Korumalı olarak etiketlenen korumalı yöntemler, aynı paketteki sınıflar olan alt sınıflar ve dost sınıflar için kullanılabilir. Hiçbir şey tarafından etiketlenmeyen (yani varsayılan) dost yöntemler, dost sınıflar tarafından kullanılabilir. Özel yöntemler sadece sınıfın kendisi tarafından kullanılabilir.

Nedenleri:

1) Korumalı Yöntemler Miras ikinci düzeyine erişemez.

örnek: Aynı pakette iki sınıf A ve B Sınıfı örneğini ele alalım.

B Sınıfı, yalnızca miras korumalı olduğu kadar A sınıfı genel yöntemleri de kullanabilir.