При разработке того, насколько полезно создавать небольшие классы для представления небольших структур данных? Например, скажем, в качестве упрощенного примера, программа использует массив строк для представления имен чего-либо, например. легковые автомобили. Вместо того, чтобы просто хранить этот массив внутри метода или класса, насколько полезно его разделить и сделать его собственным классом? Таким образом, я думаю, что он может быть ответственным за себя, и на нем могут выполняться больше действий - валидация и т. Д., Которые могут быть сохранены отдельно. Кроме того, его можно легко использовать во всей системе. Но тогда, где он останавливается, т. Е. В примере с автомобилем, вы можете продолжить создание объекта автомобиля и т. Д. Это действительно может быть бесконечным, не так ли?Разделительный код - модульный
ответ
Имеет смысл сделать это, как только вы повторяете код для работы с структурой данных.
Крис Б. делает отличную оценку взаимосвязанных данных. См. Пример рефакторинга Extract Class.
Есть несколько руководящих принципов, которые я использую, чтобы определить, когда мне нужно изменить структуру данных в свой класс:
Могу ли я хранить много взаимосвязанных данные? Если вы обнаружите, что сохраняете пару массивов и управляете ими как единое целое, лучше всего хранить один массив, содержащий объекты.
Являются ли эти структуры данных доступными для других классов? Если другие классы непосредственно подвергаются воздействию данных, вероятно, лучше всего инкапсулировать данные в свой класс, что упрощает сохранение концептуальных и фактических моделей.
Нужно ли часто выполнять операции с данными? Возможно, было бы хорошо хранить массив имен, но если вы начнете добавлять в класс упаковки такие методы, как
validateNameиcheckName, может быть хорошей идеей реорганизовать и поместить эти методы на классName.
Имейте в виду: это часто намного проще и чище, чтобы поставить достойную модель объекта на месте впереди, чем пытаться привить один на постфактум. Вы не должны делать это произвольно, но по мере того, как вы работаете над своей программой, вы должны обратить внимание на то, когда становится трудно контролировать структуры данных, которые у вас есть, - это хороший признак того, что вам следует реорганизовать их по мере необходимости.
Я думаю, что это поможет, если вы сделаете свой вопрос более ясным. Очевидно, что код OO может зайти слишком далеко, по-моему, *, но что именно вы спрашиваете здесь? Я вижу сценарий, но он кажется довольно расплывчатым. – 31eee384
ok, так что скажите, что мне нужно иметь набор объектов, которые будут по существу быть строками в качестве имен и, возможно, описанием в формате строки и любыми другими атрибутами, которые могут быть добавлены. Лучше всего держать это внутри того, что требует класс, или лучше сделать этот объект само по себе, хотя он имеет только несколько атрибутов, которые являются строками. Кроме того, если он станет его собственным объектом, тогда его проверка данных может обрабатываться его собственным конструктором, а не обрабатывать его в другом месте. Это кажется логичным для меня, но, возможно, чуть выше вершины. – Bill
Цель хорошего дизайна - в конечном итоге обеспечить ремонтопригодность и четкость без настоящих жестких и быстрых правил. Вы, безусловно, можете продолжать, объявлять паузу и моделировать всю вселенную, для которой ваш проект может взаимодействовать. Здесь важно понять, какие объекты находятся в вашем домене, и, смоделировав это, вы узнаете, когда будет достаточно простой коллекции данного объекта или требуется более логический блок. – apiri