Принципы S. O. L. I. D и компиляция? [закрытый]
например, относительно принципа Single Responsibility:
Radio:
Radio имеет две обязанности, а именно управление объемом и станцией. Эти операции будут вызываться из совершенно разных областей клиента, использующего его.
Отсюда мы имеем следующее :
Все в порядке.
Но я всегда вижу такие предложения:Так что теперь, когда нам нужно изменить , весь код в зависимости от сломанный компонент даже не нужно перекомпилировать.
Подождите минутку !
Если мне нужно изменить класс VolumeManager - мне не придется перекомпилировать Radio и StationManager.
но мне придется остановить ( в web) iis, чтобы приложение использовало новую DLL, и это вызовет приложение вниз.
Также, в console, я должен буду завершите всю программу, чтобы изменить dll, так как она заблокирована процессом (вы не можете изменить dll, когда приложение работает - файл заблокирован)
Даже когда я буду использовать GAC-мне придется остановить proram для того, чтобы chagne dll.
Так что же меня спасает ? компиляция-это просто щелчок правой кнопкой мыши и сборка. вот и всеЯ не вижу смысла упоминать : " Вам нужно будет компилировать только сломанный класс.. "
Кто Я Такой? пропал ?
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"
7 ответов:
Бывают ситуации, когда" политически " проще развернуть обновление для существующего приложения, если вы можете показать, что изменения ограничены по объему: например, если требуется обновить только одну библиотеку DLL. (обратите внимание, что это не означает, что каждый класс должен быть в своей собственной DLL. Но скорее всего, не Все Ваши классы находятся в одной библиотеке DLL)
Однако, другое преимущество является более концептуальным : если мне не нужно перекомпилировать DLL, то я точно знаю, что я этого не делал сломайте в нем что-нибудь. Чем меньше кода нужно трогать, тем меньше шансов, что я введу ошибку.
Забудьте о времени компиляции, забудьте о перезапуске приложения.
SOLID - это чистый код и ремонтопригодность. Речь идет не о чем-то во время выполнения, а о том, что код становится все сложнее с течением времени и его трудно поддерживать, и именно в этом заключается реальная стоимость.
Время компиляции не является проблемой в C# по сравнению с C++. Компиляция большого проекта на языке C++ может занять годы. Это становится действительно разочаровывающим, когда попытка внести изменения в одной области вызывает перекомпиляцию несвязанных компонентов. Единая ответственность ведет к более компактным зависимостям, таким образом улучшая проблему компиляции.
Я очень рекомендую видео дяди Боба clean coders на твердых принципах.
Основная идея, лежащая в основе независимой развертываемости, заключается в том, что модули, которые могут быть независимо развернуты, также могут быть независимо разработаны. Обычно вы не развертываете модули самостоятельно, но вы выигрываете от возможности самостоятельно разрабатывать их.Что касается влияния на процесс компиляции, то это, вероятно, уместно в C++, где каждая единица компиляции ( cpp-файл ) необходимо будет перекомпилировать код, когда он зависит от изменений и где тщательно построенный график зависимостей, где изменение влияет только на одну единицу компиляции, может серьезно повлиять на время компиляции. В любом случае, если вы не работаете на более старом оборудовании, вы, вероятно, не должны делать время компиляции приоритетом.
О необходимости остановить приложение (веб или консоль ) при изменении и развертывании независимого модуля-этого можно избежать с помощью платформы плагинов, которая может динамически загружаться новые / измененные сборки в приложение-и твердые принципы могут быть применены к тому, как вы строите плагины и их интерфейсы. Имейте в виду, что это может добавить больше осложнений, и я бы рекомендовал избегать этого и просто перезапустить приложение при развертывании.
Я не думаю, что сохраненная компиляция-это то, что имеет значение, а почему вы могли бы уйти без нее.
Потому что определенное изменение содержится в ограниченной области вашего приложения. Это хорошо само по себе - в хорошо спроектированной системе мне не нужно понимать все приложение, чтобы изменить его поведение, и я думаю, что это имеет значение.
Тот факт, что библиотеки DLL заблокированы или IIS перезапускает затронутый пул приложений (что он делает довольно хорошо, я бы сказал) технические детали, которые могут быть смягчены в какой-то будущей системе.
Действительно, с некоторым теневым копированием и доменом приложений hokey-pokey вы можете написать программу,которую вам не нужно будет перезапускать при обмене dll.
Я думаю, что важно иметь в виду, когда речь заходит о шаблонах проектирования, гибкость. Если вы однажды решите реализовать различные типы StationManager и VolumeManager,вам не придется изменять код в своем классе Radio. Единственное изменение будет вызвано созданием экземпляра Радио класса. Для этого вам все равно придется перезапустить приложение, но в вашем классе не будет никакого спагетти-кода с несколькими операторами if-else. Код не изменится, вы просто добавите новый код для новых классов. Это также подчиняется другому важному принципу проектирования: принципу open/closed (O в твердом теле): код должен быть открыт для расширения, но не для модификации. Несмотря на то, что вы следуете всем правилам хорошего дизайна, вам все равно придется перезапустить приложение, чтобы изменения произошли
На самом деле аргументы, связанные с процессом компиляции и сборки, не очень важны для платформы .NET. Но это может быть очень важно для какой-то другой платформы или/и языков.
Например, в мире C++ это преимущество может привести к резкому повышению производительности командой разработчиков, потому что это сэкономит часов во время компиляции. В мире C++ использование Bridge Pattern илиPimpl идиомы может сэкономить много времени, потому что каждое изменение в заголовочном файле (даже в закрытой части) приведет для перекомпиляции всех зависимостей (прямых или косвенных). В этом случае построение или компиляция аспекта твердых принципов может быть действительно полезным.
Короче говоря: твердые принципы - это не процесс сборки или перекомпиляции, это все о зависимостях. Но если вы правильно управляете своими зависимостями, вы определенно выиграете и в этих областях (включая, но ограничивая процессы сборки и компиляции).