Mengapa metode yang dilindungi tidak dapat disadap?

Saya bertanya-tanya mengapa tidak mungkin membuat plugin untuk protectedmetode. Ada bagian kode ini di 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;
}

Ia memeriksa apakah metode publicsebelum memungkinkannya dicegat. Hal ini dapat dengan mudah diubah dengan menciptakan preferencedalam di.xmlmodul sendiri, tentu saja, seperti ini:

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

dan menulis ulang _getClassMethodsdengan bagian dalam metode yang \ReflectionMethod::IS_PUBLICdiubah \ReflectionMethod::IS_PUBLIC | \ReflectionMethod::IS_PROTECTED.

Tapi saya bertanya-tanya mengapa tidak mungkin untuk mencegat metode yang dilindungi dalam definisi metode asli? Apakah itu berdampak besar pada kinerja, atau ada beberapa alasan lain untuk itu, seperti mengizinkan modul pihak ke-3 untuk membuat logika Magento terlalu "berantakan"?

Menurut Magento docs tidak mungkin menggunakan plugin pada metode yang dilindungi.

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

Anda tidak dapat menerapkan plugin ke:

• Metode terakhir
• Kelas akhir
• Setiap kelas yang mengandung setidaknya satu metode publik akhir
• Metode non-publik
• Metode kelas (seperti metode statis)
• __Konstruksi tipe virtual

Tetapi poin Anda benar, menurut ___callPluginsdefinisi dalam Magento\Framework\Interception\Interceptor, saya tidak melihat masalah menggunakan metode yang dilindungi.

Dugaan pertama saya adalah bahwa mereka membatasinya untuk menghindari kompleksitas kode yang tinggi karena Magento harus menulis ulang setiap metode yang dilindungi dan memanggil ___callPluginsmereka masing-masing ... itu akan sangat memperlambat IMHO.

Tapi saya pikir alasan sebenarnya adalah untuk konsistensi logis: plugin harus digunakan untuk mengubah metode kelas output / input , bukan untuk menulis ulang perilaku internal, jadi mereka hanya boleh mengakses metode publik.

Untuk menulis ulang perilaku internal Anda harus menggunakan preferensi. Masuk akal.

Jika saya ingat dengan benar dari presentasi Anton Krill, dia mengatakan bahwa metode yang dilindungi secara teknis dapat dicegat, tetapi itu mengalahkan tujuan agar mereka "dilindungi".
Kelas interceptor yang di-autogenerasi memperluas kelas aslinya sehingga memiliki akses ke metode yang dilindungi.
Tapi ... Metode yang dilindungi tidak boleh tersedia di luar kelas.
Jadi itu lebih merupakan keputusan daripada batasan.

Ini adalah fitur keamanan OOPS tidak khusus magento.

Metode publik, diberi label oleh publik tersedia untuk setiap kelas. Metode yang dilindungi, diberi label oleh protected tersedia untuk subclass dan kelas ramah, yang merupakan kelas dalam paket yang sama. Metode ramah, dilabeli dengan tidak ada (yaitu default) tersedia untuk kelas ramah. Metode pribadi hanya tersedia untuk kelas itu sendiri.

Alasan:

1) Metode yang dilindungi tidak dapat mengakses di tingkat kedua Warisan.

contoh: Mari kita ambil contoh dua kelas Kelas A & Kelas B dalam paket yang sama.

Kelas B hanya dapat dilindungi warisan serta metode umum kelas A.