Ребят, а вот смотря на последние неты, где в интерфейсах

можно логику описывать и реализовывать, какое отличие все же остались у абстрактного класса от интерфейса?

ужасное мракобесие - сувать реализацию в интерфейсы

Класс может реализовать несколько интерфейсов, а наследоваться только от одного класса. Так было и так есть даже в послднем .нете. Кроме того, многие DI контейнеры рассчитаны на работу с интерфейсами, если тебе важно их использовать, выбора особо нет

соглашусь

Я на собесах отвечаю так. За общим различиям с старых версий конечно. Интерфейсы используются как гарантированное предоставление реализации общего интерфейса определенного функционала. IDispose IEnumerable, где интерфейс отвечает за строгий регламент функционала. и каждый экземпляр обязан его реализовывать. А абстрактный класс используется для выявления общей иерархии класса, часто с предоставлением гарантии отсутствия экземпляра базовых обьектов. Вроде так {сотрудник абстрактный класс, клерк офисный наследует класс сотрудника} в данном случаи неопределнного сотрудника быть не может, и мы не хотим наличия его экземпляров.

Просто шарпы пытаются наконец-то ввести ООП в язык в полном объеме. Это попытка сделать множественное наследование только через жопу.

множественное наследование - тот еще способ выстрела себе в ногу)

Даешь агрегацию

Нежелание использовать множественное наследование - это как использовать писюн на половину.

еще скажи композиция

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

А шо имеешь против ?

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

😉

Зачем ты в чате такой плохой платформы тогда сидишь?)

Когда пет проект делал - пришлось брать или шарпы или плюсы, а плюсы были более медленные по разработке.

жить можно с чем угодно, главное что бы удобно в разработке было, мне, к примеру, требовалось вот такое множественное наследование классов только раза 2 и то интерфейсы вполне покрывают эту проблему

Ну вот могу рассказать как мы используем это... У нас это превратилось, фактически, в миксины и, в лучших традициях новомодных веяний но задолго до того как они стали новомодными, у нас сам конечный класс, из которого будет расти синглтон программы, при старте на основе конфига собирает себе наследование (вернее не конечный, а предпоследний). Очень удобно получается.

Какая-то дичь. зачем все это? "Собирает себе наследование"

шо бы было чем перед джунами пришедшими понтоваться)

простите, что ? обычно вы подняли конфиг с сервера и на его основании приложение сконфигурировалось. А у вас тут какие-то подобъекты, ооп. Что такое "базовый класс сервера" ?

при старте сервера, на основе данных из конфига, через DI прокидываются нужные классы. и никаких фабрик не нужно тогда

Ну смотрите... Допустим у вас микро (или не сильно микро) сервисная архитектура. У вас в одном из базовых классов есть методы работы с шиной данных (транспорт неважен). Так-же у вас есть класс, который выступает веб сервером. Как вы строите архитектуру? В классе текущего сервера создаете свойство для траснпорта и свойство для веб сервера, дальше их настраиваете, обмениваетесь коллбеками или как-то по другому связываете логику... В рантайме на старте. Теперь если-бы у вас было множественное наследование - вы-бы засунули 2 этих класса себе в родителей и связали-бы все уже на этапе компаилтайма и у вас небыло-бы this.Transport.sendMessage(...), а this.sendMessage(...)

Смешно. DI - это фабрика 2.0, поэтому вы сказали оксюморон.

все что вы написали понятно, непонятно только что такое класс текущего сервера. Накидайте что там. Потому что пока непонятно что у вас там кроме адаптера к шине лежит

Ну у вас точно будет синглтон где будут лежать все подключившиеся клиенты, допустим. И т.д. - это и есть класс текущего сервера.

C чего вы решили, что GC вешается? Она даже умеет в закольцованные ссылки.

Она-то умеет. Вешается она просчитывать это все.

На сколько знаю, в юнити там все грустно с этим. и там своя надстройка вместо GC сделана. или дополнительная, ибо там ссылки висят на сцене, и они убираются по другому

Ну это проблема текущего кора и нежелания делать нормальный ABI, а без него совместное владение объектами работает через жопу. Но владение объектами нужно только для GC, так что да.. Это проблемы GC