А еще флешка требует подзарядки, помнится, порядка одного раза в год.
Иначе вся информация на ней будет потеряна.
Имточника информации, увы, не помню, но можно погуглить.
Пользоваться глобальным меню неудобно. 100% неудобно!
Если более одного уровня вложенности, то чтобы попасть в нужное место нужно потратить в среднем 3-5 секунд. И это в том случае, если заранее знаешь, где оно находится, и пользовался этим раньше.
Меню «удобно» использовать только в том случае, если физически нет мыши (сломалась и т.д.). В остальных случаях даже контекстные меню намного юзабельнее глобального.
Думаю, в будущем для программ вместо глобального меню останется только панель инструментов.
И привычная всем строка поиска с автозаполнением. И справка по командам для новичков (с обучением). А в чуть более далеком будущем — голосовое управление по тому же принципу.
Автообновление, имхо — это отдельный асинхронный сервис.
Он не инициируется пользователем, а выполняется по некому «внутреннему» расписанию.
Следовательно, к паттерну MVC он не имеет никакого отношения.
И компактно :-)
На Java с нормальным полиморфизмом и отвязкой через интерфейсы у меня около 40 классов и интерфейов на вычислитель выражений уходило :-)
Ну, не совсем верно.
Набор инструментов в разработке ПО более-менее стабилен в течение пары лет.
Да, новые технологии появляются, старые улучшаются, но не обязательно же все сразу внедрять.
У нас есть заготовки частей каркаса (framework'и), у которых заданы правила, по которым их можно соединять друг с другом. А вот какие части выбрать и как их соединять, какую делать начинку — это всегда разное, увы.
И еще: программный продукт лучше соотносить не с законченным зданием, а с заселенным.
В каждой квартире свой ремонт, кое-где ремонта уже 10 лет не было, и нет денег и времени, чтобы его сделать, и т.д. В подъезде обваливается штукатурка, стены оказываются изрисованными, косметический ремонт спасает ненадолго, и т.д.
Но это не мешает в этом доме жить, хотя многое и не нравится.
IMHO, этот процесс уже довольно точно соответствует реальной жизни проекта.
И цена координальных изменений в ПО примерно соответствует цене перестройки части здания (а давайте на крыше бассейн сделаем?)
«Совершенный код» и «Чистый код» сильно правят мозги :-)
Особенно переполненные ООП'ом или функциональным стилем, синтаксическим сахаром и т.д.
Мое личное видение: код может быть не лучшего вида, но высокая связность и низкая связанность должны сохраняться, иначе код потом трудно будет переписать.
Если же эти два критерия выполнены — можно скрепя сердце оставить низкоуровневые переплетенные конструкции в их локальном ящике, закрыть его интерфейсом, специфицировать — и пусть работает (если, конечно, работает). До тех пор, пока не понадобится его расширить — тогда и перепишем, если текущий вариант трещит по швам.
Code review за своей командой, IMHO, проводить нужно, но не тыкать на некритичные вещи. Если такие находятся — лучше отдайте этот кусок на review другому коллеге, пусть он их найдет. А вот критические вещи все равно нужно контролировать кому-то достаточно опытному. Особенно когда дело касается оптимизации запросом путем создания индексов, когда ищутся пути избавлений от deadlock'ов и т.д.
Подготовьте бизнес-план реализации проекта.
Какие концепции, в каком порядке, что вначале, что потом, какие нужны минимальные затраты на первом этапе и т.д.
Никакой инвестор даже не будет с Вами разговаривать без нормального бизнес-плана.
Агрегатором Box2DObject в Вашем случае является Box2DObject.
Следовательно, логичнее всего поместить его уничтожение в деструктор объекта Box2DObject.
И не порождать лишних сущностей.
Так что если использование Creator'а еще обосновано, то Destroyer, IMNSHO, не нужен в данном случае.
Я бы добавил это резюме в конец топика, чтобы народу не приходилось холивары перечитывать.
Иначе вся информация на ней будет потеряна.
Имточника информации, увы, не помню, но можно погуглить.
Integer a = 127;
Integer b = 128;
?
Если более одного уровня вложенности, то чтобы попасть в нужное место нужно потратить в среднем 3-5 секунд. И это в том случае, если заранее знаешь, где оно находится, и пользовался этим раньше.
Меню «удобно» использовать только в том случае, если физически нет мыши (сломалась и т.д.). В остальных случаях даже контекстные меню намного юзабельнее глобального.
Думаю, в будущем для программ вместо глобального меню останется только панель инструментов.
И привычная всем строка поиска с автозаполнением. И справка по командам для новичков (с обучением). А в чуть более далеком будущем — голосовое управление по тому же принципу.
Он не инициируется пользователем, а выполняется по некому «внутреннему» расписанию.
Следовательно, к паттерну MVC он не имеет никакого отношения.
На Java с нормальным полиморфизмом и отвязкой через интерфейсы у меня около 40 классов и интерфейов на вычислитель выражений уходило :-)
Набор инструментов в разработке ПО более-менее стабилен в течение пары лет.
Да, новые технологии появляются, старые улучшаются, но не обязательно же все сразу внедрять.
У нас есть заготовки частей каркаса (framework'и), у которых заданы правила, по которым их можно соединять друг с другом. А вот какие части выбрать и как их соединять, какую делать начинку — это всегда разное, увы.
И еще: программный продукт лучше соотносить не с законченным зданием, а с заселенным.
В каждой квартире свой ремонт, кое-где ремонта уже 10 лет не было, и нет денег и времени, чтобы его сделать, и т.д. В подъезде обваливается штукатурка, стены оказываются изрисованными, косметический ремонт спасает ненадолго, и т.д.
Но это не мешает в этом доме жить, хотя многое и не нравится.
IMHO, этот процесс уже довольно точно соответствует реальной жизни проекта.
И цена координальных изменений в ПО примерно соответствует цене перестройки части здания (а давайте на крыше бассейн сделаем?)
Тогда она отлавливается на этапе тестирования :-)
На менеджеров тоже есть кому надавить сверху…
Особенно переполненные ООП'ом или функциональным стилем, синтаксическим сахаром и т.д.
Мое личное видение: код может быть не лучшего вида, но высокая связность и низкая связанность должны сохраняться, иначе код потом трудно будет переписать.
Если же эти два критерия выполнены — можно скрепя сердце оставить низкоуровневые переплетенные конструкции в их локальном ящике, закрыть его интерфейсом, специфицировать — и пусть работает (если, конечно, работает). До тех пор, пока не понадобится его расширить — тогда и перепишем, если текущий вариант трещит по швам.
Code review за своей командой, IMHO, проводить нужно, но не тыкать на некритичные вещи. Если такие находятся — лучше отдайте этот кусок на review другому коллеге, пусть он их найдет. А вот критические вещи все равно нужно контролировать кому-то достаточно опытному. Особенно когда дело касается оптимизации запросом путем создания индексов, когда ищутся пути избавлений от deadlock'ов и т.д.
Если в интерфейсы добавятся default-методы, то чем они будут отличаться от абстрактных классов?
А разве не
(= number (sum-factors number)))
?
Какие концепции, в каком порядке, что вначале, что потом, какие нужны минимальные затраты на первом этапе и т.д.
Никакой инвестор даже не будет с Вами разговаривать без нормального бизнес-плана.
Следовательно, логичнее всего поместить его уничтожение в деструктор объекта Box2DObject.
И не порождать лишних сущностей.
Так что если использование Creator'а еще обосновано, то Destroyer, IMNSHO, не нужен в данном случае.