Чи повинні серіалізація та десеріалізація бути відповідальністю класу, який підлягає серіалізації?

Наразі я перебуваю на етапі (пере) проектування декількох класів моделей програми C # .NET. (Модель як у M MVC). Модельні класи вже мають безліч добре розроблених даних, поведінки та взаємозв'язків. Я переписую модель з Python на C #.

У старій моделі Python я думаю, що бачу бородавку. Кожна модель знає, як серіалізувати себе, і логіка серіалізації не має нічого спільного з рештою поведінки будь-якого з класів. Наприклад, уявіть собі:

• Imageклас з .toJPG(String filePath) .fromJPG(String filePath)методом
• ImageMetaDataклас з а .toString()та .fromString(String serialized)метод.

Ви можете собі уявити, як ці методи серіалізації не зближуються з рештою класу, але тільки клас може гарантовано знати достатню кількість даних для серіалізації.

Чи загальноприйнята практика для класу знати, як серіалізувати та десяриалізувати себе? Або я пропускаю загальну схему?

Я, як правило, уникаю, щоб клас з кількох причин знав, як серіалізувати себе. По-перше, якщо ви хочете (де) серіалізувати в / з іншого формату, тепер вам потрібно забруднити модель такою додатковою логікою. Якщо доступ до моделі здійснюється через інтерфейс, ви також забруднюєте контракт.

public class Image
{
    public void toJPG(String filePath) { ... }

    public Image fromJPG(String filePath) { ... }
}

Але що робити, якщо ви хочете серіалізувати його до / з PNG та GIF? Тепер класом стає

public class Image
{
    public void toJPG(String filePath) { ... }

    public Image fromJPG(String filePath) { ... }

    public void toPNG(String filePath) { ... }

    public Image fromPNG(String filePath) { ... }

    public void toGIF(String filePath) { ... }

    public Image fromGIF(String filePath) { ... }
}

Натомість мені зазвичай подобається використовувати візерунок, подібний до наступного:

public interface ImageSerializer
{
    void serialize(Image src, Stream outputStream);

    Image deserialize(Stream inputStream);
}

public class JPGImageSerializer : ImageSerializer
{
    public void serialize(Image src, Stream outputStream) { ... }

    public Image deserialize(Stream inputStream) { ... }
}

public class PNGImageSerializer : ImageSerializer
{
    public void serialize(Image src, Stream outputStream) { ... }

    public Image deserialize(Stream inputStream) { ... }
}

public class GIFImageSerializer : ImageSerializer
{
    public void serialize(Image src, Stream outputStream) { ... }

    public Image deserialize(Stream inputStream) { ... }
}

На даний момент, одним із застережень із такою конструкцією є те, що серіалізатори повинні знати identityоб'єкт, який він серіалізує. Деякі кажуть, що це поганий дизайн, оскільки впровадження протікає поза класом. Ризик / винагорода за це дійсно залежить від вас, але ви можете трохи налаштувати класи, щоб зробити щось подібне

public class Image
{
    public void serializeTo(ImageSerializer serializer, Stream outputStream)
    {
        serializer.serialize(this.pixelData, outputStream);
    }

    public void deserializeFrom(ImageSerializer serializer, Stream inputStream)
    {
        this.pixelData = serializer.deserialize(inputStream);
    }
}

Це більше загальний приклад, оскільки зображення зазвичай мають метадані, які йдуть разом з ним; такі речі, як рівень стиснення, кольоровий простір тощо, що може ускладнити процес.

Серіалізація - це складова з двох частин:

1. Знання про інстанціювання структури структури ака .
2. Знання про збереження / передачу інформації, необхідної для інстанції класу, механіки .

Наскільки це можливо, структура повинна зберігатися окремо від механіки . Це збільшує модульність вашої системи. Якщо ви закопуєте інформацію про №2 у своєму класі, то ви порушуєте модульність, оскільки тепер ваш клас повинен бути модифікований, щоб йти в ногу з новими способами серіалізації (якщо вони йдуть разом).

У контексті серіалізації зображення ви б зберігали інформацію про серіалізацію окремо від самого класу та зберігали її, скоріше, в алгоритмах, які можуть визначати формат серіалізації - тому різні класи для JPEG, PNG, BMP тощо. Якщо завтра новий алгоритм серіалізації приходить разом з вами просто кодує цей алгоритм, і ваш класний договір залишається незмінним.

У контексті IPC ви можете тримати свій клас окремо, а потім вибірково заявляти інформацію, необхідну для серіалізації (за анотаціями / атрибутами). Тоді ваш алгоритм серіалізації може вирішити, чи використовувати JSON, буфери протоколів Google або XML для серіалізації. Він навіть може вирішити, використовувати парсер Jackson або свій власний аналізатор - є безліч варіантів, які ви легко отримаєте, розробляючи модульний модуль!