Сохранение и загрузка объектов без нарушения инкапсуляции

Вы упомянули Мементо. Существует вариант под названием Snapshot, задокументированный Грандом. Вот диаграмма классов UML:

Person будет Originator в шаблоне.

Вы можете сбросить экземпляр Memento в двоичный объект в базе данных.

Обратите внимание, что Memento — это внутренний класс Создателя. createMemento/setMemento — это своего рода одиночный get/set, который может нарушать инкапсуляцию, если вы пурист. Однако пакет информации (Memento), используемый при вызове, представляет собой интерфейс без никаких методов, поэтому гарантируется инкапсуляция состояния Originator's. Это может работать даже с ORM, если вы правильно отобразите его.

Конечно, это кажется большой работой, чтобы избежать get/set. Ваш пример Person/age не совсем реалистичен (не лучшая модель Person). Совершенно нормально раскрывать возраст или дату рождения человека, и раскрытие этого свойства для сохранения объекта было бы в порядке. Инкапсуляция не означает ничего не раскрывать. Это означает, что не выставляйте слишком много деталей.

Например, давайте использовать не age, а Person.birthday. Это может быть сохранено внутри как строка в формате ГГГГ-ММ-ДД или с использованием объекта Date. Такая деталь не будет раскрыта (она будет инкапсулирована). Это также сделано для того, чтобы вы могли изменить его и не затрагивать клиентов вашего класса. Все, что вы скрываете, может быть изменено без негативного влияния на клиентов.

Открывая день рождения человека, вы говорите "Я беру на себя риск того, что у человека всегда будет день рождения". Эта часть открыта, и поэтому ее будет трудно изменить, не нарушая работы клиентов.

Редактировать после комментариев

Публичные методы (например, save и load) в Person могут заботиться об операции сохранения/загрузки базы данных. У них будет доступ к закрытым полям (age) и они смогут выполнять свою работу. Вы сказали, что не используете ORM, поэтому просто делаете это сами.

Аллен Холуб написал несколько статей именно на эту тему. Он предлагает Builder и то, что он называет паттерном Reverse Builder.

Как это будет работать в вашем случае, Person будет нести ответственность за создание представления о себе. Другими словами, вы определяете интерфейсы PersonImporter и PersonExporter для перемещения данных в объект Person и из него. Эти классы в основном являются частью дизайна Person. Так:

interface PersonImporter {

    public int getAge();

    public String getId();
}

interface PersonExporter {

    public void setDetails(String id, int age);

}

class Person {

    private int age;
    private String id;

    public Person(PersonImporter importer) {
        age = importer.getAge();
        id = importer.getId();
    }

    public void export(PersonExporter exporter) {
        exporter.setDetails(id, age);
    }

}

Это не устраняет геттеры и сеттеры полностью, а контролирует их с помощью интерфейсов.

статья Holub

Это то, что я думаю, может быть не идеально.

Инкапсуляция делается для сокрытия данных. Возможно, вы просто не хотите, чтобы кто-то установил неправильное значение атрибута age.

Возможно, вы можете ввести класс-оболочку, который используется внешним кодом, и только этому классу разрешено использовать ваш класс Person.

Если вы создаете файл с классом-оболочкой public, скажем, PersonWrapper, который предоставляет геттер и сеттер для возраста. Но эти геттеры и сеттеры могут иметь желаемую логику проверки, например, какие значения могут быть установлены для age, кто может и т. д. В том же файле класс Person может быть определен как private, но с простыми геттерами и сеттерами для параметра age. Ваш PersonWrapper должен использовать геттер и сеттер класса Person только при некоторых предопределенных условиях.

Таким образом, вы можете иметь лучшую инкапсуляцию.

одним из способов здесь является использование классов картографов. Создайте PersonMAP, который сопоставляет класс с таблицей и инкапсулирует все операции с базой данных в этом классе.

Я действительно не понимаю, как использование геттеров/сеттеров нарушает инкапсуляцию. Геттеры и сеттеры уважают инкапсуляцию. На самом деле, они являются средством для достижения этого.