Сколько объектов - слишком многие?
Попробуйте поместить свои Row виджеты в Expanded.
Expanded(flex: 0, child: Image.asset('assets/images/avatar.png')),
Expanded(
flex: 0,
child: Container(
height: 90.0,
width: 1,
color: new Color(0xFFEDEDED))),
Expanded(
flex: 1,
child: Container(
child: TextField(
keyboardType: TextInputType.text,
style: new TextStyle(
fontFamily: "WorkSansLight",
fontSize: 30.0,
color: Colors.white70),
decoration: new InputDecoration(
border: InputBorder.none,
hintText: "USER NAME",
hintStyle: new TextStyle(
color: Colors.black,
fontFamily: "WorkSansLight",
fontSize: 30.0)))))
11 ответов
Я предполагаю, что Вы говорите о типах и не объектах (я знаю, что это называют объектной моделью, но это действительно - модель включенных типов).
Так или иначе, если Вы подпишетесь на Единственный Принцип Ответственности, который указывает, что каждый тип должен только обработать единственную ответственность, то количество типов вырастет, как приложение растет.
Однако каждый тип должно быть довольно легко постигать из-за его ограниченного размера, и предположив наличие некоторой структуры Вы редко должны (если когда-либо), должен посмотреть на все типы за один раз.
Управление большим проектом программного обеспечения является всем о распадающихся вещах в управляемые части и маркировку их разумным способом. Если Вы делаете это, количество типов становится менее важным, по моему опыту.
В точке, когда Вы задаетесь вопросом, "какого черта это - объект?"
У меня недавно был класс "BetForgetter", который я осуществил рефакторинг в 2 строки кода в другом классе.
Это - вероятно, признак другой проблемы.
По моему скромному мнению - пока у Вас есть хороший проект, пространство имен и/или организация каталога, наряду с разумным соглашением о присвоении имен, необходимо смочь обработать любое количество классов легко.
PS-I'm, принимающая Вас предназначенные 'классы', когда упомянутые 'объекты'.
Я не уверен, что ответ в пределах всего проекта, но я могу обычно говорить, что два класса могли бы быть более обеспечены как тот, если они зависят слишком много друг от друга.
Никакое жесткое правило, но в значительной степени до усмотрения программистов.
Но как правило ползунка, если Ваши напрасно тратящие время классы записи к к самой крошечной операции, то это многим.... и комплексу. Если Ваши мегаглыбы записи кода затем это слишком мало.
Не только со слишком многими объектами, но также и со слишком большой сложностью, я обнаруживаю точку, когда я чувствую потерянное чтение моего кода после одного выходного.
Я сказал бы, что необходимо, вероятно, взволновать больше по поводу наличия лишь немногих объект/классы. SRP является чем-то стоящим пребывать к тому, поскольку это обычно приводит к инструменту для очистки и большему количеству читаемого кода.
Я думаю, что невозможно ответить на Ваш вопрос, не зная Вашей проблемы.
Это во многом зависит от проблемы, которую Вы пытаетесь решить со своим приложением.
Iraimbilanja является абсолютно правильным. Если Вы начнете создавать объекты для всего, что пересекает Ваш путь, то Вы скоро будете задаваться вопросом, что является использованием, которое можно дать им, и какого черта Вы проводите время для создания их.
Проект с надлежащим дизайном OO, с сотнями объектов, находится в намного лучшем состоянии, чем одно с меньше, монолитными классами.
Вы никогда не можете иметь слишком многих из них, спрашивать любого достойного программиста Java.
Какой длины часть строки? (дважды длина с середины в конец, но это не относится к делу),
Я думаю, что это действительно зависит от того, что Вы пишете и как Вы записали это. Количество объектов является плохим головокружительным, необходимо волноваться о сложности объектной модели не, сколько объектов Вы имеете. То, насколько сильно связанный Ваши объекты, - то, что необходимо спрашивать.
Если у Вас есть 100 других типов объекта Bird, все из которых реализуют интерфейс и общие методы, находятся в абстрактном классе затем, у Вас нет слишком многих объектов, потому что, возможно, Вам нужен каждый Bird для действия по-другому.
Однако, если у Вас есть путаница obejects, который весь реализуют тот же код затем, Вы имеете слишком много объектов и можете осуществить рефакторинг к наличию меньше.
Так же, если у Вас есть один огромный класс, который содержит большую разрозненную функциональность затем, у Вас есть слишком мало классов.
Если у Вас нет классов, которые делают то же самое или копируют вещи, что другие классы в платформе уже делают их, Вы в порядке.
И помните просто, потому что можно использовать наследование, не означает, что Вы имеете к, состав часто лучше.