Активность Android - это часто, когда в одном классе активности много кода? - PullRequest
3 голосов
/ 20 марта 2012

Мое единственное занятие, кажется, немного выросло, и я чувствую, что вещи должны быть как-то более объектно-ориентированными.Я думаю, что это происходит потому, что я только учусь и поэтому продолжаю добавлять разные взгляды, чтобы увидеть, как все работает.Прежде чем я это узнал, он стал большим.

У меня есть подклассы, такие как LinearLayout, ViewFlipper, Button, TextView и т. Д., И я подумал, что они предоставляют конструкторы для этих классов, которые принимают аргументы, такие как textize, font, параметры макета,цвет фона и т. д. может помочь в этой ситуации и на самом деле может больше подойти к общим парадигмам проектирования ООП.Выполнение этого таким образом, конечно, означает, что у моего конструктора будет множество аргументов.

Мне было интересно, смогу ли я получить некоторую обратную связь об этом подходе выше: должен ли я использовать свои подклассы в своих интересах для большего дизайна ООП,или у некоторых действий просто естественно много кода?Спасибо!

1 Ответ

5 голосов
/ 20 марта 2012

У меня есть подклассы, такие как LinearLayout, ViewFlipper, Button, TextView и т. Д., И т. Д., И я подумал, что предоставление конструкторов для этих классов, которые принимают аргументы, такие как textize, шрифт, параметры макета, цвет фона и т. Д. И т. Д., Может помочь в ситуации и на самом деле может пригодиться больше к общим принципам дизайна ООП.

Это не очень хорошая идея. Виджеты не предназначены для расширения в качестве средства настройки. Более того, в этом нет необходимости, поскольку все, что вы перечисляете, может (и должно) быть определено в ресурсах макета XML.

Есть ли в некоторых видах деятельности много кода?

Некоторые действия ответственны за большое количество кода. Вы можете использовать эту логику в других классах, но они не обязательно будут подклассами виджетов. Ваши Adapters, различные ...Listeners, AsyncTasks, Loader.Callbacks и т. Д. Часто могут быть выделены в отдельные публичные классы, вместо того, чтобы ваша деятельность реализовывала zillion интерфейсы или имела связки внутренних классов.

...