Есть ли какие-либо инструменты статического анализа, которые будут сообщать, насколько внимательно соблюдаются принципы SOLID?

Question

Я знаю, что слепо следовать любой «лучшей практике» все равно может привести к вонючей куче дерьма, которая строго придерживается лучшей практики. Принципы SOLID таковы, что принципов. Они не применяются ко всем ситуациям, но они все еще очень хорошие эвристики для поиска возможных улучшений в вашем коде.

Недостатком является то, что они когда-то требуют глубокого анализа исходного кода для их применения. Я, как и большинство программистов, постоянно наблюдает за более эффективными способами делать вещи, поэтому мне любопытно, слышал ли кто-нибудь об инструменте анализа, который пытается проверить применение принципов SOLID (или их отсутствие).

SRPЕдиный Ответственность Принцип

класс должен иметь только один повод для изменения.

OCPоткрытого Closed Принцип

Программные объекты (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации.

LSPЛисков принцип замещения

Подтипы должны быть взаимозаменяемыми для их базовых типов.

ISPИнтерфейс Сегрегация Принцип

Клиенты не должны быть вынуждены зависеть от методов, которые они не используют. Интерфейсы принадлежат клиентам, а не иерархам.

DIP Dependency Inversion Принцип

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций .

-из Agile принципы, шаблоны и практики

Answer 1

Я не думаю, что автоматический статический анализ может определить, если принципы соблюдаются. Чтобы написать такой инструмент, вам нужно будет формально определить, что означает каждое понятие, и иметь возможность проверить его на любой код. Как бы вы оформили понятие ответственности? Я лично понятия не имею.

Таким образом, у вас могут быть инструменты, которые помогут вам обнаружить вероятность нарушения. Например, вы можете использовать показатели кода, такие как количество методов для каждого класса, количество членов в классе, чтобы определить, является ли класс слишком большим и, следовательно, может нарушить SRP.

Исключением может быть Принцип замещения Лискова. IF Вы определяете контракты по всем методам (предварительные условия, постусловия, инварианты), тогда вы можете проверить, что метод, переопределяющий метод суперкласса, не укрепил предпосылки, не ослабляет постусловия и не учитывает инварианты метод суперкласса. Я думаю, что инструмент ESC/Java выполняет эти проверки. Чтение wikipedia page about LSP потребует дополнительных проверок.

Answer 2

Мой ответ включает в себя продукт, специфичный для .NET, извинения заблаговременно, и, возможно, кто-то может предложить его аналоги не.NET.

Я дал бы NDepend попробовать и посмотреть, если это может привести меня к нарушениям SRP и ISP, используя такие показатели, как:

• ряд методов по типам типа с
• аномально высоким числом методы
• афферентных/эфферентных муфта на сборочном и типа уровня
• другие показатели, full list of metrics here

Нарушения DIP и LSP могут быть сложнее отслеживать, поскольку они связаны с намерением программиста. Инструмент анализа может идентифицировать взаимосвязь между типами, но как он может сообщать ситуацию, когда один класс действительно расширяет другой из неправильного вывода Square из Rectangle? Или, что в правильно разработанной программе, A должен был зависеть от B, а не наоборот?

OCP представляет собой различную задачу, поскольку расширение/модификация, которые класс должен быть открыт/закрыт, необязательно уже имел место.

Однако, если мы считаем, что после SOLID приводит к более обслуживаемой продукта (доказать это утверждение с научной точки зрения это не то, что этот вопрос о), то абстрактность-Нестабильность график NDepend должен дать хороший совокупный меру того, насколько хорошо принципы выполнялись для каждого программного модуля. Если бы они были, модуль должен был избегать нижнего левого угла диаграммы, получившего название «Зона боли». В этой зоне модуль стабилен (не в хорошем смысле - слишком много других зависит от него, поэтому его трудно изменить), но недостаточно абстрактного.