Comments 63
Мне одному кажется что автор проектирует шиворот на выворот?
Согласен, сумбурно получилось. Хотя стремился идти от простому к сложному, и ничего не упустить.
В других найденных мной источниках ничуть не лучше. В лучшем случае это набор рекомендаций разработчику по пунктам. Или целая книга на полтыщщи страниц.
В других найденных мной источниках ничуть не лучше. В лучшем случае это набор рекомендаций разработчику по пунктам. Или целая книга на полтыщщи страниц.
Хотя стремился идти от простому к сложному, и ничего не упустить.
Нету у вас этого. У вас много говорится мы будем делать так и вот так, но нет самого главного ЗАЧЕМ?. Прежде чем что-то проектировать необходимо определиться с тем ЗАЧЕМ это надо. Затем с тем КАК оно будет это делать. Иначе будет получаться код ради кода.
Из того то стоит почитать это:
www.books.ru/shop/books/477847
www.books.ru/shop/books/156126
Нету у вас этого. У вас много говорится мы будем делать так и вот так, но нет самого главного ЗАЧЕМ?. Прежде чем что-то проектировать необходимо определиться с тем ЗАЧЕМ это надо. Затем с тем КАК оно будет это делать. Иначе будет получаться код ради кода.
Из того то стоит почитать это:
www.books.ru/shop/books/477847
www.books.ru/shop/books/156126
В начале статьи дается пример неудачной архитектуры, а дальше идет информация, как этого избежать и сделать лучше.
Вы не поняли. Когда вы делаете программу она должна решать какие-то задачи. И должно быть показано почему эти задачи не могут быть решены существующими сейчас программами. В противном случае ваша программа это код ради кода и не более того.
Хорошо, задача по добавлению нового функционала в проект за приемлемые человеко-часы.
Архитектура как таковая не решает прикладные задачи. Это всего лишь способ решения задач. Схема, которой нужно придерживаться.
Архитектура как таковая не решает прикладные задачи. Это всего лишь способ решения задач. Схема, которой нужно придерживаться.
Хорошо, задача по добавлению нового функционала в проект за приемлемые человеко-часы.
А причем тут тогда изменение архитектуры?
Архитектура как таковая не решает прикладные задачи. Это всего лишь способ решения задач.
Архитектура строится для решения прикладных задач. У вас наблюдается рефакторинг, а не новая архитектура.
А рефакторинг лучше изложен у того же Фаулера в книге «Рефакторинг». и что самое важное его методики подходят для больших проектов. И опять же прежде чем изменять надо выяснять надо ли. Иначе может получится что задача добавления нового функционала в проект, не упростилась, а усложнилась.
Рефакторинг упрощает код, но не исправляет ошибки проектирования. Например, по правилам рефакторинга нет нужды убирать код из обработчика нажатия кнопки.
В статье представлены некоторые ошибки проектирования (анти-паттерны) и варианты их замещения на эффективные шаблоны проектирования. А использование правил оформления кода нужно, чтобы заранее уменьшить негативное влияние человеческого фактора.
Рефакторинг рулит в больших проектах, когда все слишком сложно, а переделать узкие места очко играет — можно невзначай запороть весь проект в самое неподходящее время.
В статье представлены некоторые ошибки проектирования (анти-паттерны) и варианты их замещения на эффективные шаблоны проектирования. А использование правил оформления кода нужно, чтобы заранее уменьшить негативное влияние человеческого фактора.
Рефакторинг рулит в больших проектах, когда все слишком сложно, а переделать узкие места очко играет — можно невзначай запороть весь проект в самое неподходящее время.
Тормозить будет однозначно, организация в чем то напоминает qutIM 0.2, там тоже была система событий, по сути дела та же пересылка сообщений и подписка на события. Но увы, это обычно ведёт к тормозам. Лучше уж не прямой вызов, а делать вызов через некую универсальную обёртку. Падение скорости ничтожно, а API становится по настоящему абстрактным. А систему сообщений и событий использовать только в тех местах, где это необходимо.
Вообще-то вся GUI-часть Qt, если не весь Qt, работает на системе сообщений/подписке.
Спасибо, кэп.
А теперь попробуйте на досуге сравнить время затраченное на прямой вызов со временем вызова через сигнал.
А теперь попробуйте на досуге сравнить время затраченное на прямой вызов со временем вызова через сигнал.
Так никто и не заставляет использовать сигналы/слоты на системах, где критично время ответа.
Там задержки в пару миллисекунд при очень частых вызовах — я как-то замерял, когда писал контроллер для одной железки :)
Ну, за минусом небольшой задержки за счет вывода текста в консоль.
Там задержки в пару миллисекунд при очень частых вызовах — я как-то замерял, когда писал контроллер для одной железки :)
Ну, за минусом небольшой задержки за счет вывода текста в консоль.
«Уже сейчас видно, что всё это будет глючить и тормозить» (с)
Грубо говоря правильное разделение на бэкенды и фронтэнды спасут отца русской демократии и позволят сэкономить киловатты электроэнергии.
select count(«должны»|«должна»|«должен»|«нужно»|«нужен») from text;
go;
> over 9000…
select count(«можно»|«может»|«могут») from text;
go;
> over 9000…
Архитектура — это не стиль кода и не отступы, не именование переменных. Очень порадовали: «использовать SQL тоже нужно через ядро». «Связи должны быть не прямые, а в виде дерева». «Можно просто создавать новые функции, похожие на старые».
Совершенно бесполезная статья — каша наизнанку. Это реферат старшеклассника?
У вас есть опыт промышленной разработки?
go;
> over 9000…
select count(«можно»|«может»|«могут») from text;
go;
> over 9000…
Архитектура — это не стиль кода и не отступы, не именование переменных. Очень порадовали: «использовать SQL тоже нужно через ядро». «Связи должны быть не прямые, а в виде дерева». «Можно просто создавать новые функции, похожие на старые».
Совершенно бесполезная статья — каша наизнанку. Это реферат старшеклассника?
У вас есть опыт промышленной разработки?
Согласен. Что-то напоминает фантазию некоторых товарищей, которые иногда приходят на собеседования и рассказывают насколько круто у них всё организованно, а при вопросе о паттернах теряют дар речи.
Начать можно с этого:
Если под Windows работаете — то качайте сразу StarUML. Я когда лет 9 назад узнал про UML, был сильно впечатлён, чего только на UML не разбирал ;) Сейчас почти ничего не рисую, но в голове схемы уже сами вырисовываются.
Превосходная книга. Еще хороша вот эта:
www.amazon.co.uk/Object-oriented-Software-Construction-Prentice-Hall-Resource/dp/0136291554
www.amazon.co.uk/Object-oriented-Software-Construction-Prentice-Hall-Resource/dp/0136291554
Ещё хорошая книга Макконелли «Совершенный код», Буч, приведённый выше; в своё время я очень протащился книгой — Луи Басс, Р. Кацман «Архитектура программного обеспечения на практике»; Александреску хорошие книги пишет. Стоит обратить своё внимание на GOF, но мне её тяжеловато читать было, возможно сейчас снова попробую.
Именование глобальных переменных и классов оказывает непосредственное влияние на архитектуру. Когда в проекте полсотни похожих имен, могут возникнуть проблемы.
Чем вас позабавили обрывки фраз, вырванные из контекста?
Опыт есть. Спрашивайте конкретней.
Чем вас позабавили обрывки фраз, вырванные из контекста?
Опыт есть. Спрашивайте конкретней.
Простите, но вот это у вас как соотносится с правильным именованием?
> integer ID;
> string Host;
> string Port;
> integer ID;
> string Host;
> string Port;
Давайте по пунктам, чтобы не было обидно (а то меня так всегда воспринимают, как будто я издеваюсь)
>>Именование глобальных переменных и классов оказывает непосредственное влияние
>>на архитектуру. Когда в проекте полсотни похожих имен, могут возникнуть проблемы.
Мне кажется, проблемы возникнут с чем-то другим, но явно не с архитектурой системы. Можете дать определение архитектуры приложения своими словами?
Позабавило же меня то, что вы обращаетесь к нам, как к людям, которые никогда не пробовали программировать. Вот, например: «новые функции, похожие на старые». Что значит «похожие»? А сильно похожие или нет, только первой половиной?
Вы про сигнатуру функций говорили? Так и пишите, тут поймут.
«Может-должен-должны-могут-надо»… Никто никому не должен, максимум — обязан, и то, потому что существует рациональная причина. У вас же в тексте — заповеди Моисея, практики в форме аксиом. Поймите, это бесполезно — оно все одно не запоминается. Про cargo cult слышали? Вот именно оно.
>>Именование глобальных переменных и классов оказывает непосредственное влияние
>>на архитектуру. Когда в проекте полсотни похожих имен, могут возникнуть проблемы.
Мне кажется, проблемы возникнут с чем-то другим, но явно не с архитектурой системы. Можете дать определение архитектуры приложения своими словами?
Позабавило же меня то, что вы обращаетесь к нам, как к людям, которые никогда не пробовали программировать. Вот, например: «новые функции, похожие на старые». Что значит «похожие»? А сильно похожие или нет, только первой половиной?
Вы про сигнатуру функций говорили? Так и пишите, тут поймут.
«Может-должен-должны-могут-надо»… Никто никому не должен, максимум — обязан, и то, потому что существует рациональная причина. У вас же в тексте — заповеди Моисея, практики в форме аксиом. Поймите, это бесполезно — оно все одно не запоминается. Про cargo cult слышали? Вот именно оно.
Мне кажется, проблемы возникнут с чем-то другим, но явно не с архитектурой системы. Можете дать определение архитектуры приложения своими словами?
ru.wikipedia.org/wiki/Архитектура_программного_обеспечения
А если совсем кратко — структура взаимосвязи компонентов системы.
Позабавило же меня то, что вы обращаетесь к нам, как к людям, которые никогда не пробовали программировать. Вот, например: «новые функции, похожие на старые». Что значит «похожие»?
Из Win32 API:
CreateWindowA()
CreateWindowW()
CreateWindowExA()
CreateWindowExW()
А по стилю написания — ну не пейсатель я, виноват.
Хм, ну если вы писали в вики, то вопросов нет, своими словами. Если же нет — незасчитано, это не ваши слова :)
>>структура взаимосвязи компонентов системы
Окэ. Вы одно определяете через другое, не давая определения другого. Риторические вопросы — что такое «структура»? Что такое «компоненты»? Почему в ваше определение не входит цель построения этих взаимосвязей и решаемая ими задача — такое ощущение, что они сами по себе, просто чтобы были.
Также по-вашему выходит, что внутренний состав компонент в архитектуру приложения не входит — связи входят, а устройство компонент — нет. А если в приложении нет компонент, или компонент — один, т.е. у него нет связей с другими — выходит, нет и архитектуры?
По поводу WinAPI не в ту степь — CreateWindowA и CreateWindowW названы так не потому, что это влияет на архитектуру (даже на озвученную «структуру взаимосвязи»)-- просто так удобнее подставлять при помощи макроса конкретное имя функции в зависимости от unicode/non-unicode окружения.
В общем, мой вам совет — попробуйте для себя найти краткое непротиворечивое определение архитектуры ПО — будет проще выразить мысль, узнаете много интересного.
>>структура взаимосвязи компонентов системы
Окэ. Вы одно определяете через другое, не давая определения другого. Риторические вопросы — что такое «структура»? Что такое «компоненты»? Почему в ваше определение не входит цель построения этих взаимосвязей и решаемая ими задача — такое ощущение, что они сами по себе, просто чтобы были.
Также по-вашему выходит, что внутренний состав компонент в архитектуру приложения не входит — связи входят, а устройство компонент — нет. А если в приложении нет компонент, или компонент — один, т.е. у него нет связей с другими — выходит, нет и архитектуры?
По поводу WinAPI не в ту степь — CreateWindowA и CreateWindowW названы так не потому, что это влияет на архитектуру (даже на озвученную «структуру взаимосвязи»)-- просто так удобнее подставлять при помощи макроса конкретное имя функции в зависимости от unicode/non-unicode окружения.
В общем, мой вам совет — попробуйте для себя найти краткое непротиворечивое определение архитектуры ПО — будет проще выразить мысль, узнаете много интересного.
> просто так удобнее подставлять при помощи макроса конкретное имя функции в зависимости от unicode/non-unicode окружения
А это разве хорошо? Почему бы не назвать функцию одинаково и в зависимости от режима во время сборки выбирать нужный вариант?
Или бывают случаи, когда используются оба варианта в неком одном модуле?
А это разве хорошо? Почему бы не назвать функцию одинаково и в зависимости от режима во время сборки выбирать нужный вариант?
Или бывают случаи, когда используются оба варианта в неком одном модуле?
Нет, это не очень хорошо.
Назвать одинаково не удалось, т.к. это было не единовременным решением, а эволюционным — Win-ядро сначала не было Unicode. Потом добавили Unicode, но чтобы а) не ломать совместимость пришлось городить весь этот огород.
Случаи использования — были в ранних версиях Win, когда ядро было не-юникодным, и при вызове API юникодные строки приходилось перекодировать в не-юникод и обратно. В настоящее время это атавизм, и все реализованно наоборот — ядро использует юникод, а перекодирование перед вызовом и после используется для не-юникодных строк. Т.е. функции с окончанием A на самом деле макросы, подставляющие аналоги с W. Но к счастью, для большинства задач вызов не-юникодного API — это ненужный атавизм
Назвать одинаково не удалось, т.к. это было не единовременным решением, а эволюционным — Win-ядро сначала не было Unicode. Потом добавили Unicode, но чтобы а) не ломать совместимость пришлось городить весь этот огород.
Случаи использования — были в ранних версиях Win, когда ядро было не-юникодным, и при вызове API юникодные строки приходилось перекодировать в не-юникод и обратно. В настоящее время это атавизм, и все реализованно наоборот — ядро использует юникод, а перекодирование перед вызовом и после используется для не-юникодных строк. Т.е. функции с окончанием A на самом деле макросы, подставляющие аналоги с W. Но к счастью, для большинства задач вызов не-юникодного API — это ненужный атавизм
Вы, наверное, заметили, что статья слишком маленькая для такой большой темы? Я старался слишком глубоко не копать, ограничиться ключевыми моментами.
По поводу раскрытия темы компонентов — согласен, надо было уделить этому внимание, разобрать структуру один компонент для примера. Постараюсь дополнить статью в ближайшее время.
По поводу WinAPI — вы же просили примеры «новые функции, похожие на старые» для совместимости. Как раз тот самый случай. Можно еще DirectDraw припомнить с его «вторыми» версиями функций.
По поводу раскрытия темы компонентов — согласен, надо было уделить этому внимание, разобрать структуру один компонент для примера. Постараюсь дополнить статью в ближайшее время.
По поводу WinAPI — вы же просили примеры «новые функции, похожие на старые» для совместимости. Как раз тот самый случай. Можно еще DirectDraw припомнить с его «вторыми» версиями функций.
winAPI вообще можно рассматривать пример того, как НЕ НУЖНО ДЕЛАТЬ!!!
Видимо пространства имён вы таки не используете…
я так понимаю по ссылке из вашего профиля все эти научные изыскания нашли свою реализацию на irchat.ru/? х))
а вообще статья напоминает отрывок из курсача или чего-то подобного…
а вообще статья напоминает отрывок из курсача или чего-то подобного…
Совершенно верно.
Make me unsee it. Вам понятие юзабилити знакомо? Диалоги выбора смайлов и попапы просто чудовищны
Вы по скриншотам судите? Они сильно устарели, все забываю их обновить.
Обновите, а то у меня сейчас просто нет возможности прогу вживую проверить, из Линукса пишу.
Тут немного относительно свежих скриншотов (но со старыми иконками и без ClearType):
irchat.ru/forums.php?m=posts&q=64
irchat.ru/forums.php?m=posts&q=64
тоже самое можно почитать в любой книжке где рассматривается архитектура микроядерных ОС.
Думаю там лучше :))
Пример архитектуры из статьи является частным случаем шаблона Модель-Представление-Поведение. А почему вы спрашиваете?
По поводу стиля примеров — «ибо цель его не дать готовый код, а показать идею».
По древообразности взаимосвязей есть возражения? Возможно, я не прав. Подскажите, как оно должно быть и почему.
Про передачу параметров в виде командной строки и про конфиг — как-нибудь напишу. Не думал, что это интересная тема.
По поводу стиля примеров — «ибо цель его не дать готовый код, а показать идею».
По древообразности взаимосвязей есть возражения? Возможно, я не прав. Подскажите, как оно должно быть и почему.
Про передачу параметров в виде командной строки и про конфиг — как-нибудь напишу. Не думал, что это интересная тема.
Очередь сообщений не очень удобна в том плане, что приходится писать лишний код для сериализации / десериализации и обработку сообщений. Сейчас модно для тех же целей использовать позднее связывание — те же сигналы и слоты, как было написано выше.
Очередь команд проще для понимания и реализации (и отладки), поэтому лучше подходит для примера. Да и на практике не тормозит, если масштаб не велик.
Статья мне не понравилась, но не минусовал.
Возможо выше описали, но объясню со своей колокольни:
1. Автор использовал какую-то описательную нотацию, которую довольно сложно понимать, даже учитывая использование разных цветов — не наглядно.
2. Начали за здравие..., к середине статьи материал излагается сумбурно — я не понял основную мысль которую до меня хотят донести.
3. Автор утверждает что использует «псевдо-язык», которым и не «пахнет». Хороший пример псевдо-языка есть в книге «Совершенный код».
4. Дело вкуса, но конечный вариант архитектуры мне не понравился, никак не понравился. Лучше конечно чем первый от «Васи Пупкина», но всё равно довольно лажовый.
Возможо выше описали, но объясню со своей колокольни:
1. Автор использовал какую-то описательную нотацию, которую довольно сложно понимать, даже учитывая использование разных цветов — не наглядно.
2. Начали за здравие..., к середине статьи материал излагается сумбурно — я не понял основную мысль которую до меня хотят донести.
3. Автор утверждает что использует «псевдо-язык», которым и не «пахнет». Хороший пример псевдо-языка есть в книге «Совершенный код».
4. Дело вкуса, но конечный вариант архитектуры мне не понравился, никак не понравился. Лучше конечно чем первый от «Васи Пупкина», но всё равно довольно лажовый.
Sign up to leave a comment.
Архитектура программы на примере коммуникатора