Маю архітектурне питання
Є в мене класс Application який містить та використовує клас PasswordRealise через абстрактний інтерфейс PasswordInterface. Таким чином, як я розумію в мене виходить що граф залежностей становиться не ациклічним бо до классу Application доводиться імпортрувати файл класу PasswordRealise щоб там його ініціалізувати, які прийоми є щоб позбавитися залежності, чи то нормально коли так?
6 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментаріввикиньте те ооп у смітник вже :)
Так а архітектурне питання де?
Коментар порушує правила спільноти і видалений модераторами.
Я так розумію ти використовуєш інтерфейс тут для того, щоб приховати деталі реалізації та позначити функціонал, для якого всі будуть мати доступ, в не залежності від імплементації.
Тобто, усі хто будуть використовувати змінну 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
Окрема частина тролінгу — неймінг сутностей.