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

они всегда являются типами

любой класс, интерфейс или абстрактный класс являются типами

способом создания нового типа

https://habrastorage.org/files/d29/bad/2de/d29bad2deaec4f7da9ca1e08f7e47641.png

У тебя есть три класса, три типа, разные реализации нотификаций.

все они входят во множество нотификаторов - абстрактный тип который объеденяет конкретные штуки.

с типами можно делать много разных прикольных вещей

аля композиции типов

``` class Base64 implements Encoder, Decoder;

например вот, есть объект, который является объединением типов Encoder и Decoder

ести типы "свои" и "чужие". Скажем с точки зрения твоего ядра все типы будут твоими, а типы предоставляемые библиотеками - чужими. Чужим типам доверять не стоит. Но если ты знаешь что там бородатые дядьки то можно расслабиться. А вот твоим трем ребятам следует обезопасить себя от возможных изменений в интерфейсах твоих типов, твоего ядра, для своих проектов. Делается это введением "своих" типов, на которые они все могут завязать

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

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

я упоролся

вообще когда говорят "абстракции" и тд, это подразумеваются как раз таки интерфейсы а "абстрактный класс" == "скелет", и то как @fes0r выше написал, интерфейсы уже могут иметь дефолтные методы и вот скоро будут приватные дефолтные методы иметь тоже так что по большей степени абстрактный класс это такой себе костыль и недопонимание..

ну в былые времена в C++ были только абстрактные классы... и делать композиции типов можно было за счет множественного наследования от абстрактных виртуальных классов

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

но абстрактные классы они оставили просто потому что "ну а че нет"

а поддерживать расширяемые классы это боль, следовательно абстрактный класс это двойная боль)

бооооооль

но абстрактные классы они оставили просто потому что "ну а че нет"

чтобы не сломать то что раньше было, поэтому и оставили

чтобы не сломать то что раньше было, поэтому и оставили

я про первые версии java

там много вещей таких в языке

когда они воровали из C++

ну не воровали))

заимствовали)

я вот щас как раз удаляю на проекте один абстрактный класс, от которого пошел рак

абстрактные кансерогены

https://www.jetbrains.com/phpstorm/whatsnew/#definitions

2016.3 же

ну тайтл страницы кривой)

Никогда не понимал(и до сих пор не понимаю) вопроса отличия абстрактного класса от интерфейса. Ну, то есть что здесь спрашивают? Это концептуально разные вещи, где интерфейс описывает как с этим классом работать, а абстрактный класс - что-то вроде костыля в ооп, когда при проектировании иерархии нужна стартовая точка для наследования, где этот класс хранит общие свойства. Абстрактный класс Human. Дочерние man, woman. Не можем же мы создать некоторое существо Human, не уточнив его специфики. Значит пусть он будет абстрактный и имеет какой-то базовый набор свойств. А любители гуманоидов пусть не задают ему никаких абстракций. Как-то так я это вижу. Можете бить ногами.

Абстрактный класс - рудимент

> Не можем же мы создать некоторое существо Human, не уточнив его специфики. можем

> Значит пусть он будет абстрактный и имеет какой-то базовый набор свойств. это не нужно

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

раньше это лет 30 назад

наследование вместо композиции?

ну просто оно еще так-то юзается там, где лень делать структурные типы

Никогда не понимал(и до сих пор не понимаю) вопроса отличия абстрактного класса от интерфейса. Ну, то есть что здесь спрашивают? Это концептуально разные вещи, где интерфейс описывает как с этим классом работать, а абстрактный класс - что-то вроде костыля в ооп, когда при проектировании иерархии нужна стартовая точка для наследования, где этот класс хранит общие свойства. Абстрактный класс Human. Дочерние man, woman. Не можем же мы создать некоторое существо Human, не уточнив его специфики. Значит пусть он будет абстрактный и имеет какой-то базовый набор свойств. А любители гуманоидов пусть не задают ему никаких абстракций. Как-то так я это вижу. Можете бить ногами.

кого ты хочешь наследовать от Human?

у меня на этот случай как раз задачка есть)

дааа, норм задачка кстати)

а как быть с трансгендерами?)

а как быть с трансгендерами?)

а они не люди?

сексист... ?

ну есть Human -> Woman, Human -> Man

как называть притеснение трансгендеров?

хехе

ну есть Human -> Woman, Human -> Man

скажи это брата-сестрам Вачевски

а трансгендеров куда?) у них то свойства общие

уже сестрам Вачевски

ну они все еще братья... технически... то что их пипки вывернули наизнанку и напичкали гормнов это все же больше космитические изменения

допишу в задачку

"Сделай мне такое: бармен Вася хочет стать Василисой и пойти учиться на первую трансгендерную космонавтку в космический вуз"

хм

звучит прям как требования на проекте!

Куда вас понесло...

https://pbs.twimg.com/media/BB9WlqBCIAEWC_O.jpg

дельфинопластика

вот еще один челендж

тут без множественного наследования уже никак

хуйня ваше наследование

В моем примере такого не предусматривалось.

https://s-media-cache-ak0.pinimg.com/564x/2d/58/f1/2d58f1bebb284c52abbc1f2b6d4899f8.jpg

ну короч надо сделать тип новый ManBearBig который будет лишь композицией трех типов

А зачем?

ERROR: S client not available

А для тех кто скажет "так можно от млекопитающего отнаследовать" есть добрый сосед человек паук

А зачем?

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

наследование классов мол

любых, абстрактных или не очень

Ну, так вы молотком борщ мешаете.

че б и нет

Это не очень реальные примеры из жизни. Да и само собой не бывает ничего идеального.

Это не очень реальные примеры из жизни. Да и само собой не бывает ничего идеального.

у меня был юзер. Потом их решили разделить на покупателей и продавцов

норм кейс для наследования вида User <- Customer | Merchant

?

зачем там наследование вообще?)

да погоди ты

мне мнение надо узнать у человека

Сразу скажу, что я так себе программист, поэтому не мощни сильно. Ну, допустим.

через месяц клиент решил "а хер с ним пусть им можно будет и то и то. Кастомер может стать мерчантом и наоборот. надо только недостающие части заполнить при первом логине"

тру стори, было такое)

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

и новый счет заводить

я вот честно скажу - наследование тут меня подвело

и задача которая без наследования заняла бы 4 часа работы заняла у меня добрых 3 дня разработки + регрессионное тестирование всего приложения

Ну, подождите. Он это сказал "потом". А проектируем мы систему до этого "потом".

Ну, подождите. Он это сказал "потом". А проектируем мы систему до этого "потом".

месяц, один месяц.

можно было сделать за 4 dev + 2 QA а вышло 24 dev + 16 QA

проект с рейтом $100/h

Полегче, полегче)

оверхэд 34 часа

$3400

из-за плохого решения

причем и то и то решение имплементить одинаково

Будто ты мне счет выставляешь)

по времени

мне просто важно что бы ты понял что не важно что будет потом. Если ты этого не знаешь и можно сделать более гибко и с теми же временными затратами - лучше делать более гибко