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

Я знаю, что слепое следование любой "лучшей практике" может все еще привести к зловонной груде дерьма, которое строго придерживается лучшей практики. ТВЕРДЫЕ принципы - просто это, принципы. Они не относятся к каждой ситуации, но они - все еще очень хорошая эвристика для нахождения возможных улучшений Вашего кода.

Оборотная сторона им - то, что они иногда требуют, чтобы глубокий анализ Вашего исходного кода применил их. Я, как большинство программистов, постоянно в поисках более эффективных способов сделать вещи. Так, мне любопытно, если кто-либо услышал об аналитическом инструменте, который пытается протестировать на приложение ТВЕРДЫХ принципов (или отсутствие этого).

SRP единственный принцип ответственности

Класс должен иметь только одну причину измениться.

OCP открыто закрытый принцип

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

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

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

ISP интерфейсный принцип сегрегации

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

DIP принцип инверсии зависимости

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

- От гибких принципов, шаблонов и методов Robert C. Martin.

7
задан Trevor Reid 20 November 2019 в 20:46
поделиться

2 ответа

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

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

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

8
ответ дан 6 December 2019 в 21:16
поделиться

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

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

  • количество методов на типы типов с
  • аномально большим количеством методов;
  • афферентное / эфферентное сцепление в сборке и уровень типа
  • другие показатели, полный список показателей здесь

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

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

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

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

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

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

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

4
ответ дан 6 December 2019 в 21:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: