Пусть есть некоторый класс MyData, который представляет данные предметной области (например: Отчёт, Лабиринт, Игровая доска, ...)
Соответственно он предоставляет через свои методы данные внешним объектам (например данные отчёта, структуру лабиринта, позицию игрока, клетки доски и т.д.)
Вопрос в том куда помещать метод создания самого объекта класса MyData:
* в сам класс MyData
* в другой класс, например MyDataCreator
Если в сам класс MyData, то не нарушает ли это принцип SRP ?
Если другой класс, то не вносит ли это излишнюю сложность ?
Здравствуйте, nikda, Вы писали:
N>Пусть есть некоторый класс MyData, который представляет данные предметной области (например: Отчёт, Лабиринт, Игровая доска, ...) N>Соответственно он предоставляет через свои методы данные внешним объектам (например данные отчёта, структуру лабиринта, позицию игрока, клетки доски и т.д.)
N>Вопрос в том куда помещать метод создания самого объекта класса MyData: N>* в сам класс MyData N>* в другой класс, например MyDataCreator
N>Если в сам класс MyData, то не нарушает ли это принцип SRP ?
Если этот метод тривиален, то не нарушает, если нетривиален, то нарушает.
N>Если другой класс, то не вносит ли это излишнюю сложность ?
Если этот метод не нужен, то вносит, если нужен, то не вносит.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, nikda, Вы писали:
N>Пусть есть некоторый класс MyData, который представляет данные предметной области (например: Отчёт, Лабиринт, Игровая доска, ...) N>Соответственно он предоставляет через свои методы данные внешним объектам (например данные отчёта, структуру лабиринта, позицию игрока, клетки доски и т.д.)
Так-то MyData должна хранить только данные в их чистом виде, а отчёты и прочее должно генерироваться во view. N>Вопрос в том куда помещать метод создания самого объекта класса MyData: N>* в сам класс MyData
Template pattern N>* в другой класс, например MyDataCreator
Factory pattern
N>Если в сам класс MyData, то не нарушает ли это принцип SRP ?
Нет. N>Если другой класс, то не вносит ли это излишнюю сложность ?
Зависит от. Фабрику делают если есть много разных сущностей которые ты хочешь производить но выдавать какую-то абстракцию или интрфейс скрывая детали реализации.
Здравствуйте, nikda, Вы писали:
N>Пусть есть некоторый класс MyData, который представляет данные предметной области (например: Отчёт, Лабиринт, Игровая доска, ...) N>Соответственно он предоставляет через свои методы данные внешним объектам (например данные отчёта, структуру лабиринта, позицию игрока, клетки доски и т.д.)
N>Вопрос в том куда помещать метод создания самого объекта класса MyData: N>* в сам класс MyData N>* в другой класс, например MyDataCreator
N>Если в сам класс MyData, то не нарушает ли это принцип SRP ?
Нет не нарушает. С этой тз и конструктор класса нарушает SRP класса.
N>Если другой класс, то не вносит ли это излишнюю сложность ?
Вносит, лишние места-файлы, куда надо заглядывать. Лучше все относящееся к MyData держать в соотв. файле или классе.
Здравствуйте, nikda, Вы писали:
N>Пусть есть некоторый класс MyData, который представляет данные предметной области (например: Отчёт, Лабиринт, Игровая доска, ...) N>Соответственно он предоставляет через свои методы данные внешним объектам (например данные отчёта, структуру лабиринта, позицию игрока, клетки доски и т.д.)
Через методы выражают поведение, если это просто доступ к данным, то мы имеем дело с обычной структурой данных.
N>Вопрос в том куда помещать метод создания самого объекта класса MyData: N>* в сам класс MyData N>* в другой класс, например MyDataCreator
Если этот "метод создания" занимается тупым выделением памяти под объект, то его вообще не нужно создавать, он уже есть: оператор new.
N>Если в сам класс MyData, то не нарушает ли это принцип SRP ?
Не нарушает. N>Если другой класс, то не вносит ли это излишнюю сложность ?
Привносит.
По теме — начните с простого конструктора.
Если логика тяжёлая или включает в себя не только создание объекта, но и его настройку, заполнение свойств из других объектов и тыды — вынесите в static factory-метод.
Если вся логика находится в ответственности другого сервиса (например, объект вытаскивается из СУБД или собирается из xml-я) — выделите логику создания в отдельный сервис, лезть в базу — явно не ответственность самого класса с данными
про GRASP побольше написано, но тоже довольно компактно и, в отличии от другой всем известной аббревиатуры, это имхо вполне можно применять как рецепты "как делать", а не только как признаки того, как делать не надо.
Короче, пользуясь случаем рекомендую.
Здравствуйте, VTT, Вы писали:
VTT>Здравствуйте, nikda, Вы писали:
N>>Пусть есть некоторый класс MyData, который представляет данные предметной области (например: Отчёт, Лабиринт, Игровая доска, ...) N>>Соответственно он предоставляет через свои методы данные внешним объектам (например данные отчёта, структуру лабиринта, позицию игрока, клетки доски и т.д.)
N>>Вопрос в том куда помещать метод создания самого объекта класса MyData: N>>* в сам класс MyData N>>* в другой класс, например MyDataCreator
N>>Если в сам класс MyData, то не нарушает ли это принцип SRP ? VTT>Если этот метод тривиален, то не нарушает, если нетривиален, то нарушает.
N>>Если другой класс, то не вносит ли это излишнюю сложность ? VTT>Если этот метод не нужен, то вносит, если нужен, то не вносит.
Хранение данных и предоставление какой то частичной информации из обьекта уже нарушение SRP.
В идеале должно быть — POCO обьект хранящий данные и к нему ещё один обьект с функциями которые принимают обьект как параметр и возвращают из него нужную информацию
Автор(ы): Крэг Ларман
