Бывают ли времена, когда объединение бизнес-логики и структур данных - хорошая идея?

Question

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

Мой вопрос: Является ли это хорошей практикой или лучше отделить логику и структуру от начала, если есть разумный потенциал, который изменит бизнес-логика?

Мой интуитивный инстинкт состоит в том, чтобы сохранить логику отдельно, поскольку это, по-видимому, следует принципу открытого/закрытого, а сочетание структуры и логики, по-видимому, нарушает SRP.

Answer 1

Это довольно субъективный вопрос и, по сути, бросается в глаза объектно-ориентированное программирование, в котором объединение данных и логики является нормой. Обычно я предпочитаю сохранять структуру данных отдельно от связанной логики, если структура данных используется для связи с другой системой (по существу, с использованием интерфейса определения интерфейса), или если есть случаи, когда логика специфична для очень специфического контекста.

В таких случаях, как списки, очереди и словари в объектно-ориентированных языках, данные и логика объединяются для формирования сплоченного объекта и взаимозависимы. В этих случаях разделение логики и данных на самом деле не имеет смысла в объектно-ориентированном языке, таком как C#.

Однако в других конкретных случаях было бы разумно отделить данные и логику. Например, если вы создаете объект счета-фактуры и его нужно обрабатывать с помощью любого количества нисходящих систем, то вы не хотите вводить логику для этих нижестоящих систем в свой Счет. Вместо этого эта логика должна быть отделена.

Итак, я думаю, что короткий ответ: это действительно зависит от того, что вы делаете.

Надеется, что это помогает, Nate