VS
И если что не обижайтесь. Я перехожу с пхп на js. И прежде всего ищу ответы для себя. Так как пока не понимаю, как связать мои старые убеждения(с пхп) с новыми походами на js.
Size: a a a
2021 January 06
Y
а у вас мова про яке ооп? те що описав Алан Кей, чи те що Страуструп викотив?
Ми намагаємось отримати визначення того, що таке "сучасне" ООП)
VS
Как поломать? При чем тут завязка на реализацию?
Чего Вы хотите достигнуть когда используете наследование (зачем оно вообще нужно)?
Чего Вы хотите достигнуть когда используете наследование (зачем оно вообще нужно)?
Переиспользование реалзизации.
Но можно заменить это на композицию обьектов
Но можно заменить это на композицию обьектов
Y
Vlad Sobenko
Переиспользование реалзизации.
Но можно заменить это на композицию обьектов
Но можно заменить это на композицию обьектов
Не реализации, а кода (может Вы это и имели в виду).
Если наследование это просто переиспользлвание кода, то почему оно что-то ломает?
Вынесение кода в функцию это тоже переиспользлвание. Или функции тоже что-то ломают?
Если наследование это просто переиспользлвание кода, то почему оно что-то ломает?
Вынесение кода в функцию это тоже переиспользлвание. Или функции тоже что-то ломают?
VS
Не реализации, а кода (может Вы это и имели в виду).
Если наследование это просто переиспользлвание кода, то почему оно что-то ломает?
Вынесение кода в функцию это тоже переиспользлвание. Или функции тоже что-то ломают?
Если наследование это просто переиспользлвание кода, то почему оно что-то ломает?
Вынесение кода в функцию это тоже переиспользлвание. Или функции тоже что-то ломают?
Зависимость от интерфейс значительно меньше, чем от реализации.
Y
Vlad Sobenko
Переиспользование реалзизации.
Но можно заменить это на композицию обьектов
Но можно заменить это на композицию обьектов
Композиция это и есть наследование, просто другой способ.
Почему тогда есть два способа наследования, через классы и композицию? И почему во всех книгах по ООП советуют всегда когда возможно предпочитать композицию наследованию классов?
Почему тогда есть два способа наследования, через классы и композицию? И почему во всех книгах по ООП советуют всегда когда возможно предпочитать композицию наследованию классов?
VS
Композиция это и есть наследование, просто другой способ.
Почему тогда есть два способа наследования, через классы и композицию? И почему во всех книгах по ООП советуют всегда когда возможно предпочитать композицию наследованию классов?
Почему тогда есть два способа наследования, через классы и композицию? И почему во всех книгах по ООП советуют всегда когда возможно предпочитать композицию наследованию классов?
Если мы зависим от абстракции при композиции. То реализацию можно подменить, тоесть мы от неё не зависим. Как подменить родителя при наследовании?
Мне кажется совсем не то же самое
Мне кажется совсем не то же самое
Y
Vlad Sobenko
Зависимость от интерфейс значительно меньше, чем от реализации.
Вы пишете о несвязанных вещах. Мы говорили о наследовании. И вы опять не ответили не на один вопрос. Почему повашему наследование, если это просто переиспользование кода, что-то ломает? И ломают ли функции что-то, ведь они это тоже способ переиспользлвания кода?
VS
Вы пишете о несвязанных вещах. Мы говорили о наследовании. И вы опять не ответили не на один вопрос. Почему повашему наследование, если это просто переиспользование кода, что-то ломает? И ломают ли функции что-то, ведь они это тоже способ переиспользлвания кода?
Что я не ответил? Перечитайте ещё раз
DN
Композиция это и есть наследование, просто другой способ.
Почему тогда есть два способа наследования, через классы и композицию? И почему во всех книгах по ООП советуют всегда когда возможно предпочитать композицию наследованию классов?
Почему тогда есть два способа наследования, через классы и композицию? И почему во всех книгах по ООП советуют всегда когда возможно предпочитать композицию наследованию классов?
Война — это мир, свобода — это рабство, незнание — сила
Y
Vlad Sobenko
Что я не ответил? Перечитайте ещё раз
Я спросил почему наследование что-то ломает, а Вы начали мне рассказывать про интерфейсы
VS
Я спросил почему наследование что-то ломает, а Вы начали мне рассказывать про интерфейсы
а где про ломает? А увидел
Y
Vlad Sobenko
Мы завязывется на реализацию родительского класса, она может поломать нашу.
Вот тут Вы писали
АП
Vlad Sobenko
Мне бы интересно было бы на твой. Как ты реализовываешь композит, прокси паттерны например?
Прокси в js есть на уровне языка
Для компоновщика абстрактный базовый класс не нужен, как и для любого другого паттерна
Абстрактный базовый класс это всего лишь выделение интерфейса, который нужно реализовывать. Для языков с динамической типизацией это вообще не нужно, потому что "если что-то ведёт себя как утка, то это утка"
Для компоновщика абстрактный базовый класс не нужен, как и для любого другого паттерна
Абстрактный базовый класс это всего лишь выделение интерфейса, который нужно реализовывать. Для языков с динамической типизацией это вообще не нужно, потому что "если что-то ведёт себя как утка, то это утка"
VS
Прокси в js есть на уровне языка
Для компоновщика абстрактный базовый класс не нужен, как и для любого другого паттерна
Абстрактный базовый класс это всего лишь выделение интерфейса, который нужно реализовывать. Для языков с динамической типизацией это вообще не нужно, потому что "если что-то ведёт себя как утка, то это утка"
Для компоновщика абстрактный базовый класс не нужен, как и для любого другого паттерна
Абстрактный базовый класс это всего лишь выделение интерфейса, который нужно реализовывать. Для языков с динамической типизацией это вообще не нужно, потому что "если что-то ведёт себя как утка, то это утка"
Ну так нет средств языка, чтобы это удобно реализовать и поддерживать.
АП
Vlad Sobenko
Ну так нет средств языка, чтобы это удобно реализовать и поддерживать.
Что именно нужно удобно реализовывать? Я же говорю, абстрактный класс (или интерфейс) нужен для языков со статической типизацией, при динамической тебе не нужно заботиться о проведении типов, достаточно реализовать методы с нужной сигнатурой
Чего тебе не хватает для composite?
Чего тебе не хватает для composite?
VS
Сделать можно всё, но поддерживать как. Были бы интерфейсы, то при изменении интерфейса - язык/стат анализатор/компилятор бы меня оповестил, что такие то обьекты уже не следуют контракту
VS
Я спросил почему наследование что-то ломает, а Вы начали мне рассказывать про интерфейсы
Родитель например имеет доступ к стейту ребенка и может изменить его так, что он будет непригодным при вызове операции ребенка.
VS
Что именно нужно удобно реализовывать? Я же говорю, абстрактный класс (или интерфейс) нужен для языков со статической типизацией, при динамической тебе не нужно заботиться о проведении типов, достаточно реализовать методы с нужной сигнатурой
Чего тебе не хватает для composite?
Чего тебе не хватает для composite?
Я вот пока и разбираюсь с этим. Это и не даёт покоя, не стыкуется с моим пониманием вопроса. Но офк это имеет место быть, и Кей вроде и писал, что динамические типы больше подходят по его ооп.
JK
Прокси в js есть на уровне языка
Для компоновщика абстрактный базовый класс не нужен, как и для любого другого паттерна
Абстрактный базовый класс это всего лишь выделение интерфейса, который нужно реализовывать. Для языков с динамической типизацией это вообще не нужно, потому что "если что-то ведёт себя как утка, то это утка"
Для компоновщика абстрактный базовый класс не нужен, как и для любого другого паттерна
Абстрактный базовый класс это всего лишь выделение интерфейса, который нужно реализовывать. Для языков с динамической типизацией это вообще не нужно, потому что "если что-то ведёт себя как утка, то это утка"
В том то и дело, что js не имеет встроенных инструментов для контроля возможностей уток, хотя бы как в том же GO - без объявления имплементации