Количество воображаемых проблем, которые инженер-программист может для себя создать, зависит от его воображения и сложности реальных проблем, которые нужно решить.
Возможно речь идёт ни столько об усложнении простых и скучных задач, сколько об желании инженера создать свой инструмент для решения текущей задачи, потому что имеющийся не подходит по многим его критериям правильного ПО.
Это ведь элементарно: когда инженеру не нравится архитектура библиотеки для работы с HTTP, он начинает писать библиотеку с хорошей архитектурой, при этом не забыв запихнуть туда всё, что по его мнению должно там быть, не смотря на то, что в текущем проекте это не будет использовано — библиотека ведь должна отвечать критериям правильного ПО...
Хотя да, со стороны это выглядит как усложнение простых и скучных задач...
Уважаемый sojuznik спасибо вам за развёрнутые пояснения!
> У вас, правильней назвать, не плагины, а модульный дизайн.
Ок, учту.
> слишком многословно, слишком расточительно и от std:: рябит в глазах.
Я часто пользую и boost, во избежании конфликтов и неоднозначности — всегда нэймспэйсы оставляю не раскрытыми. Как-то нормально на это смотрю.
> Как я понимаю, вы это писали, видимо, для резюме, чтобы показать свои знания модного C++. Ход может быть неплохом, чтобы найти работу. Но обычно в коммерческом программировании важно не знание самого модного, а умение писать просто и элегантно по принципу KISS.
Нет )) я не ищу работу ))
Опыт у меня не очень большой, но в коммерческом программировании, как мне кажется важнее быстро выдавать рабочий код, что и позволяет нам делать новый стандарт.
Тут порог вхождения чуть выше чем в обычных случаях (в мета программировании), но в итоге позволяет писать код лаконично и быстро.
У меня нет каких-то конкретных сейчас примеров (читал где-то), но современный компилятор компонующий код с новым стандартом выдаёт бинарник по скорости исполнения ни намного медленнее чем без, но взамен новый стандарт предоставляет гибкость и удобство.
Тут всегда будет За и Против…
> Простота обеспечивается как техническими решениями, так и простотой с точки зрения того, кто будет пользоваться вашим кодом. Обилие всевозможных фич C++ в вашем решении говорит об обратном. Это означает, что ваше решение завязано на эти фичи, что дает меньше гибкости для пользователей вашего кода.
Если фичи новые, это не значит что они сложные, сложность скрыта под капотом (стандарт в нашем случае).
Мой код завязан на эти фичи потому что они уже здесь, грядут, идут и используются (ну или готовы чтобы их использовали).
> Еще внимательней относитесь к именам. У вас я вижу get и get_plugin, has и другие слишком общие слова. Одинаковые и похожие имена, а также слишком общие названия могут затруднять чтение кода и усложнить понимание того, для чего они нужны.
Ок.
> По поводу шаблонов в API. Старайтесь применять шаблоны, только если они дают элегантное и простое решение технических задач. Использовать шаблоны для создания сахара может быть неудобным решением, поскольку параметры шаблона не очевидны для понимания пользователем кода, что именно туда передается и почему. Всякие <2>, ::_3 и прочее — это коряво и выглядит как хак. К сожалению, в стандартной библиотеке такого полно. Там это делалось для ухищрений. В своем коде ухищряться подобным образом — не лучшее решение для подражания.
<2> — Этот как раз имело своей задачей упростить взаимодействие с интерфейсом: означает количество аргументов для задачи, вычисляется в compile time.
::_3 — Используется только в примере, для биндинга члена функции передаваемой в плагин.
Для подражания может не лучшее, но так легко и удобно пользовать.
Я имел опыт пользовать <2> в классах для полей значений, которые по сути являлись динамическими, вот там да, был гемор. А тут у нас возможные значения от 0 до 6…
Как дополнительный навык, не выливающийся в задачу научиться писать поэмы, — - почему нет? Речь ведь идёт об описании того, с чем программист имеет дело…
Соглашусь с тем, что с опытом программист начинает искать
самые короткие пути достижения поставленных задач.
Больше времени уделяется составлению
дорожных карт,ну или проработке ТЗ если хотите...
Возможно речь идёт ни столько об усложнении простых и скучных задач, сколько об желании инженера создать свой инструмент для решения текущей задачи, потому что имеющийся не подходит по многим его критериям правильного ПО.
Это ведь элементарно: когда инженеру не нравится архитектура библиотеки для работы с HTTP, он начинает писать библиотеку с хорошей архитектурой, при этом не забыв запихнуть туда всё, что по его мнению должно там быть, не смотря на то, что в текущем проекте это не будет использовано — библиотека ведь должна отвечать критериям правильного ПО...
Хотя да, со стороны это выглядит как усложнение простых и скучных задач...
Выложьте код в паблик и киньте ссылку.
И мы тут все дружно поглядим, что у вас там такого "не ужасного" получилось ))
> У вас, правильней назвать, не плагины, а модульный дизайн.
Ок, учту.
> слишком многословно, слишком расточительно и от std:: рябит в глазах.
Я часто пользую и boost, во избежании конфликтов и неоднозначности — всегда нэймспэйсы оставляю не раскрытыми. Как-то нормально на это смотрю.
> Как я понимаю, вы это писали, видимо, для резюме, чтобы показать свои знания модного C++. Ход может быть неплохом, чтобы найти работу. Но обычно в коммерческом программировании важно не знание самого модного, а умение писать просто и элегантно по принципу KISS.
Нет )) я не ищу работу ))
Опыт у меня не очень большой, но в коммерческом программировании, как мне кажется важнее быстро выдавать рабочий код, что и позволяет нам делать новый стандарт.
Тут порог вхождения чуть выше чем в обычных случаях (в мета программировании), но в итоге позволяет писать код лаконично и быстро.
У меня нет каких-то конкретных сейчас примеров (читал где-то), но современный компилятор компонующий код с новым стандартом выдаёт бинарник по скорости исполнения ни намного медленнее чем без, но взамен новый стандарт предоставляет гибкость и удобство.
Тут всегда будет За и Против…
> Простота обеспечивается как техническими решениями, так и простотой с точки зрения того, кто будет пользоваться вашим кодом. Обилие всевозможных фич C++ в вашем решении говорит об обратном. Это означает, что ваше решение завязано на эти фичи, что дает меньше гибкости для пользователей вашего кода.
Если фичи новые, это не значит что они сложные, сложность скрыта под капотом (стандарт в нашем случае).
Мой код завязан на эти фичи потому что они уже здесь, грядут, идут и используются (ну или готовы чтобы их использовали).
> Еще внимательней относитесь к именам. У вас я вижу get и get_plugin, has и другие слишком общие слова. Одинаковые и похожие имена, а также слишком общие названия могут затруднять чтение кода и усложнить понимание того, для чего они нужны.
Ок.
> По поводу шаблонов в API. Старайтесь применять шаблоны, только если они дают элегантное и простое решение технических задач. Использовать шаблоны для создания сахара может быть неудобным решением, поскольку параметры шаблона не очевидны для понимания пользователем кода, что именно туда передается и почему. Всякие <2>, ::_3 и прочее — это коряво и выглядит как хак. К сожалению, в стандартной библиотеке такого полно. Там это делалось для ухищрений. В своем коде ухищряться подобным образом — не лучшее решение для подражания.
<2> — Этот как раз имело своей задачей упростить взаимодействие с интерфейсом: означает количество аргументов для задачи, вычисляется в compile time.
::_3 — Используется только в примере, для биндинга члена функции передаваемой в плагин.
Для подражания может не лучшее, но так легко и удобно пользовать.
Я имел опыт пользовать <2> в классах для полей значений, которые по сути являлись динамическими, вот там да, был гемор. А тут у нас возможные значения от 0 до 6…