Хм ... а для каких паттернов нужно наследование?

ООП

Похоже, только один, в вики я больше не нашел таких, которые бы требовали наследование.

Есть 3 базовых принципа ООП - Инкапсуляция, Наследование, Полиморфизм. Нету одного из них - это не ООП

Есть 3 базовых принципа ООП - Инкапсуляция, Наследование, Полиморфизм. Нету одного из них - это не ООП

/voteban

Ой

Я просто нажал, оно само открылося )000)0)

Есть 3 базовых принципа ООП - Инкапсуляция, Наследование, Полиморфизм. Нету одного из них - это не ООП

На самомо деле, нет. Вот в js наследования нет (не было), а ооп есть)

в js ты перекрываешь методы у общего родителя

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

В моей книге написано, что тот же шабаонный метод на го не написать

через прототип

Но это не наследывание, а прототипирование

все потомки будут наследовать общее поведение

В моей книге написано, что тот же шабаонный метод на го не написать

что за книга?

Синяя Книга Богдана

Цвет наследования - Синий

На самомо деле, нет. Вот в js наследования нет (не было), а ооп есть)

Ну не было там ООП. Там была попытка повторить синтаксис явы, ага.

К примеру Алан Кей считает что без наследования ООП впринципе безсмысленно

Есть 3 базовых принципа ООП - Инкапсуляция, Наследование, Полиморфизм. Нету одного из них - это не ООП

ООП - это макакеноинкапсуляция, макакенонаследование и макакенополиморфизм, прошу не путать

ООП - это макакеноинкапсуляция, макакенонаследование и макакенополиморфизм, прошу не путать

Поясни

К примеру Алан Кей считает что без наследования ООП впринципе безсмысленно

Хм ... а будут ли пруфы?

Поясни

Да что тут пояснять. Инкапсуляция в ООП так себе, наследование данных и реализации - худшее, что могли вообще придумать дизайнеры ЯП, ну а полиморфизм подтипов - херня полная по сравнению с параметрическим полиморфизмом.

все потомки будут наследовать общее поведение

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

К примеру Алан Кей считает что без наследования ООП впринципе безсмысленно

А ещё статитечская типизация - от сатаны, стоит ли доверять таким авторитетам. Да что уж там, стоит ли вообще доверять авторитетам?

а при наследовании иначе?

А ещё статитечская типизация - от сатаны, стоит ли доверять таким авторитетам. Да что уж там, стоит ли вообще доверять авторитетам?

ну и полиморфизм же, чо за набросы

Да что тут пояснять. Инкапсуляция в ООП так себе, наследование данных и реализации - худшее, что могли вообще придумать дизайнеры ЯП, ну а полиморфизм подтипов - херня полная по сравнению с параметрическим полиморфизмом.

Ну колхоз дело добровольное, согласен, что в некоторых местах ООП - лютое зло, но есть и места где за императивщину надо бить.

в эликсире все красиво, нет проблемы с полиморфизмом, все через матчеры

Ну, при наследовании логика одного шаблона наследуется другим, а объекты создаются напрямую от шаблона. В случае прототипа - от объекта.

Правда оказалось, что прототипы в 99% случаев не очень удобны и все скатилось к шаблонам опять.

Ну колхоз дело добровольное, согласен, что в некоторых местах ООП - лютое зло, но есть и места где за императивщину надо бить.

ООП в джаве та же императивщина, только с классами

что за книга?

Книга юного сурка про паттерны, же.

Надоело читать фигню. Вы трёте из пустого в порожнее. Пора завязывать этот бессмысленный базар про наследование и ООП. С помощью админа или без.

ООП в джаве та же императивщина, только с классами

Ну она мультипарадигменный язык, хотя точнее стала им по мере развития. Да и трудно назвать исключительно ООП языки.

Ну она мультипарадигменный язык, хотя точнее стала им по мере развития. Да и трудно назвать исключительно ООП языки.

> исключительно ООП языки уверен что вы назовёте всё ту же императивщину с классами

> исключительно ООП языки уверен что вы назовёте всё ту же императивщину с классами

Смаллтолк? Но я его наискосок пробегал, так что утверждать не могу

о, сегодня про гуй срача уже нет?

начался за ООП

ООП - это слияние данных и поведения в одну сущность (в отличии от функциональщины), а также объекты и сообщения, которыми они обмениваются. Все остальное - это уже конкретные реализации и детали имплементации.

завтра ФП и хаскель?

предлагаю тему на вброс - сколько зарабатывает начинающий гошник?

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

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

а как вы хеджируете риски?

а как вы хеджируете риски?

не надо тут матерными словами разбрасываться да

Смаллтолк? Но я его наискосок пробегал, так что утверждать не могу

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

я просто гошник из финтеха, тут иначе нельзя

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

А где-то оно есть? Это магическое декларативное программирование? А то мне казалось, что все попытки что-то сделать разваливаются о суровую реальность.

ООП - это слияние данных и поведения в одну сущность (в отличии от функциональщины), а также объекты и сообщения, которыми они обмениваются. Все остальное - это уже конкретные реализации и детали имплементации.

Единственная тру реализация ООПа по Кею кроме Смолтолка известная мне - Ерланг. Чо ты там про функциональщину говорил?

Единственная тру реализация ООПа по Кею кроме Смолтолка известная мне - Ерланг. Чо ты там про функциональщину говорил?

а в чем разница между эрлангом и коболом?

А где-то оно есть? Это магическое декларативное программирование? А то мне казалось, что все попытки что-то сделать разваливаются о суровую реальность.

Ну в чистом виде вряд-ли, но модель она на то и модель.

а в чем разница между эрлангом и коболом?

в названии

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

А где-то оно есть? Это магическое декларативное программирование? А то мне казалось, что все попытки что-то сделать разваливаются о суровую реальность.

Императивная и функциональная парадигмы сами по себе неполноценны.

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

ООП и функциональщина/императивщина ортогональны.

Императивная и функциональная парадигмы сами по себе неполноценны.

@demeliorator, а ты на это что имеешь сказать? У меня вот словарный запас меня подвёл

Декларативная парадигма просто неосуществима, судя по всему. Выбор между неполноценным и неосуществимым вроде не такой сложный?

Ерланг это язык, главной фичей которого являются вездесущие акторы - те самые объекты обменивающиеся сообщениями.

завтра ФП и хаскель?

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

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

надежды и мечты, да

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

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

если и правда нужен ответ - разверните вопрос

@demeliorator, а ты на это что имеешь сказать? У меня вот словарный запас меня подвёл

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

если нет - советую угомонитьс уже сейчас

Ерланг это язык, главной фичей которого являются вездесущие акторы - те самые объекты обменивающиеся сообщениями.

Тут уже нюансы терминологии, если для ООП достаточно только меседжей и объектов, то Ерланг - ООП, согласен. Но определения не столь однозначны.

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

а то заладили со своими парадигмами

ERROR: S client not available

зарплаты в другом чате

кто сказал что javascript говно?

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

https://github.com/tmrts/go-patterns

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

Кстати, можно сделать что-то в таком духе: https://play.golang.org/p/y-bEcA0yME6

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

Ну это сделать можно, но через Ж и лучше так не делать. Посути реализовать виртуальную таблицу методов, копирование структур и т.д. Не могу представить зачем.

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

Ну какая зарплата может быть у человека который не знает элементарные конструкции?

Ну какая зарплата может быть у человека который не знает элементарные конструкции?

в смысле не знает блокчейн?:)

лох, щегол и неудачник?

в смысле не знает блокчейн?:)

Внезапно да

И? Где тут облом?

И? Где тут облом?

Ну вооде нет примера в той репе для этого патерна.

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

Покажите пример где этот шаблонный метод может понадобится

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

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

Так собирайте без "шаблонного метода". Что вам мешает?

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

коллега, а покажите мне пример для того, чтобы я понял, зачем оно вам понадобилось

Так собирайте без "шаблонного метода". Что вам мешает?

Ну вот предположим, у меня есть базовый метод парсера, он делает такие вещи: 1. Считывание данных 2. Преобразование в унифицированный формат 3. Чистка данных 4. Преобразование. 5. Транформация данных в итоговый результат И у меня есть базовый парсер. Далее мне нужен еще один, в котором я выполняю дополнительную трансформацию (скажем, высчитываю дополнительное поле) и второй, в котором более строго чищу данные.

ну

Шаблонный метод как раз весьма неплохо подходит под эту задачу.

это хорошо

И почему бы вдруг тебе не хватило бы встраивания?

Ну вот предположим, у меня есть базовый метод парсера, он делает такие вещи: 1. Считывание данных 2. Преобразование в унифицированный формат 3. Чистка данных 4. Преобразование. 5. Транформация данных в итоговый результат И у меня есть базовый парсер. Далее мне нужен еще один, в котором я выполняю дополнительную трансформацию (скажем, высчитываю дополнительное поле) и второй, в котором более строго чищу данные.

Вам рассказать как эта задача решается композицией или сами додумаетесь?

коллега, а покажите мне пример для того, чтобы я понял, зачем оно вам понадобилось

это очень общий паттерн, один из самых общих. При желании любой код, где функция принимает/возвращает не пустой интерфейс вместо конкретного типа можно трактовать как реализацию шаблонного метода. Но это всё гуманитарщина конечно

Вам рассказать как эта задача решается композицией или сами додумаетесь?

Всякую задачу можно решить на тьюринг полном языке, это софистика. С таким подходом можно на brainfuck писать и радоватся жизни.

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

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

а это принципиально - ссылки на функции или ссылка на интерфейс с методами?

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

напомнило Маяковского. Я достаю из широких штанин дубликатом бесценного груза.

а это принципиально - ссылки на функции или ссылка на интерфейс с методами?

нет, но ссылку на интерфейс я бы передал в яве. тут у нас существуют функции сами по себе, а не как методы класса, поэтому я класс отбросил, как ненужную сущность

напомнило Маяковского. Я достаю из широких штанин дубликатом бесценного груза.

Смотрите, завидуйте - go generate...

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

Ну вот предположим, у меня есть базовый метод парсера, он делает такие вещи: 1. Считывание данных 2. Преобразование в унифицированный формат 3. Чистка данных 4. Преобразование. 5. Транформация данных в итоговый результат И у меня есть базовый парсер. Далее мне нужен еще один, в котором я выполняю дополнительную трансформацию (скажем, высчитываю дополнительное поле) и второй, в котором более строго чищу данные.

Объявить сигнатуру функции и впердолить в структуру переменную этого типа? Черезжопно, конечно, но можно. Хотя в го настаивают на парадигме sharing-by-calling