Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 [3]  Все   Вниз
  Печать  
Автор Тема: Современный дизайн С++  (Прочитано 50025 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #60 : 07-12-2009 17:16 » 

По-моему, ни хорошо и ни плохо, а просто так есть Улыбаюсь

Когда речь заходит об идеальной архитектуре, хорошо бы как-то обозначить критерии идеальности, что неминуемо поставит вопрос о целях проектирования...

Инкапсуляция мне не кажется самоцелью и абсолютным благом. Тут как с червями...

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

Когда проектировщик ставит инкапсуляцию самоцелью архитектуры, у него может даже получиться приближенное к идеалу решение, но ценой его будет заниженный предел по сложности организации проектируемой системы и большие общесистемные ограничения. Инкапсуляция, конечно, как раз и понижает сложность, чтобы всё уместилось в уме архитектора... Однако выйдет "червяк" - тормозная система, которая медленно и нудно гоняет из конца в конец разные данные, "синхронизируя" свои автономные и одинаково безликие части. Эти части друг другу не столько помогают в решении общесистемных задач, сколько конкурируют за ресурсы и заставляют друг друга обзаводиться разными приспособительными механизмами для взаимодействия между собой. Появляются всякие трёхэтажные wrapper'ы, неожиданные ошибки из-за дырявых абстракций и т.п. И выходит чудовище, которое разрастается, как плесень, и засасывает как болото. В конце концов выясняется, что ради повышения производительности и снижения стоимости сопровождения лучше всё выбросить и начать заново.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #61 : 07-12-2009 18:29 » 

Dimka, на тему архитектуры написана тьма книг, в их пересказе смысла не вижу.

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

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

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

Враппер есть хорошо, да это повышает накладные расходы, но при таком подходе каждый модуль изолирован от всех других и теоретически не зависим даже интерфейсно, более того враппер позволяет проводить тестирование каждого модуля в отдельности. Стандартный пример модуль шифрования для которого пишутся 2 затычки: одна "слева" подает на вход случайные или наперед известные данные и читает из выхода после чего сравнивает (если одинаковые, то все волшебно), вторая "справа" - получает зашифрованные данные с выхода и запихивает их на вход.

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

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

С уважением Lapulya
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #62 : 08-12-2009 04:12 » 

Цитата
При этом надо понимать, что статический "полиморфизм" никак не сможет заменить динамический полиморфизм, а вот обратный ворэрраунд без шаблонов возможен (в самом грубом приближении это ручная реализация каждого инстацирования, да отстой, НО можно и без потери безопасности, но с потерей гибкости).
это на себе испытал )) Серьёзно программирую около 5 лет, но шаблонами начал пользоваться совсем недавно. Иногда, признаю, удобно их применять. Но старенькая VS6 иногда была против, ругалась на длинные внутренние имена и вообще зависала, отказываясь порой понимать, что от неё хотят. Студия №9 вроде адекватно себя ведёт (у  неё другие закидоны)
Записан

Страниц: 1 2 [3]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines