Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Говорят что хорошая вещь: Large Scale C++ Software но я сам не читал, усиленно ищу
А вообще, смотри в чём проблемы, если в синтаксисе то почитай сначала Страуструпов всяких, Майерсов, Саттеров... Если в самой парадигме то тут тебе может помочь Буч, GoF.
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
Эта книга помимо всего прочего обсуждает реализацию design patterns на C++. Поэтому для начала тебе неплохо было бы ознакомиться с самими паттернами. Возьми книгу "Design Patterns".
А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Книг много. Всё зависит, от того, что ты считаешь традиционным С/С++ программированием.
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень . А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))
Вначале так сказать микро-уровень — это сам язык и "правильное" его использование. Тут я считаю вот это классикой:
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится.
Собственно она позволяет понять насколько программист является грамотным инженером. Если книжка нравится и хочется немедленно всюду это дело применять -- то точно инженер плохой. Если уж с таким и сотрудничать, то очень внимательно контролировать чего он там напрограммировал. Точно ли не переусложнил?
2) Во-вторых, эта книжка мне нравится потому, что там очень хорошо и на примерах описано насколько плохо программировать таким образом
3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет
4) Ну и главное. В целом очень редко в программировании попадаются такие сложные задачи, что нужно то, что описано у Александреску скажем. Конечно теоретикам программирования на C++ реальные сложные практические случаи (скажем написаение графического редактора с каими-то хитрыми особенностями, или там системы распозанавания речи или ещё чего), а уж тем более какие-то простые и распространённые (скажем написание Web-интерфейса к какой-то БД) совсем уже не интересны. Потому что там уже трудно придумать что-то реально хорошее и нужное. А интересны либо какие-то извраты на почве синтаксиса, либо решение каких-то сверхсложных архитектурных задачь, в реальной жизни совсем не возникающих.
Но при этом не особо опытные инженеры этого всего не понимают и очень сильно переусложняют код.
Так что очень может быть, что стиот почитать вские умные книжки на эту тему, особенно про паттерны проектирования, но главная идея должна быть такая, что никогда не забывать точно ли это нужно для реально возникающих в твоей деятельности задач.
Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
Просто такие программы писать труднее и требуется более высокая квалификация. Но, ИМХО, стремиться надо к этому, а не к созданию мегасупержутких наворотов.
Хотя для эрудиции эти все нароботки просмотреть конечно стоит
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
И в большинстве случаев лучше на Java, а не на C++.
Здравствуйте, igna, Вы писали:
E>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.
I>И в большинстве случаев лучше на Java, а не на C++.
Ну в целом я согласен, хотя не согласен, что именно на Java
Обычно в каждой области есть какой-то подходящий язык или языки, которым и стоит пользоваться.
Другое дело, что если контора пишет всё на C++ и C#, то не стоит ради какой-то небольшой задачи заводить ещё и культуру разработки на Java, или там на дельфи. Но в целом подход верный
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр. А>>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
E>1) Мне нравится книжка Александреску (которая современное проектировнаие на C++). Но странною любовью нравится.
E>...
Зачастую есть такая тема. Иногда себя на этом ловлю. Но.
1. Александреску, по-моему, этого не делает, но Саттер вначале каждой книги пишет, что голова должна быть превыше всего, что всё о чём он пишет не должно заменять здравого смысла. Человек-разумный должен это понимать.
2. У каждого языка/инструмента/технологии есть своя область применимости. Это касается и того, о чём пишет Александреску, и языка с++ как такового, и Java, и ООП и БД. Вообще всего.
3. Чем шыре у специалиста кругозор, тем он может выбрать более вдекватное решение для конкретной задачи.
Т.ч. я считаю, что такой "наезд" на Современное проектирование не обоснован. Эти же мысли можно применить ко всему, он тут ни при чём.
Например, недавно мне надо было реализовать около 50 различных поведений (классов). Причём, если подумать, то каждый класс тз этого множество достаточно чётко разделяется на несколько аспектов. И существует по несколько реализаций каждого аспекта. Когда все эти реализации каждого аспекта перемножаются друг на друга и получается более 50 вариантов поведения. Как предлагаешь это реализовывать? При этом каждый аспект достаточно часто меняется независимо от других.
Или например фабрики. Недавно видел пару сотен строк кода для реализации обычной абструктной фабрики.
Здравствуйте, remark, Вы писали:
R>Зачастую есть такая тема. Иногда себя на этом ловлю. Но. R>1. Александреску, по-моему, этого не делает, но Саттер вначале каждой книги пишет, что голова должна быть превыше всего, что всё о чём он пишет не должно заменять здравого смысла. Человек-разумный должен это понимать.
R>Т.ч. я считаю, что такой "наезд" на Современное проектирование не обоснован. Эти же мысли можно применить ко всему, он тут ни при чём.
Ну тут форум инженеров-программистов. И стоит всех предостиречь от бездумного увлечения наворотами
Я собственно отвечал автору топика
А что касается примера с поведениями, то от чего бы поведение не задавать парой интерфейсов?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>А что касается примера с поведениями, то от чего бы поведение не задавать парой интерфейсов?
Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску.
Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
Здравствуйте, remark, Вы писали:
R>Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску. R>Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
Не, Александреску обычно пишет о навёрнутых конструкциях их шаблонов. А я написал о структуре из нескольких указателей на интерфейсы.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску. R>>Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.
E>Не, Александреску обычно пишет о навёрнутых конструкциях их шаблонов. А я написал о структуре из нескольких указателей на интерфейсы.
"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.
Здравствуйте, remark, Вы писали:
R>"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.
У шаблонов есть много "преимуществ"
1) Намного хуже, чем в случае интерфейсов заданы правила использования. В результате грамотный шаблон написать труднее (больше надо всегопредусмотреть), и воспользоваться труднее (надо выбрать из большего числа мыслемыз альтернативных способов использования)
2) Намного более сложный синтаксис и семантика. Вот, например, что тут написано:
template<typename TLog>
class Base {
protected
void exit( int );
};
template<typename TLog>
class MyExitProicessor : public Base<TLog> {
public:
void OnExit( TLog& log, int code )
{
LogExit( log, code ); // это какой-то метод MyExitProicessor, описанный ниже
exit( code );
}
};
3) Очень неудобные сообщения об ошибках в пользовательском коде.
А вот реальные приимущества всех этих трюков Александреску они в чём?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>Попались мне давеча книжки Александреску. Прочитав немного, понял,
Да, такие книжки прочищают мозги хорошо Ж)
Если сам вздумаешь писать тип трэйты, то ты не думай что если даже они будут работать, то всё будет пучком... Такие чтуки реально тормозят компиляцию, у меня к примеру каждый толстый cpp компилируется по 10 сек под P4-2400 на 2003 студии, вот так то. Поэтому написать действительно хорошие тип трейты стоит не малых усилий..
А что касается библиотеки Loki, то там не всё работает..
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Книжка Александреску хороша, нет слов, да только не всегда все это все в пользу. Если програмируешь в основном один и очень хорошо в этом сам разобрался то конечно, да... А если работаешь в большой разнородной команде с текучкой где не все С++ программисты про итераторы слышали, то применение изощренных приемов из этой книги может заметно мешать. Только "избранные" смогут этот код понимать даже в приципе а поддерживать все "это" придется самому. Если поручат исправить простую ошибку менее квалифицированному кадру то он запросто там таких дров наломает, что все равно потом к тебе прибегут за помощью, когда гром грянет. Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет. Видел я и проекты написанные на "обычном" C++ и исключительно advanced код, так вот те простые чаще были более удачные.
Другие отностительно новые книжки по "продвинутому" C++ — Exceptional C+, More Exceptional C+, Effective STL, C++ Templates: The Complete Guide, и еще может пара книжек то ACE
Здравствуйте, qqqqq, Вы писали:
Q><...>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет...
Если программист стал незамениным, его пора увольнять (с) не помню кто
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали: Q>><...>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет...
E>Если программист стал незамениным, его пора увольнять (с) не помню кто
Это теоретики... Ни разу не видел ничего подобного. Задача тимлида проследить за необходимостью "навороченности" кода и дизайна.
Erop пишет: > Q><...>Но если тайная цель все под себя подмять в такой разнородной команаде то да, надо напихать в программу побольше патернов, темплейтов из этой и других подобных книг, замешать с STL, Loki, boost и АСЕ, и еще написать описание соответствено — цены тебе не будет... > Если программист стал незамениным, его пора увольнять (с) не помню кто
Глупо.
Если ..., то пора увольнять ПМ'а , такое вот ИМХО.
Здравствуйте, Erop, Вы писали:
E>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog.
Это не Prolog. Это Lisp.
> Но совсем не раскрыл тему "зачем так извращаться?"
Ты не читал предисловие.
Imagine the following scenario. You come from a design meeting with a couple of printed diagrams, scribbled with your annotations. Okay, the event type passed between these objects is not char anymore; it's int. You change one line of code. The smart pointers to Widget are too slow; they should go unchecked. You change one line of code. The object factory needs to support the new Gadget class just added by another department. You change one line of code.
You have changed the design. Compile. Link. Done.
Well, there is something wrong with this scenario, isn't there? A much more likely scenario is this: You come from the meeting in a hurry because you have a pile of work to do. You fire a global search. You perform surgery on code. You add code. You introduce bugs. You remove the bugs . . . that's the way a programmer's job is, right? Although this book cannot possibly promise you the first scenario, it is nonetheless a resolute step in that direction. It tries to present C++ as a newly discovered language for software architects.
А вообще, книга описывает основные паттерны проектирования, которые нужно уже давно знать и использовать самому. Нельзя изучать паттерны по книге Александреску. Нужно прочитать Gang of Four и попробовать делать так как там написано. А потом, когда надоест писать горы однотипного кода и появиться желание как-то автоматизировать этот процесс, то тут приходят на помощь идеи Александреску.
Если ты не используешь паттерны. Александреску тебе ничего не даёт, а просто сотрясает воздух в пустую.
))
"Всё что не убивает нас, делает нас сильнее..."
