Так что "в ООП не принято использовать наследование" - это не верно.

Ну вообще как раз таки наследование - это один из столпов в общепринятом понимании ООП. В "изначальном" ООП в Smalltalk по Алану Кею тоже наследование использовалось.

общепринятой? ты про википедию?) впрочем, холивар на эту тему профитнее вести в джава чатиках) никак не в го.

А вот что наследование является плохой практикой - это уже друго разговор.

Сейчас будет спор композиция против наследования?

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

и тут мы пришли к другому срачу: а зачем?

то, что оно используется, или что оно есть, не значит ровным счётом ничего. Вон в пхп трейты тоже используют. Это не значит, что этот высер (трейты) чем-то оправдан

Для удобства

Для удобства

Во всех случаях?

Во всех случаях?

Я не готов говорить за все случаи

общепринятой? ты про википедию?) впрочем, холивар на эту тему профитнее вести в джава чатиках) никак не в го.

И про неё тоже. Да в любой книге по ООП, в любом ООП языке будет упомянуто наследование. Даже в Smalltalk.

Откуда я знаю какие у вас случаи)

В бизнес логике часто приходится использовать наследование

Я не готов говорить за все случаи

Тогда для каких кейсов имеется ввиду "удобство"?

Для удобства

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

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

Скорость

Низкий порог входа

Относительно каких нибудь плюсов или джавы

то, что оно используется, или что оно есть, не значит ровным счётом ничего. Вон в пхп трейты тоже используют. Это не значит, что этот высер (трейты) чем-то оправдан

Нет, это означает что практически в любом ООП языке (ну кроме Go) обязательно придётся столкнуться с наследованием.

Нет, это означает что практически в любом ООП языке (ну кроме Go) обязательно придётся столкнуться с наследованием.

это связано лишь с низкими порогами входа :) никак не с тем, что это прям столп какой-то

без него можно жить вполне, да

во множестве языков можно столкнуться с синглтонами. ну чёт такая себе логика

это связано лишь с низкими порогами входа :) никак не с тем, что это прям столп какой-то

В C++ есть наследование. А у этого языка порог входа далеко не низкий. Так что порог входа тут не причём. А вот то, что наследоваие - это вполне привычный интсрумент, практически тот самый "столп" уже как раз причём. И синглтоны тоже будут попадаться. То есть такие вещи вообще проигнорировать просто не получится. Ну если только за пределы Go не вылезать никуда, кроме сишки.

мой косяк, херово написал. я скорее не за язык вещал, а за этот самый мифический правильный ооп.

Нет, это означает что практически в любом ООП языке (ну кроме Go) обязательно придётся столкнуться с наследованием.

Rust?

Rust?

так его вроде в этом чатике не любят?

проще сделать наследование, чем думать как иначе. Проще сделать синглтон, чем думать как иначе и т.д.

Нет, это означает что практически в любом ООП языке (ну кроме Go) обязательно придётся столкнуться с наследованием.

а что Go это ООП язык?

мой косяк, херово написал. я скорее не за язык вещал, а за этот самый мифический правильный ооп.

Вообще это всё довольно расплывчато, субъективно и не формализованно. Так что можно спокойно говорить, что нет никакого определения "тру ооп"

а что Go это ООП язык?

Кто-то считает, что нет. Я к примеру считаю, что да.

а что Go это ООП язык?

местами.

Вообще это всё довольно расплывчато, субъективно и не формализованно. Так что можно спокойно говорить, что нет никакого определения "тру ооп"

поэтому и написал, что мифический.

Алан Кей вроде бы вообще выделял основным столпом посылку сообщений, которая вообще является лишней абстракцией фактически.

так его вроде в этом чатике не любят?

У чатика нет официальной позиции по этому вопросу

У чатика нет официальной позиции по этому вопросу

учту на будущее

чатик неофициальный

Самый безумный чат по яп

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

Из всех, в которых я нахожусь

Самый безумный чат по яп

В каком смысле безумный?

И почему ООП считают сложным.

В каком смысле безумный?

В плане актива

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

тут люди дела делают прост

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

Все зависит от умения, на самом деле. Кто-то может и космические аппараты на Fortran запускать. Ну, или уже умел...

А ядерные ракеты? Там до сих пор иногда софт чуть ли не на ADA. И нифига никакого ООП, а бизнес-логика - недецкая!

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

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

Удваиваю

Наследование - это не про Go, к счастью

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

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

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

приведи пример. попахивает

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

Это была явная необходимость или больше привычка из других ЯП?

Только я не эмулировал. Просто делал по другому

Задача была очень специфическая.

Это была явная необходимость или больше привычка из других ЯП?

нет необходимости в наследовании. И быть не может by design. так что больше привычка

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

Задача была очень специфическая.

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

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

В обратном направлении это тоже работет.

нет необходимости в наследовании. И быть не может by design. так что больше привычка

Я ж к этому и топлю)

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

нет необходимости в наследовании. И быть не может by design. так что больше привычка

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

Парни, извините за флуд. У всех гугл и яндекс открываются ?

+

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

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

ERROR: S client not available

подскажите как прочитать файл, если он больше чем ram

подскажите как прочитать файл, если он больше чем ram

Построчно

Или побайтово

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

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

Или побайтово

есть примеры?

хорошо, что я не знаю таких слов

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

А что кстати помешает этим апологетам сделать такое же безобразие с композицией в Go?

есть примеры?

file, err := os.Open("file.ext") if err != nil { println(err) } defer file.Close() scanner := bufio.NewScanner(file) buf := make([]byte, 0, 1024*1024) scanner.Buffer(buf, 10*1024*1024) for scanner.Scan() { print(scanner.Text()) }

Парни, извините за флуд. У всех гугл и яндекс открываются ?

У меня пока открываются из Питера. Но, благодаря депутатке Яровой, скоро могут и перестать. :)

file, err := os.Open("file.ext") if err != nil { println(err) } defer file.Close() scanner := bufio.NewScanner(file) buf := make([]byte, 0, 1024*1024) scanner.Buffer(buf, 10*1024*1024) for scanner.Scan() { print(scanner.Text()) }

спасибо

То есть глубоко вложенная композиция конечно лучше глубокой иерархии наследования, но всё равно довольно печально на мой взгляд. Потому что опять же изменение в начале иерархии может затронуть и скорее всего затронет всех "потомков".

Знает ли кто про какую нибудь либу для проверки сложности пароля для реализации фидбэка пользователю о безопасности его пароля?

Знает ли кто про какую нибудь либу для проверки сложности пароля для реализации фидбэка пользователю о безопасности его пароля?

самый безопасный пароль это его отсутствие

самый безопасный пароль это его отсутствие

давай не будем, а?

давай не будем, а?

вообще очень много было на эту тему, не понятно что ты имеешь ввиду

Знает ли кто про какую нибудь либу для проверки сложности пароля для реализации фидбэка пользователю о безопасности его пароля?

ну куча ж либ, для JS надо ж?

вообще очень много было на эту тему, не понятно что ты имеешь ввиду

дело в том что "123456" это не очень безопасный, но валидный пароль, и пользователю надо об этом при выборе пароля сообщить.

ну куча ж либ, для JS надо ж?

Go

дело в том что "123456" это не очень безопасный, но валидный пароль, и пользователю надо об этом при выборе пароля сообщить.

буква, цифра, спец символ и кровь девственницы хочешь?

Знает ли кто про какую нибудь либу для проверки сложности пароля для реализации фидбэка пользователю о безопасности его пароля?

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

буква, цифра, спец символ и кровь девственницы хочешь?

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

Go

ну первое что нашел

https://github.com/nbutton23/zxcvbn-go

например комбинация даты рождения и фамилии это тоже херовый пароль

искать zxcvbn

https://github.com/nbutton23/zxcvbn-go

оо, норм, мерси

например комбинация даты рождения и фамилии это тоже херовый пароль

слишком много вариантов твоего субъективного "плохого пароля", поэтому наверное придется самому писать

слишком много вариантов твоего субъективного "плохого пароля", поэтому наверное придется самому писать

Писать самому - плохой подход

использовать только пароли плохой подход

использовать только пароли плохой подход

+

многофакторные авторизации!