Здравствуйте, sergii.p, Вы писали:


SP>Момент с дублированием проявляется в следующем примере
SP>

SP>struct OpenedConnection {
SP>    ip: String,
SP>    port: u32,
SP>    is_ssl: bool,
SP>}

SP>struct ClosedConnection {
SP>    ip: String,
SP>    port: u32,
SP>    is_ssl: bool,
SP>}
SP>

SP>т е просто дублируем поля, которые можно и не дублировать. Конечно если разные состояния должны хранить разный набор полей, то это и не проблема. Но зачастую всё же поля повторяются. Можно завести отдельную структуру, где перечислить все повторяющиеся поля, но это уже не такое чистое решение. Чем же мне решение на rust и приглянулось. Взгляните на классический паттерн State по GoF. Один класс на фасад, один интерфейс и по одному классу на каждое состояние. Минимум 4 сущности. Только это превращает классический State в антипаттерн.
Тут просто корявая модель в ООП. Классическая ошибка — использование наследования-генериков вместо mixin. Ведь у тебя есть два абсолютно разных типа (а тип с разными параметрами — это и есть два типа), то их и нужно явно описывать. Что-то вроде

struct ConnectionDetails {
    ip: String,
    port: u32,
    is_ssl: bool,
}

struct Connection {
    details: ConnectionDetails, // опционально, можно и не хранить.
    bytesSent: u32,
    bytesReceived: u32,
...
}

И тогда проблем с повторным вызовом open нет, и вообще open не нужен — открытие происходит в конструкторе Connection, который на вход берёт ConnectionDetails.
И генерики не нужны. KISS.

Здравствуйте, sergii.p, Вы писали:


SP>Момент с дублированием проявляется в следующем примере
SP>

SP>struct OpenedConnection {
SP>    ip: String,
SP>    port: u32,
SP>    is_ssl: bool,
SP>}

SP>struct ClosedConnection {
SP>    ip: String,
SP>    port: u32,
SP>    is_ssl: bool,
SP>}
SP>

SP>т е просто дублируем поля, которые можно и не дублировать. Конечно если разные состояния должны хранить разный набор полей, то это и не проблема. Но зачастую всё же поля повторяются. Можно завести отдельную структуру, где перечислить все повторяющиеся поля, но это уже не такое чистое решение. Чем же мне решение на rust и приглянулось. Взгляните на классический паттерн State по GoF. Один класс на фасад, один интерфейс и по одному классу на каждое состояние. Минимум 4 сущности. Только это превращает классический State в антипаттерн.
Тут просто корявая модель в ООП. Классическая ошибка — использование наследования-генериков вместо mixin. Ведь у тебя есть два абсолютно разных типа (а тип с разными параметрами — это и есть два типа), то их и нужно явно описывать. Что-то вроде

struct ConnectionDetails {
    ip: String,
    port: u32,
    is_ssl: bool,
}

struct Connection {
    details: ConnectionDetails, // опционально, можно и не хранить.
    bytesSent: u32,
    bytesReceived: u32,
...
}

И тогда проблем с повторным вызовом open нет, и вообще open не нужен — открытие происходит в конструкторе Connection, который на вход берёт ConnectionDetails.
И генерики не нужны. KISS.

ЗЫЖ Твоя штука никакого отношения к gof State не имеет. State — это всё-таки динамическое состояние. Когда внезапно сокет может закрыться, напирмер, а у тебя событие по таймеру, или из бд что-то загрузилось и в зависимости от того чего загрузилось надо делать что-то немного разное. compile time тут никаким боком.