Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Маю архітектурне питання

Є в мене класс Application який містить та використовує клас PasswordRealise через абстрактний інтерфейс PasswordInterface. Таким чином, як я розумію в мене виходить що граф залежностей становиться не ациклічним бо до классу Application доводиться імпортрувати файл класу PasswordRealise щоб там його ініціалізувати, які прийоми є щоб позбавитися залежності, чи то нормально коли так?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

викиньте те ооп у смітник вже :)

Так а архітектурне питання де?

Коментар порушує правила спільноти і видалений модераторами.

Я так розумію ти використовуєш інтерфейс тут для того, щоб приховати деталі реалізації та позначити функціонал, для якого всі будуть мати доступ, в не залежності від імплементації.
Тобто, усі хто будуть використовувати змінну password, будуть мати лише два методи інтерфейсу PasswordInterface, і не знатимуть про існування PasswordRealize.

Якщо ти питаєш про залежність на PasswordRealize, то вона в тебе по-любому буде, адже ти не можеш створити instance інтерфейсу замість классу. Питання, лише в якому місті.
Щодо місця, де ініціалізувати password, то як варіант робити це в DI контейнері. В залежности від мови програмування, можна підібрати собі фреймворк для зручності.
І тоді ти робиш собі instance в контейнері, а в Application заінджектиш по протоколу цю змінну. Application не знатиме про (і не імпортуватиме) PasswordRealize, бо ти всюди юзаєш тип змінної як інтерфейс.

Наприклад, в Котліні (для DI з Kodein):

Об’явив в DI контейнері:

val di = DI {
    bindSingleton<PasswordInterface> { PasswordRealize() }
}

Зробив ін’єкцію в Application:

class Application { val password by di.instance<PasswordInterface>() }

Вуаля)

Або ж просто через конструктор передати інстанс без DI фреймоврків через інтерфейс)

Не зрозуміло, чи це троллінг, але якщо ні — не потрібно класу Application нічого знати про PasswordRealise, бо він у конструкторі приймає PasswordInterface, і будь-хто, хто ініціалізує Application, зможе передати туди інстанс PasswordRealise

Окрема частина тролінгу — неймінг сутностей.

Підписатись на коментарі