Боюсь, вы не поняли основной посыл статьи. Речь в ней идет не о реализации, а об использовании. Собственно, это даже написано в заголовке. При этом реализацию можно взять из предложенного вами куска кода. Можно взять реализацию из Александреску. Книжка его очень умная и толковая. Но вся статья написана о том, как использовать и убрать недостатки, присущие этому паттерну.
Ответ заключается в том, что такой подход содержит в себе все недостатки, перечисленные в начале статьи. Как следствие, при кажущейся простоте, появляется трудность при расширении и превращении синглтона не в синглтон. Например, мы знаем, что у нас есть один экран и поэтому логично использовать синглтон для отрисовки изображения. Но потом появляется второй экран и выясняется, что все надо переделывать. Предложенный подход не настаивает на использовании синглтона, и в следующих статьях я покажу, как можно это использовать.
Имелось в виду то, что у реализации синглтона есть состояние, но интерфейс, конечно же, должен по возможности скрывать подробности реализации и сложности, с которыми сталкивается такая реализация. В принципе, мы говорим об одном и том же.
Для логгера есть состояние, например — открытый файл. Если файл закрыт, то в лог писать нет смысла. К тому же файл могут удалить и логи перестанут записываться, если не сделать дополнительные приседания. В данном случае вызывающему объекту не нужно знать о состоянии, синглтон его должен поддерживать самостоятельно. Но об этом важно помнить.
В целом да, но в базе данных есть один трюк. И хотя мы не знаем состояния, мы открываем транзакцию и на некоторое время фиксируем состояние грубо говоря. Потом начинаем выяснять это состояние (SELECT), и затем — изменять (INSERT,UPDATE,DELETE). Т.е. процесс происходит так, как будто мы ничего не знаем о текущем состоянии. При этом транзакция гарантирует, что никто не вмешается и не испортим нам получение состояния. Поэтому такая транзакционность упрощает взаимодействие с базой данных.
В целом, не стоит воспринимать данный тезис как то, что происходит всегда без исключений. Но об этом все же стоит помнить при проектировании/использовании.
Будет про многопоточность, но позже. Невозможно охватить все аспекты в одной статье, т.к. хочется подробно описать такой важный вопрос. Я планирую продолжение этого топика с освещением вопросов про время жизни, многопоточность и различные плюшки.
Писал кодогенератор для своей программы: был специальный формат для шаблона, и для данных, которые по шаблону генерировали код. Очень много ручной работы получилось избежать. Конечный язык генерируемого текста — С++. Генератор был так же написан на С++.
Тоже использовали IncrediBuild. Улучшение было в 3-10 раз в зависимости от проекта, количества удаленных машин и их загруженности. Самый лучший ускоритель, на мой взгляд.
А как при этом кодируется информация, которая «ставит между разрывами единичные знаки». Можно ли после этого восстановить информацию? В статье ничего про это нет.
Ну, например, компания А создает продукт Х, а компания Б создает продукты Х и Й. Продукты Х у обеих компаний конкурируют, но компания А не хочет создавать продукт Й, а хочет сконцентрироваться только на Х, т.к., например, он обладает большим функционалом и работает лучше. Поэтому и может возникнуть описанная ситуация.
К сожалению, в нашем проекте запрещают все «новое». Зато отрываюсь по полной в инструментах для разработчика, чтобы облегчить разработку различных модулей. Уже использовал:
1. Variadic templates.
2. Lambda.
3. 'auto' keyword.
4. std::shared_ptr, std::unordered_map
В частности, лямбду очень удобно использовать совместно с boost::asio.
По-моему, речь шла о том, что хочется не просто решить задачу или выполнить проект, а решить задачу в «потоке». При этом войти в этот «поток» не очень получается. И чтобы войти, необходимо начинать с малого, а потом уже после перехода в «потоковое» состояние можно будет переходить к сложным задачам или подзадачам. Т.е. это не стратегия выполнения проекта, а тактика (т.е. локальный план) перехода в «потоковое» состояние.
А вообще, мне, как обычному программисту, проще работать без оценок. Т.к. любая оценка — это способ давления, как было уже сказано в статье. Оценки нужны менеджерам, а не программистам. Программисту нужна интересная задача и чтобы его никто не отвлекал. Все остальное ему до лампочки. Ну может еще чтоб получился хороший конечный продукт, за который бы он сказал: а я принимал участие для его создания!
Зависимости есть, но они очень слабые. Дело не в зависимостях, а в том, что есть определенный срок, к которому все должны успеть. Потому как если какая-то команда скажет, что нам нужно еще месяцок, то это будет фатально для всего продукта, т.к. слишком много завязано на сроки: есть пользователи, есть ожидания, есть обязательства, есть вложенные деньги. Поэтому проще пожертвовать функционалом, чем увеличить время разработки, пусть и незначительно. В этом аспекте важно понять, какой функционал следует делать в первую очередь, а какой — перенести на следующий релиз или вообще не делать. И каждой решение — оно не простое, а выстраданное. Поэтому хочется сделать правильный выбор на основе большего количества данных.
К сожалению, не всегда можно отказаться от оценок. К примеру, мы работаем на очень большую компанию, которая создает сложный продукт, состоящий из множества компонент. Соответственно, над каждой компонентой трудится несколько человек, количество варьируется от 5 до 20. Релизы должны создаваться строго по графику, который согласуется на самом высоком уровне. В каждой компоненте существует определенный набор функционала, который должен быть сделан, но упор делается на качество, поэтому можно пожертвовать несколькими фичами ради этого качества. Фичи нельзя просто так выкинуть, их тоже надо согласовывать. Поэтому, когда решается вопрос, что выкидывать, а что оставлять, то принимается во внимание важность (ценность) фичи, а также сложность (количество потраченного времени) и риски (можно что-то не учесть и время разработки может сильно увеличиться). Поэтому стараются для анализа исходить из разных факторов. Понятно, что для простых проектов это может быть совсем не актуально. Т.е. я хочу сказать, что все зависит от задачи и от множества разных факторов.
В целом, не стоит воспринимать данный тезис как то, что происходит всегда без исключений. Но об этом все же стоит помнить при проектировании/использовании.
1. Variadic templates.
2. Lambda.
3. 'auto' keyword.
4. std::shared_ptr, std::unordered_map
В частности, лямбду очень удобно использовать совместно с boost::asio.