Есть ли какие-либо инструменты статического анализа, которые сообщат, как тесно ТВЕРДЫЕ принципы сопровождаются?
Существуют некоторые хорошие ресурсы для того, чтобы расти на crypto. Вот тот:
От той страницы:
В обычно используемой системе криптографии с открытым ключом, изобретенной Ron Rivest, Adi Shamir и Len Adleman в 1977, и общественность и закрытые ключи получены из пары больших простых чисел согласно относительно простой математической формуле. В теории могло бы быть возможно получить закрытый ключ из открытого ключа путем работы формулы назад. Но только продукт больших простых чисел общедоступен, и числа факторинга того размера в начала так твердо, что даже самые мощные суперкомпьютеры в мировом наклоне повреждают обычный открытый ключ.
книга Bruce Schneier Прикладная Криптография является другим. Я настоятельно рекомендую ту книгу; это - забавное чтение.
2 ответа
Я не думаю, что автоматический статический анализ может определить, соблюдаются ли принципы. Чтобы написать такой инструмент, вам нужно формально определить, что означает каждая концепция, и иметь способ проверить это на соответствие любому коду. Как бы вы формализовали понятие ответственности? Лично я понятия не имею.
Тем не менее, у вас могут быть инструменты, которые помогут вам определить вероятность нарушения. Например, вы можете использовать метрики кода, такие как количество методов в классе, количество членов в классе, чтобы определить, является ли класс слишком большим и, следовательно, может нарушать SRP.
Исключением может быть принцип замещения Лискова. ЕСЛИ вы определяете контракты для всех методов (предварительные условия, постусловия, инварианты), тогда вы можете проверить, что метод, переопределяющий метод суперкласса, не усиливает предусловие, не ослабляет постусловие и уважает инварианты метода суперкласса. Я думаю, что инструмент ESC / Java выполняет эти проверки. Прочитав страницу википедии о LSP , необходимо будет выполнить дополнительные проверки.
Мой ответ касается продукта, специфичного для .NET, заранее приношу извинения и, возможно, кто-то может предложить его аналоги, не относящиеся к .NET.
Я бы дал NDepend попробуйте и посмотрите, может ли это привести меня к нарушениям SRP и ISP, используя такие показатели, как:
- количество методов на типы типов с
- аномально большим количеством методов;
- афферентное / эфферентное сцепление в сборке и уровень типа
- другие показатели, полный список показателей здесь
Нарушения DIP и LSP может быть труднее отследить, поскольку они связаны с намерениями программиста. Инструмент анализа может идентифицировать отношения между типами, но как он может отличить ситуацию, когда один класс действительно расширяет другой, от того, что Square неправильно унаследована от Rectangle? Или, что в правильно разработанной программе, A должен был зависеть от B, а не наоборот?
OCP представляет другую проблему, потому что расширение / модификация, для которой класс должен быть открыт / закрыт, может не обязательно уже иметь место.
Однако, если мы полагают, что следование SOLID ведет к более удобному в обслуживании продукту (доказательство этого утверждения с научной точки зрения не является тем, о чем идет речь), тогда диаграмма абстрактности-нестабильности NDepend должна дать хороший агрегированный показатель того, насколько хорошо соблюдались принципы каждый программный модуль. Если бы это было так, то модуль должен был бы избегать нижнего левого угла диаграммы, получившего название «Зона боли». В этой зоне модуль стабилен (не в хорошем смысле - от него зависит слишком много других, поэтому его сложно изменить), но недостаточно абстрактно.
если мы считаем, что следование SOLID ведет к более удобному в обслуживании продукту (доказательство этого утверждения с научной точки зрения не является тем, о чем идет речь), тогда диаграмма абстрактности-нестабильности NDepend должна дать хороший агрегированный показатель того, насколько хорошо принципы были для каждого программного модуля. Если бы это было так, то модуль должен был бы избегать нижнего левого угла диаграммы, получившего название «Зона боли». В этой зоне модуль стабилен (не в хорошем смысле - от него зависит слишком много других, поэтому его сложно изменить), но недостаточно абстрактно. если мы считаем, что следование SOLID ведет к более удобному в обслуживании продукту (доказательство этого утверждения с научной точки зрения не является тем, о чем идет речь), тогда диаграмма абстрактности-нестабильности NDepend должна дать хороший агрегированный показатель того, насколько хорошо принципы были для каждого программного модуля. Если бы это было так, то модуль должен был бы избегать нижнего левого угла диаграммы, получившего название «Зона боли». В этой зоне модуль стабилен (не в хорошем смысле - от него зависит слишком много других, поэтому его сложно изменить), но недостаточно абстрактно. ■ Диаграмма абстрактности-нестабильности должна дать хороший агрегированный показатель того, насколько хорошо соблюдались принципы для каждого программного модуля. Если бы это было так, то модуль должен был бы избегать нижнего левого угла диаграммы, получившего название «Зона боли». В этой зоне модуль стабилен (не в хорошем смысле - от него зависит слишком много других, поэтому его сложно изменить), но недостаточно абстрактно. ■ Диаграмма абстрактности-нестабильности должна дать хороший агрегированный показатель того, насколько хорошо соблюдались принципы для каждого программного модуля. Если бы это было так, модуль должен был бы избегать нижнего левого угла диаграммы, получившего название «Зона боли». В этой зоне модуль стабилен (не в хорошем смысле - от него зависит слишком много других, поэтому его сложно изменить), но недостаточно абстрактно.