Строка по сравнению с новым классом Данных
Я подслушал двух из своих коллег, спорящих о том, создать ли новый класс модели данных, который только содержит одно строковое поле и метод set и метод считывания для него. Программа затем создаст несколько объектов класса и поместит их в список массива. Парень, который хранит их, утверждает, что должен быть новый тип, в то время как парень, который говорил данные, нет точки, проходящей всю эту проблему, в то время как Вы можете простая строка хранилища.
Лично я предпочитаю создавать новый тип, таким образом, мы знаем то, что хранится в списке массива, но у меня нет веских доводов для убеждения 'добирающегося' парня данных. Вы?
Sarah
8 ответов
... новый класс модели данных, который содержит только одно строковое поле и сеттер и геттер для него.
Если бы это был только геттер, то нельзя сказать в общем случае, что лучше - класс String или пользовательский класс. Это зависит от таких вещей, как:
- согласованность с остальной частью вашей модели данных,
- предвидение того, захотите ли вы изменить представление,
- предвидение того, захотите ли вы реализовать проверку при создании экземпляра, добавить вспомогательные методы и т.д.,
- последствия для использования памяти или персистентности (если они вообще имеют значение).
(Лично я склонялся бы к использованию обычной строки по умолчанию, и использовал бы пользовательский класс, только если, например, я знал, что, вероятно, в будущем потребуется изменение или уточнение представления. В большинстве ситуаций не составит большой проблемы изменить String на пользовательский класс позже... если возникнет такая необходимость.)
Однако тот факт, что для поля предлагается использовать сеттер, существенно меняет ситуацию. Экземпляры класса будут изменяемыми, а экземпляры String - нет. С одной стороны, это может быть полезно, например, если вам действительно нужна изменяемость. С другой стороны, мутабельность сделает класс несколько рискованным для использования в определенных контекстах, например, в наборах и в качестве ключей в картах. А в других контекстах может потребоваться копирование экземпляров. (Это было бы излишним для неизменяемого класса-обертки или "голой" String.)
(Простой ответ - избавиться от сеттера, если только он вам действительно не нужен.)
Существует также вопрос, что семантика equals будет различной для String и пользовательской обертки. Поэтому вам может понадобиться переопределить equals и hashCode, чтобы получить более интуитивно понятную семантику в случае пользовательской обертки. (И это относится к вопросу о сеттере и использовании класса в коллекциях)
Оберните его в класс, если он соответствует остальной структуре вашей модели данных.
- Он дает вам метку для строки, чтобы вы могли сказать, что она представляет во время выполнения.
- Это упрощает получение вашей сущности и добавление дополнительных полей и поведения. (Что может быть вероятным>)
Тем не менее, ключ - , если он соответствует остальной части вашей модели данных ... согласовываться с тем, что у вас уже есть.
Контрапункт к ответу mschaef:
Сохраните его как строку, если она соответствует остальной структуре вашей модели данных. (Видите, как вступление звучит так важно, даже если я дополню его предложением, в котором в основном говорится, что мы не знаем ответа?)
- Если вам нужен ярлык, говорящий, что это такое, добавьте комментарий. Стоимость = одна линия, всего. Черт возьми, в любом случае вам нужна строка (или три), чтобы прокомментировать ваш новый класс, так для чего же это объявление класса?
- Если вам нужно добавить дополнительные поля позже, вы можете реорганизовать его , затем . Вы не можете проектировать для всего, и если бы вы попытались, вы бы получили ужасный беспорядок.
Как Егге говорит , «худшее, что может случиться с базой кода, - это размер». Добавьте объявление класса, геттер и сеттер, теперь вызывайте их отовсюду, где к нему прикасаются, и вы добавили размер в свой код без реальной (т. Е. Не гипотетической) цели .
Это зависит от того, есть ли реальная возможность добавить поведение к типу позже. Даже если геттеры и сеттеры сейчас тривиальны, тип имеет смысл, если есть реальный шанс, что они смогут что-то сделать позже. В противном случае достаточно четких имен переменных.
Я не согласен с другими ответами:
Это зависит от того, есть ли реальная возможность добавить поведение к типу позже [Matthew Flaschen]
Нет, не есть. ...
Никогда не помешает защитить дизайн на будущее [Alex]
Верно, но здесь не уместно...
Лично я был бы склонен использовать обычную String по умолчанию [Stephen C]
Но это не вопрос мнения. Это вопрос проектных решений:
Является ли объект, который вы храните, логически строкой, куском текста? Если да, то храните строку (игнорируя вопрос с сеттером).
Если нет - тогда не храните строку. То, что данные могут храниться как строка - это деталь реализации, она не должна быть отражена в вашем коде.
Для второго пункта не имеет значения, захотите ли вы добавить поведение позже. Важно лишь то, что в сильно типизированном языке тип данных должен описывать логическую сущность. Если вы работаете с вещами, которые не являются текстом (но могут быть представлены текстом, могут содержать текст ...), то используйте класс, который внутренне хранит этот текст. Не храните текст напрямую.
В этом весь смысл абстракции и сильной типизации: пусть типы представляют семантику вашего кода.
И наконец:
Как говорит Егге, "худшее, что может случиться с кодовой базой - это размер". [Ken]
Ну, это так иронично. Вы читали какие-нибудь записи в блоге Стива Йегге? Я нет, они просто чертовски длинные.
Я не вижу причин, по которым String следует заключать в класс. Основное мнение, стоящее за обсуждением, заключается в том, что потребность времени - это объект String. Если позже он будет расширен, тогда произведите рефакторинг. Зачем добавлять ненужный код во имя будущего.
За время, потраченное на обсуждение того, следует ли обернуть его в класс, его можно было обернуть и покончить с этим. Никогда не помешает сохранить дизайн в будущем, особенно когда это требует минимальных усилий.
Заключение его в класс обеспечивает большую безопасность типов - в вашей модели вы можете использовать только экземпляры класса-оболочки, и вы не сможете легко допустить ошибку, поместив в модель строку, содержащую что-то другое. .
Однако это добавляет накладные расходы, дополнительную сложность и многословность в ваш код.