PhpStorm 9 проверка наследования классов работает

Question

неожиданных Я столкнулся следующие проблемы в PhpStorm 9:
Скажем, у меня есть интерфейс FieldInterface, который имеет некоторые методы:

namespace Acme; 

interface FieldInterface { 
    public function methodA(); 
    public function methodB(); 
} 

тогда у меня есть абстрактный класс, который реализует базовая функциональность интерфейса. Это абстрактный класс имеет возможность пользователю осуществлять определенные методы, скажем, это в нашем примере methodB:

namespace Acme; 

abstract class AbstractField implements FieldInterface { 
    public function methodA() { 
     // implement methodA 
    } 

    public abstract function methodB(); // have the user implement it 
} 

И, наконец, у меня есть некоторые готовые к использованию класса StringField:

namespace Acme; 

class StringField extends AbstractField { 
    public function methodB() { 
     // implement methodB 
    } 
} 

В этот момент все в хорошо. Но если я добавлю новый метод в FieldInterface, PHPStorm не скажет, что что-то не так с AbstractField, хотя очевидно, что я должен добавить public abstract function newMethod();. Однако вместо этого он указывает ошибку в классе StringField.
Можно понять, исходя из того, что абстрактные классы создаются с целью расширения, но обычно вы используете , чтобы расширить абстрактный класс, а не реализовать базовый интерфейс. Весь смысл создания абстрактного класса заключается в том, чтобы сохранить время пользователя для реализации интерфейса. Итак, почему PHPStorm заставляет меня реализовать интерфейс в конкретном классе, а не принуждать меня реализовать его в абстрактном классе, который явно реализует интерфейс.
Так что я задаюсь вопросом, является ли это ошибкой в ​​PHPStorm, или, возможно, это сделано специально. В любом случае, есть ли какое-либо обходное решение?

Answer 1

Вот как это должно быть, показывая ошибку в абстрактном классе было бы неправильно.

Фактически, public abstract function methodB(); является избыточным, потому что абстрактный класс уже «наследует» этот абстрактный метод от интерфейса, поскольку он его не реализует.

Единственным обходным решением является AbstractFieldне аннотация.