структура данных внутри объекта

Question

У меня есть простой вопрос об объектно-ориентированном дизайне, но у меня есть некоторые трудности с поиском лучшего решения. Скажем, у меня есть объект с некоторыми методами и довольно большим количеством свойств, возможно, объект Employee. Свойства, такие как FirstName, Address и т. Д., Которые указывают структуру данных. Тогда могут быть методы на объекте Employee, такие как IsDueForPromotion (), который в большей степени носит ОО-характер.

Смешивать это неправильно для меня, я хотел бы разделить их, но я не знаю, как это сделать хорошо. Я думал о том, чтобы поместить все данные свойств в структуру и иметь внутренний объект структуры внутри объекта employee, private EmployeeStruct employeeData ...

Однако я не уверен, что это действительно хорошая идея, может быть, мне просто нужно иметь все методы и свойства в одном классе и продолжать с этим. Разве я усложняю ситуацию, если отделяю данные от методов?

Я был бы очень признателен, если у кого-то есть идеи по этому поводу.

J

Answer 1

Не была ли идея OO-design объединить данные и соответствующие методы вместе?

Вопрос здесь в том, как объект Employee мог знать о начале рекламной акции. Я предполагаю, что метод принадлежит где-то еще классу, который имеет информацию, чтобы определить это. действительно глупый пример Manager m = new Manager(); manager.IsDueForPromotion(employeeobject);

Но другие методы для доступа к полям Employee принадлежат этому классу.

Вопрос, который я поднял о IsDueForPromotion, зависит от вашего приложения и от того, является ли ваш Сотрудник POJO или DTO или если к нему могут быть также подключены более «интеллектуальные» методы. *

Answer 2

если ваши данные развиваются медленнее, чем поведение, вы можете попробовать использовать шаблон посетителя:

class Employee {

    String name;
    String surName;
    int age;
    // blah blah
    // ...getters
    // ...setters
    // other boilerplate

    void accept(EmployeeVisitor visitor) {
        visitor.visitName(name);
        visitor.visitAge(age);
        // ...
    }
}

interface EmployeeVisitor {

    void visitName(String name);

    void visitAge(int age);
}

с этим дизайном вы можете добавлять новые операции без изменения класса Employee. Проверьте также используйте образец спецификации.

Answer 3

Основным принципом объектно-ориентированного программирования является группирование данных, таких как FirstName и Address, с функциональностью, которая сопровождает их, например, IsDueForPromotion (). Неважно, сколько данных содержит объект, он все равно будет содержать эти данные. Единственный раз, когда вы хотите удалить данные из объекта, это если он не имеет никакого отношения к этому объекту, например, сохранить имя компании в объекте Employee, когда он должен храниться в объекте компании.

Answer 4

Ну, OO - это способ группировки данных и функций, которые принадлежат друг другу в одном месте. Я действительно не понимаю, почему вы сделали бы исключение «когда данных много». Единственная причина, по которой я могу придумать, это разборчивость.

Лично я думаю, что вы бы усложнили задачу, придумав отдельную структуру для хранения ваших данных. Я также не согласен с тем, что это будет хорошей практикой. С одной стороны, то, как класс реализует свою функциональность или хранит свои данные, должно быть скрыто от внешнего мира. С другой стороны, если данные принадлежат классу, неестественно хранить их в чем-то вроде структуры.

Может быть интересно взглянуть на имеющиеся у вас данные и посмотреть, можно ли их смоделировать в меньшие доменные объекты. Например, иметь объект Address, который содержит значение улицы, номера дома, штата, почтового индекса, страны и т. Д. Таким образом, ваш объект Employee будет просто содержать объект Address. Затем объект Address можно повторно использовать для объектов вашей компании и т. Д.

Answer 5

Объектные операции (методы) должны использовать свойства. Поэтому я чувствую, что лучше оставить их вместе.

Если для него не требуются свойства, это своего рода служебный метод, и его следует определить в другом программном обеспечении, например в некотором вспомогательном классе.