Тоже можно решить, по-моему. Трудно, конечно, говорить в общем случае, но параметры, передаваемые в функцию обычно как-то логически связаны. А значит их можно объединить в один тип (или несколько). После этого можно инициализировать только нужные поля объекта этого типа и передавать в подпрограмму. Да, вызов в одну строчку может потеряться, но это не самая страшная потеря, особенно если ее ценой получится увернуться от тяжелых костылей.
Хаки нужны, чтобы проверить теорию. Система контроля версий позволяет удалять их бесследно. Иногда придумываешь несколько вариантов развития архитектуры, причем друг с другом несовместимые и на качественную реализацию каждого нужен, скажем, месяц. А система уже до того немаленькая, что любые попытки продумать последствия в голове взрывают мозг. При этом каким-то местом ощущаешь, что правильный вариант только один. В этом случае лично мне проще начать делать один из вариантов «напролом» — без инкапсуляции, с глобальными переменными, если так быстрее и т.п. Обычно уже в этот же день натыкаешься на на какую-то концептуальную проблему, типа «класс двигателя внутреннего сгорания для корректной работы требует ссылку на таблицу с днями рождения водителей» (пример надуман). Сразу понимаешь — идея плоха изначально, трат времени не достойна, откатываемся…
Все зависит от сложности системы. Одни прототипы можно легко выбрасывать и переписывать, другие — нет. Недавно столкнулся с ситуацией, когда прототип умудрялись тянуть на костылях и велосипедах больше года, и процентов 90 функциональности было реализовано, но в конце оказалось, что получившаяся архитектура в принципе неспособна потянуть оставшиеся 10%. Ничего не подозревающий заказчик, наблюдая за прогрессом, ждал результат очень скоро. Система формировалась на глазах… Было очень непросто объяснить ему, что на 10% потребуется еще 100% времени. А вот если бы эти разработчики (индусы, кстати, хз, совпадение ли) хоть недельку в самом начале провели с секатором в размышлениях — кто знает… Прототипы могут затягивать — с ними все время кажется, что цель приближается… Отчасти это вопрос удачи — выдержат ли костыли в фундаменте полную функциональность или все рухнет в самом конце.
Все вроде бы автора и осуждают, но плюсы ставят. После аналогичного успеха статьи про веточки и молнии было понятно, что теперь kreosan просто обязан развивать тему. Да, микроволновка кинескоп переплюнула. Но что сейчас делать? На бытовых приборах дальше, скорее всего, не уедешь. Придется смотреть в сторону промышленного оборудования или у военных что-то заимствовать… Вот тут уже можно реально с защитными очками не заморачиваться
Это наталкивает меня на мысль что класс отвечает за слишком много вещей
Трудно в общем случае сказать, слишком или нет. Возможно, предметная область реально сложная, и маленькими классами не обойтись. Может, приходится дорабатывать унаследованную систему. Я же не говорю, что это решение на все случаи жизни. Большие классы время от времени случаются. Обычно нельзя сказать «Тут проблема дизайна — ничего делать не буду, я работаю только с идеальными решениями. И вообще — давайте все перепишем с нуля!» :)
Это значит что у нас точно есть состояние когда объект недособран
Нет такого состояния. Все зависимости внедряются вызовами конструкторов полей по умолчанию. Т.е. к началу выполнения тела любого конструктора (и тем более нестатического метода) все будет инициализировано. Причем, если зависимость не определена, будет ошибка компиляции. Сообщение об ошибке получится не очень очевидным, но нужно помнить, что в статье приводится лишь идея, это даже близко не готовый продукт
Я встречал статьи ( в реальных проектах я, к сожалению, с последовательными стратегиями внедрения зависимостей не сталкивался), где описывалось внедрение через конструктор… С одной стороны они действительно смотрелись понятнее и логичнее, но с другой там обычно
Но представьте, что будет, если зависимостей хотя бы штук 5, а конструкторов несколько.
Кроме того, на мой взгляд, логически правильнее отделять зависимости от параметров конструирования.
В таком возрасте важно развивать детей «вширь», т.е всякие книги общеразвивающие предлагать, фильмы, мероприятия посещать и т.п. Чтобы росло количество вариантов выбора в будущем. Иначе будет одно из двух
Родители навяжут свой выбор узкой специальности — а дальше уж как повезет
Ребенок сам выберет что-то солидное — президента, космонавта или человека-паука, потом окажется, что вакансий не так и много, придется идти на экономиста...
Я не хочу сказать, что космонавтом быть плохо, но это должен быть осознанный выбор после ознакомления с другими специальностями, а не просто «папа сказал определиться до 6-го класса»
Информация, конечно, нужна, но в статье идет речь о подталкивании к определенному образу мышления, склонности к которому может и не быть. И если взрослый человек может сказать «Не, это не для меня», то ребенок вряд ли найдет подходящие слова и будет терпеть…
Сейчас модно стало начинать учить детей всему как можно раньше. По-моему, это лишнее давление в таком возрасте. Вон в мои времена в первом классе единицы умели читать, а сейчас это чуть ли не обязательное требование… Причем умение читать в первом классе никак не коррелировало с успехами в последнем. Непонятно зачем это все — осознанный выбор любимой профессии у большинства к концу школы произойдет (если вообще произойдет), а на должность специалиста восьмилетнего все равно не возьмут.
для вычисления расстояния придется числа в квадраты возводить или по модулю брать, а с прямоугольными областями (стороны которых параллельны осям координат) достаточно операций сравнения
Напомнило. Есть у меня несколько знакомых, которые хорошие фильмы смотрят на обычной скорости, а плохие — на удвоенной. И считают, что экономят время. Но ведь еще больше сэкономится, если не смотреть плохие вообще…
Переход в atmosphere.meteor.com/ отправил закладку в глубокую задумчивость (chrome, ios). Надпись «WTF» в заголовке списка пакетов хорошо угадала мои мысли :)
Трудно в общем случае сказать, слишком или нет. Возможно, предметная область реально сложная, и маленькими классами не обойтись. Может, приходится дорабатывать унаследованную систему. Я же не говорю, что это решение на все случаи жизни. Большие классы время от времени случаются. Обычно нельзя сказать «Тут проблема дизайна — ничего делать не буду, я работаю только с идеальными решениями. И вообще — давайте все перепишем с нуля!» :)
Нет такого состояния. Все зависимости внедряются вызовами конструкторов полей по умолчанию. Т.е. к началу выполнения тела любого конструктора (и тем более нестатического метода) все будет инициализировано. Причем, если зависимость не определена, будет ошибка компиляции. Сообщение об ошибке получится не очень очевидным, но нужно помнить, что в статье приводится лишь идея, это даже близко не готовый продукт
1. Конструктор один
2. Параметров у него немного
3. Зависимостей тоже одна-две
Но представьте, что будет, если зависимостей хотя бы штук 5, а конструкторов несколько.
Кроме того, на мой взгляд, логически правильнее отделять зависимости от параметров конструирования.
Я не хочу сказать, что космонавтом быть плохо, но это должен быть осознанный выбор после ознакомления с другими специальностями, а не просто «папа сказал определиться до 6-го класса»