Принципы и компиляция С.О.Л.И.Д.

Например, в отношении принципа Single Responsibility:

Расскажите о классе Radio:

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

следовательно, мы имеем:

Все отлично.

Но я всегда вижу такие предложения:

Итак, теперь, когда нам нужно изменить, весь код в зависимости от сломанный компонент dont даже нужно перекомпилировать.

Подождите минуту!

Если мне нужно изменить класс VolumeManager - мне не придется перекомпилировать Radio и StationManager. Но Мне нужно остановить (в Интернете) iis, чтобы приложение могло использовать новую DLL, и это приведет к отключению приложения.

Кроме того, в console мне придется завершить всю программу, чтобы изменить dll, так как она заблокирована процессом (вы не можете изменить dll при запуске приложения - файл заблокирован)

даже когда я буду использовать GAC - мне придется остановить прорам, чтобы chagne dll.

так что это меня спасает? компиляция просто - щелкните правой кнопкой мыши и создайте. thats all

Я не вижу смысла упоминать: "вам нужно будет скомпилировать только сломанный класс.."

Что мне не хватает?

http://www.gontu.org/solid-single-responsibility-principle/ искать слово "build"

http://epic.tesio.it/doc/manual/solid_principles.html искать слово "recompiled"

http://www.dananhudson.com/?tag=solid искать слово "recompile"

Ответ 1

Бывают ситуации, когда "политически" проще развертывать обновление существующего приложения, если вы можете показать, что изменения ограничены в области видимости: если, например, нужно обновлять только одну DLL. (обратите внимание, что это не означает, что каждый класс должен быть в своей собственной DLL. Но, скорее всего, не все ваши классы находятся в одной DLL)

Однако другое преимущество более концептуально: если мне не нужно перекомпилировать DLL, то я точно знаю, что я ничего не сломал в нем. Чем меньше кода нужно коснуться, тем меньше вероятность того, что я добавлю ошибку.

Ответ 2

Забудьте время компиляции, перезапустите перезапуск приложения.

SOLID - это чистый код и ремонтопригодность. Это не о чем-то во время выполнения, это о том, что код становится все сложнее с течением времени и его трудно поддерживать, и именно здесь реальная стоимость.

Ответ 3

Время компиляции не является проблемой на С# по сравнению с С++. Большой проект на С++ может потребовать времени для компиляции. Это становится очень неприятно, когда вы пытаетесь внести изменения в одну область, вызывает перекомпиляцию несвязанных компонентов. Руководство по единой ответственности в отношении более компактных зависимостей таким образом улучшает проблему компиляции.

Ответ 4

Я очень рекомендую дяди Бобу чистые кодировщики по принципам SOLID.

Основной идеей независимой развертываемости является то, что модули, которые могут быть независимо развернуты, также могут быть независимо развиты. Обычно вы не разворачиваете модули самостоятельно, но извлекаете выгоду из возможности самостоятельно их разрабатывать.

В связи с последствиями для процесса компиляции это, вероятно, актуально в С++, где каждый блок компиляции (файл cpp) необходимо будет перекомпилировать, когда код зависит от изменений и где тщательно сконфигурированный график зависимостей, где изменение влияет только на один блок компиляции, может серьезно повлиять на время компиляции. В любом случае, если вы не работаете на более старом оборудовании, вы, вероятно, не должны делать время компиляции приоритетом.

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

Ответ 5

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

Потому что определенные изменения содержатся в ограниченной области вашего приложения. Это само по себе - в хорошо продуманной системе мне не нужно понимать полное приложение, чтобы изменить его поведение, и я думаю, что это важно.

Тот факт, что dlls заблокирован или IIS перезапускает затронутый App-пул (что он довольно хорошо скажет), являются техническими соображениями, которые могут быть смягчены в некоторой будущей системе.

В самом деле, с помощью теневого копирования и App-Domain hokey-pokey вы можете написать программу, которую вам не нужно будет перезапускать при обмене DLL.

Ответ 6

Я думаю, что важно иметь в виду шаблоны дизайна - это гибкость. Если вы когда-то решили реализовать различные типы StationManager и VolumeManager, вам не придется менять код в вашем классе Radio. Единственное изменение будет наложено созданием класса Radio. Для этого вам все равно придется перезапустить приложение, но у вас не будет никакого кода спагетти в вашем классе с несколькими инструкциями if-else. Никакой код не изменится, вы просто добавите новый код для новых классов. Это также подчиняется другому важному принципу дизайна: принцип open/closed (O in SOLID): код должен быть открыт для расширения, но не для модификации. Несмотря на то, что вы следите за всеми хорошими методами проектирования, вам все равно придется перезапустить приложение, чтобы изменения произошли.

Ответ 7

На самом деле аргументы, связанные с процессом компиляции и сборки, не очень важны для платформы .NET. Но это может быть очень важно для некоторых других платформ и/или языков.

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

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