Слишком длинная цепочка. Товарищ выше правильно заметил — штрафовать человека, читавшего книгу в исправном робомобиле не за что.
Как вариант — вводить обязательную страховку для владельцев робомобилей. Очевидно, что для более безопасных машин будут предлагаться пониже страховые выплаты, что и будет конкурентным преимуществом на рынке.
Я в отпуске-то код писать начинаю, от того, что скучно становится. Так что и на пенсии буду писать =)
Засесть за какой-нибудь Open Source проект, развивать его, ездить по конференциям.
Функциональщину я даже не рассматриваю — её преимущества не объяснить в комментариях, особенно ярым адептам ООП.
Хорошего способа — нет. Т.е. можно сделать ООП код без ООП конструкций языка (суть ООП не в ключевых словах, а в полиморфизме, наследовании), но с ними проще и понятнее. Там где действительно нужен полиморфизм — уходить в процедурщину я не советую.
А вот это уже полиморфизм — и это сильная сторона ООП =)
Способ, конечно же, есть:
foreach($modifiedObjects as &$object)
{
if ($object['validate']($object))
{
$object['save']($object);
}
else
{
$objectsWithErrors []= $object;
}
}
В таком подходе есть один серьезный плюс — легко менять методы «на лету», создавая объекты, не привязанные к классам.
Но, смотрится это плохо, да и IDE не сможет подхватить эти функции. Это магия Си, её не нужно использовать в языках с развитым ООП.
Ой, я не ругаю программистов, я лишь говорю, что это очень плохой пример преимуществ ООП. Можно было найти гораздо лучше.
Скажем, такой:
// Этот код выполнится, но когда где-нибудь потом всплывет ошибка, будет очень тяжело её локализовать
$user['age'] = -5;
// А вот этот код может отреагировать на неверное значение: ассертом, исключением, кодом возврата или же просто не изменив состояние объекта.
$user->setAge(-5);
можем изменить данные и вызвать метод save объекта $user и сохранить запись в таблице, можем провести вализацию
user_save($user);
user_validate($user);
В чем проблема? Где костыли?
Процедурный стиль, ООП стиль, функциональный стиль — это лишь инструменты. И не в выборе инструментов дело. А вот то, как эти инструменты используются и отличает программиста от кодера. Если вы не в курсе, то Линус пишет на С, а не на С++, и прекрасно обходится без статических фабрик.
Как вариант — вводить обязательную страховку для владельцев робомобилей. Очевидно, что для более безопасных машин будут предлагаться пониже страховые выплаты, что и будет конкурентным преимуществом на рынке.
Да и регистратор в неё ставить не надо ;)
Засесть за какой-нибудь Open Source проект, развивать его, ездить по конференциям.
Падать вместо попытики исправиться — это иногда совершенно корректная обработка ошибок ;) Особенно во время разработки.
Остаюсь на Droid Sans Mono.
Все, достаточно. А то, что в топике — классический такой говнокод =)
ППКС, как говорится. Только ООП тут ни при чем — при любом подходе возможны хорошие и плохие проекты.
Не представляете? Наверное, мало работали в процедурном стиле?
Хорошего способа — нет. Т.е. можно сделать ООП код без ООП конструкций языка (суть ООП не в ключевых словах, а в полиморфизме, наследовании), но с ними проще и понятнее. Там где действительно нужен полиморфизм — уходить в процедурщину я не советую.
Способ, конечно же, есть:
В таком подходе есть один серьезный плюс — легко менять методы «на лету», создавая объекты, не привязанные к классам.
Но, смотрится это плохо, да и IDE не сможет подхватить эти функции. Это магия Си, её не нужно использовать в языках с развитым ООП.
Если же функции все-таки разные (а обычно так и происходит), то при любом подходе придется писать дополнительный код и дополнительные тесты.
Скажем, такой:
В чем проблема? Где костыли?
Процедурный стиль, ООП стиль, функциональный стиль — это лишь инструменты. И не в выборе инструментов дело. А вот то, как эти инструменты используются и отличает программиста от кодера. Если вы не в курсе, то Линус пишет на С, а не на С++, и прекрасно обходится без статических фабрик.