Slava
очень часто такое бывает полезно
Sergey
Бесспорно, но речь про дизайн
Slava
я, к примеру, часто делаю интерфейс с приватным методом, чем запрещаю людям пихать в мои функции то что я сам не разрешил
Slava
сам интерфейс при этом публичный
Sergey
Ну, немного другой кейс, на мой взгляд вполне логичный
Sergey
Сам то интерфейс паблик
Daniel
Если тип приватный - это гарантия, что объект, и ссылка на объект, не появятся иначе, как через соответствующий метод
Daniel
Способ заставить вызывать "конструктор"...
Anonymous
Способ скрыть быдлокод!
Dmitriy
Oleg
Это код, с которым взаимодействовать невозможно.
Код, который по своим понятиям общается.
Код, с которым придется бороться не на жизнь, а на смерть, т.к. по-нормальному от него чего-то добиться не получится.
dev_sheep
dev_sheep
Только вот чтобы понять принцип Лисков, по-началу надо жестко набухаться. Ну, во всяком случае в том определении, которое есть в википедии 😁
dev_sheep
объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы
dev_sheep
Википедия, мать ее
Alexander
Понятно всё, вы чо. Но практического смысла не очень много, если уже есть какой-то опыт разработки
Alexander
А если нет, то людям непонятно
Alexander
😬
Maxim
Aleksandr
Alexander
практического не очень много, особенно сейчас. теоретический наверное есть
Anton
но это же solid
Anton
я думаю в нем есть смысл даже сейчас
Alexander
но это неточно(с) :)
Anton
)))
Maxim
Maxim
кто-нибудь юзал container/heap?
Maxim
он потокобезопасный?
Maxim
вроде как нет, ну ладно
Aleksandr
практического не очень много, особенно сейчас. теоретический наверное есть
эм, на принципе лисков практически все работает. это соответствие интерфейсу. ты интерфейсы не видишь в либах?
Alexander
то как оно работает – это конкретная реализация, и решения авторов языка. тезисы лисков настолько абстаркты что применимы много к чему. на практике нас интересуют детали
dev_sheep
очень понятно написано
я вполне себе понимаю это, но читая определение с википедии это непонятно моментально, во всяком случае у меня так было, хоть и давненько
dev_sheep
в отличие от остальных принципов
Aleksandr
то как оно работает – это конкретная реализация, и решения авторов языка. тезисы лисков настолько абстаркты что применимы много к чему. на практике нас интересуют детали
ну вот - практически во всех распространенных языках это реализовано интерфейсами.
Alexander
More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address titled Data abstraction and hierarchy
Alexander
до 87 года не было интерфейсов или чего-то подобного в ЯП?
Aleksandr
да, не только интерфейсы, но и наследование где оно есть итд. в общем в разных языках есть реализации, и на этих реализациях основано современное программирование. Поэтому тезис что это не актуально, не верен.
Alexander
тезис не полезен на практике и замутняет мозг неофитам из-за своей абстрактности, не неофитам он тоже уже не нужен, потому что они столкнулись уже с конкретными реализациями. его полезность тока теоретическая чтобы абстрактно дискутировать о программировании в общем, без конкеретики.
Alexander
чем мы и занимаемся последние -цать минут :)
Michael
[last news]
Pilosa: open source, distributed bitmap index in Go
Читал, но не понял, зачем оно.
Aleksandr
тезис не полезен на практике и замутняет мозг неофитам из-за своей абстрактности, не неофитам он тоже уже не нужен, потому что они столкнулись уже с конкретными реализациями. его полезность тока теоретическая чтобы абстрактно дискутировать о программировании в общем, без конкеретики.
надо просто пояснять тезис на примере реализации. если он сложно сформулирован для абстрактного понимания, это не значит, что он не полезен - наоборот он крайне нужен и полезен
Aleksandr
как может быть не полезен тезис, реализациями которого ты пользуешься каждый день в работе?
Alexander
см. выше
Alexander
это не реализации, наоборот принцип описывает абстрактно то что уже есть в ЯП
Alexander
И зачем тезис объяснять, если вы не в академии? на практике то он не нужный, лучше объяснить что-такое интерфейсы и как они реализованы в конкретных ЯП и почему так.
Aleksandr
это не реализации, наоборот принцип описывает абстрактно то что уже есть в ЯП
и? кодификация того, что уже присутсвует также важна
Alexander
важна, в академиях
Alexander
я про практику программирования, которое ремесленный навык, а не инженерный или абстрактно математический
Aleksandr
тогда теоретические книги по парадигмам прогарммирования можно вообще не читать. только учебники по конкретным языкам. остальное оставим академикам.
Alexander
это правда. можно не читать, но можно почитать если интересно теоретическую базу прокачать
Aleksandr
это правда. можно не читать, но можно почитать если интересно теоретическую базу прокачать
крайне не согласен. теория сильнее практики прокачивает навыки программирования. можно на практике экспериментальным путем найти какие то хорошие решения, но прочитав теорию можно узнать как надо, до чего сам не додумался. Возможно немного в сторону ушли от Лисков
Alexander
ну ок, у меня протовоположно мнение. только практика может прокачать в таком прикладном скилле как программирование, теория не будет понятна и будет применятся неправильно без солидной практики
Alexander
На самом деле принцип подстановки Лисков очень простой и большинство программистов придерживается его на интуитивном уровне. Но академическое определение действительно может ввести в ступор :)
Alexander
на этом предлагаю закончить спор, каждый высказал своё мнение
Anton
и все-таки LSP не только о наследованиии, а еще и о API, так что не вижу тут капитанства в нем
dev_sheep
На самом деле принцип подстановки Лисков очень простой и большинство программистов придерживается его на интуитивном уровне. Но академическое определение действительно может ввести в ступор :)
наконец-то я хоть от кого-то усышал это последнее предложение :D
Alexander
я ничего против Liskov, SOLID и абстрактных знаний не имею, если чо
пугает просто религиозность в отношении к ним и черезмерное внимание к принципам а не к реальной практике (смотри посты от разных авторов про то как надо правильно писать SOLID-программы)
Мерль
Используете ли вы системы сборки?
ничего – 15
👍👍👍👍👍👍👍 45%
make – 13
👍👍👍👍👍👍 39%
другое – 3
👍 9%
gb – 1
▫️ 3%
gulp o_O – 1
▫️ 3%
gradle O_o
▫️ 0%
👥 33 people voted so far.
Constantine️
ааа, только один вариант
Constantine️
ну как так
webpack
Ruslans
Oleg
Я использую make, а внутри уже и webpack и xgettext и много чего еще
Мерль
Я использую make, а внутри уже и webpack и xgettext и много чего еще
Для того, чтобы собирать и фронтенд и бэкенд?
Мерль
ну тогда норма
Мерль
У меня есть знакомый, который грейдлом go собирает
Илья
у меня как то make + gb
Илья
тк одного костыля недостаточно
Alexey
Подскажите пожалуйста.
Мне нужно внутри go выполнить команду ffmpeg.
На вход я передаю mp4 файл в виде resp.Body от http запроса, который выполнился до этого куска кода
cmd := exec.Command("ffmpeg",
"-f", "lavfi",
"-i", "anullsrc=channel_layout=stereo:sample_rate=44100",
"-i", "pipe:0",
"-shortest", "-c:v", "copy", "-c:a", "aac",
"output.mp4")
cmd.Stdin = resp.Body
cmd.Run()
На выходе после cmd.Run() хочу получить объект io.Reader, как результат работы ffmpeg, который можно было бы потом скормить телеграм боту
reader := tgbotapi.FileReader{Name: "test", Reader: output, Size: int64(contentLength)}
file := tgbotapi.NewDocumentUpload(messageChatID, reader)
код по ffmpeg выше сейчас сохраняет на диске output.mp4, тем саммым показывая, что передача resp.Body в пайп работает.
Нокак сделать, чтобы на выходе еще был результат обработки в виде объекта, а не файла, я не понимаю 😒
Мерль
хотелось бы что-то типа build.go в корне проекта
Мерль
было бы очень удобно
Alexey
пробовал... но не понятно в какой переменной ловить аутпут?
Мерль
