Узко мыслите.
Представьте теперь, что кроме Person есть еще Alien extends Person. Для поддержки Alien вы добавляете в функцию sayHey(Person p) функциональность работы с Alien, а потом РУКАМИ в рантайме выбираете, какую же функцию вам позвать. В ООП это красиво оборачивается в иерархию классов, и клиенту будет уже по барабану, кто там этот ваш наследник — Person, Alien или Animal. Понимаете? Мы абстрагируемся от физической природы и работаем с контрактом того, что с этой иерархией можно поздороваться. В процедурном прог
По первому пункту: если вам «повезло» работать с коллегой, который пишет короткий, но ничего не значащий код, это не означает, что писать длинные методы — хорошо. Это значит, что ваш коллега не потрудился написать понятный код, это раз.
Слышали что-нибудь про декомпозицию? Если вы не понимаете, что делает маленький кусок кода, то понять кусок, состоящий из 10 маленьких непонятных кусков — еще сложнее, это два.
Вы раньше писали на c++? Ваш код-стайл не соответсвует java conventions и Android conventions. В частоности, в java world никто не именует члены класса через подчеркиание. Либо не делают этого вообще, либо используют префикс m( Android стиль).
Делегат — это конечно хорошо. Но не тогда, когда этот делегат — Activity. Про memory leak уже сказали. Лучше пользоваться Handlers, это решает сразу проблему с утечкой, а так же обеспечивает низкую связность.
1. Не всегда геттеры сводятся к простому getProperty. Да, должны сводится, но не сводятся. И тогда надо отказываться от генерации и все равно их писать.
2. Сгенерировать геттеры-сеттеры это одна комбинация горячих клавиш. Конечно, они занимают место, но есть code-folding. К hashCode() и equals() это тоже относится. Я к чему — проект не решает какой-то адской проблемы.
3. Как любая прослойка, она будет добавлять досадные баги, вылавливание которых может запросто привести к потере сэкономленного времени.
Платформа Андроид предоставляет разработчикам возможность торговли электронными товарами изнутри приложения. Разработчик указывает список того, что можно купить и платформа проводит самостоятельно платеж, когда пользователь дает на него согласие.
Представьте теперь, что кроме Person есть еще Alien extends Person. Для поддержки Alien вы добавляете в функцию sayHey(Person p) функциональность работы с Alien, а потом РУКАМИ в рантайме выбираете, какую же функцию вам позвать. В ООП это красиво оборачивается в иерархию классов, и клиенту будет уже по барабану, кто там этот ваш наследник — Person, Alien или Animal. Понимаете? Мы абстрагируемся от физической природы и работаем с контрактом того, что с этой иерархией можно поздороваться. В процедурном прог
Слышали что-нибудь про декомпозицию? Если вы не понимаете, что делает маленький кусок кода, то понять кусок, состоящий из 10 маленьких непонятных кусков — еще сложнее, это два.
И да, чем вы лучше doit.im?
1. Не всегда геттеры сводятся к простому getProperty. Да, должны сводится, но не сводятся. И тогда надо отказываться от генерации и все равно их писать.
2. Сгенерировать геттеры-сеттеры это одна комбинация горячих клавиш. Конечно, они занимают место, но есть code-folding. К hashCode() и equals() это тоже относится. Я к чему — проект не решает какой-то адской проблемы.
3. Как любая прослойка, она будет добавлять досадные баги, вылавливание которых может запросто привести к потере сэкономленного времени.
Вещь может и хорошая, но слишком много но.