Один класс шифрует, второй енкодит, но работают в связке

Один класс шифрует, второй енкодит, но работают в связке

Это синонимы)

Нет

Нет

Ну английский язык с вами не согласен)

?

Нет

encode - шифровать, decode - раскодировать

шифриует = енкодит

Есть два статик класса, как сделать третий которые бы использовал методы с того и другого типа инкапсуляция?

Вопрос был как сделать ехтендс к двум статик классам, множественное наследование

encode - шифровать, decode - раскодировать

Не совсем, разные слова там

Ответьте как сделать, а я скажу в чем разница

Вопрос был как сделать ехтендс к двум статик классам, множественное наследование

у тебя по прежнему без фреймворка?

у тебя по прежнему без фреймворка?

Да, я вообще другой орм взяла

надо еще DI взять

и научиться использовать

И статику не юзать ага)

А так я не понял надо в третьем классе слить первые два? Тогда композиция.

Один класс шифрует, второй енкодит, но работают в связке

сделать один и назвать MyCryptClass :)) в php нет множественного наследования

Или если в оба добавить черты третьего то трейт

Или если в оба добавить черты третьего то трейт

ноооооу

лукавый Макс

Или если в оба добавить черты третьего то трейт

Ой трейты еще не знаю

Ой трейты еще не знаю

ине надо

А di в статик классе это норм?)

лукавый Макс

Да норм всё с третами, не ссы я и Тейлор стто раз так делали)

Просто один класс шифрует, второй енкодит)

С каких пор трейты зло

С каких пор трейты зло

с тех пор как их придумали

Encrypt encode

С каких пор трейты зло

У него пунктик)

У него пунктик)

один из сотни пунктиков

Da

Так а шо с трейтами не так?

Так а шо с трейтами не так?

они призваны закрывать дыры в архитектуре

Или дыры в языке который не может в множественное наследование

Или дыры в языке который не может в множественное наследование

нет

множественное сделали в си++,поскольку не было интерфейсов там

Так причем интерфейсы

Так Лара вся в трейтах Даже бутить их умеет Оо

Так Лара вся в трейтах Даже бутить их умеет Оо

ну Ларка это тот еще ворох говнокода.

но это еще один мой пунктик:)

Ану делись своими пунктиками Интересно

Го архитектурные срачи перед сном

Dependency Inversion. Зависимости должныбыть только абстракциями. и стандартный вывод из этого - только интерфейсы.

верно? понятно?

они призваны закрывать дыры в архитектуре

из ада притом

из ада притом

красиво аналогизируешь :)

Го архитектурные срачи перед сном

чот писал, писал, а толку нет :)

Ну за трейты спорить не буду За di тоже))

не. я хотел сказатьчто зависимость на реальныйкласс - нормальное дело

это тоже абстракциявполне себе

не для общей библиотеки конечно.а для своего проекта.

эх. никто перчатку срача не поднимает. видимо спать пора :)

хз про че сраться

нуя тут попираю чуть ли не сам солиД

правда лишь его трактовку. все прям за интерфейсы топят

хз причем тут интерфейсы

solid не про них же вовсе

Кто то использовал ассоциации?

даже злосчастный ISP не про интерфейсы, которые interface

Кто то использовал ассоциации?

ты про что

ооп

и что ты под этим подразумеваешь

ERROR: S client not available

хз причем тут интерфейсы

ну вот самое популярное обьяснение Д принципана русском - https://blog.byndyu.ru/2009/12/blog-post.html

там однозначно - абстракция есть интерфейс

депенденси на реальныйкласс -фуу

Александр Бындю это кто вообще

явно не псевдоним Мартина Фаулера

ну он умныйтоварищ

ммм

ну трактовать может кто угодно и как угодно

я думаю легко найду иу великих про интерфейсы

и что ты под этим подразумеваешь

Чем она отличается от агрегации

поэтому я с почтением отношусь к первоисточникам только

Чем она отличается от агрегации

ты имеешь ввиду композицию и агрегацию?

https://martinfowler.com/articles/injection.html

я думаю легко найду иу великих про интерфейсы

найдешь конечно

вот тебе от Фаулера

тоже интерфейсы

ты имеешь ввиду композицию и агрегацию?

да, говорят еще ассоциация есть

https://martinfowler.com/articles/injection.html

там вообще java

а как быть с языками где нет интерфейсов в принципе?

да какая разница

там ведь тоже вполне можно соблюдать SOLID :)

там абстрактныеклассы и множественное наследование

нет

да, говорят еще ассоциация есть

Агрегация и композиция частные случаи ассоциации, в любом ООП при прогинге по сути используется, к чему вопрос? Примеры интересны?

абстрактные классы в языке в 99% случаев подразумевает наличие интерфейсов

а множественное наследование вообще скорее исключение чем правило

абстрактные классы в языке в 99% случаев подразумевает наличие интерфейсов

видимо нам надо в чатик ооп :)

да ну, не охото

Агрегация и композиция частные случаи ассоциации, в любом ООП при прогинге по сути используется, к чему вопрос? Примеры интересны?

Да можно было бы и на примеры глянуть=

А в питона где в конструктор по дефолту можно классы передавать, это di и есть?

да