Чем все закончилось-то с тимлидом?
Я сказал что не смогу сделать проект в срок и уволился.
Соболезную.
ООП это идея. Это не класс собака, котрый наследуется от животного. Это именно идея о том, что так единственно правильно. И как это часто бывает с идеями, они не всегда подходят всем и всегда.
Если у тебя ООП головного мозга и ты во всем видишь объект, то ты освоил ООП. Если же ты просто видишь задачу и начинаешь ее решать на ходу придумывая алгороитм, то скорее всего объект у тебя не сформируется и на ООП похоже не будет. Что никак не влияет на успешность решения задачи.
То что требовал от тебя твой тимлид это почти наверняка не ООП, а его представления об ООП. такое бывает когда в конторе текучка и потом кому то нужно будет разбираться в чужом коде. Вот тимлид и хочет чтоб заранее было написано как ему удобнее. При этом его представление об ООП может отличаться от чьего то еще.
В общем, надо было спросить что конкретно хочет отдельно взятый тимлид, а не искать ООП, которого нет.
>В общем, надо было спросить что конкретно хочет отдельно взятый тимлид, а не искать ООП, которого нет.
Кнеижку зитоле написать, "ООП Которого Нет".
Таких книжек уже навалом. Проблема в том, что два человека используя одни и те же догмы могут по разному реализовать одну и ту же задачу. Просто выберут разные уровни абстракции. И получится что оба писали ООП, но получилось нихуя не похоже.
С функциональным программированием все проще.
ОХ, бля, ОП, была похожая ситуация, тимлид так заебал, что пришлось уволиться, затем он притащил своих корешей и со временем пытался подсидеть техдира, но сам был выпидорнут. Один в один хуйню мне эту же втирал, твоего не георгий случаем?
Ну я спрашивал естественно, что не так, но он отвечал общими фразами, когда человек говорит много и нихуя конкретно.
> твоего не георгий случа
Нет, не Георгий.
поэтому дропнул ооп в пользу функциональщины, ооп для пидоров.
>Проблема в том, что два человека используя одни и те же догмы могут по разному реализовать одну и ту же задачу. Просто выберут разные уровни абстракции. И получится что оба писали ООП, но получилось нихуя не похоже.
Неа, проблема как бы не в этом таки.
Это уже следствие.
Проблема в том, что ООП подход, не является универсальным.
Вернее так, он неспособен описывать реальность, в принципе. По крайней мере когда речь идет о программных и аппаратных средствах.
ООП - это красивая концепция для описания ЗАДАЧ и БИЗНЕС ПРОЦЕССОВ, в виде графиков там.
Но не для программирования, не для написания кода эти задачи решающего.
процедурщина, это когда не используется объект как состояние, а состояние передается аргументами между процедурами?
есть такая памятка, что, может быть что-то не так: когда у процедуры больше 3 аргументов.
есть такая памятка, что, может быть что-то не так: когда у процедуры больше 3 аргументов.
И как с вакансиями дела?
Нет. Такая же путаница.
даже дело не в том, сколько аргументов, а например
foo(obj)
... do something
... blah(obj)
blah(obj)
... do something
... blahblah(obj)
>Я не надеюсь что увижу тут дельный ответ,
Правильно делаешь, ходить по книжкам не научишься. Взял, сука, и пошел ==> Взял и научился ООП.
>меня серьезно дрочили по поводу ООП
ООП — это раковая опухоль. А твой тимлид даун. Впрочем, если вы писали на Java, то тимлида уже нельзя вылечить. У него метастазы в мозге.
Например?
Как с деньгами обстоит вопрос?
смысл ООП упрощения разработки для быдлеца, ускорение разработки, адаптация тупых пезд, не имеющих абстрактного мышления. Есть много подходов к разработке, пишешь в том стиле, в котором умеешь. Многие программы вообще логичней в процедурном стиле создавать, особенно трансформирующие системы, где данные на вход поступают, обработанные данные имеем на выходе.
Вообще-то процедурщина требует меньше абстрактного мышление, чем ооп. Поэтому собственно и обучение никогда с ооп не начинают
>процедурщина требует меньше абстрактного мышление, чем ооп
Абсолютно такого же мышления она требует. Проблема в размере проекта, а не в языке.
Поебались
Зачем вообще придумали этот ООП? В ассемблере нету никаких объектов, там одни процедуры, команды и переменные.
>жаваскрипт
ООП головного мозга.
Осталось что бы кто нибудь сгенерил картинку на этот мем.
Да. Примерно про это и говорю.
обьект - массив
класс - способ задания схемы пассива указатлелй на данные, на методы и на другие массивы
класс - способ задания схемы пассива указатлелй на данные, на методы и на другие массивы
Про регистры забыл.
Ну и? Открыл Америку, так это и реализовано под оберткой, в CLR, например.
америка - израиль
Ты — хуй
«Еврейской крови нет в крови моей.
Но сыплю в раны перец
я всем антисемитам, как еврей,
и потому - я настоящий немец!»
«Ничто во мне про это не забудет!
«Интернационал» пусть прогремит,
когда навеки похоронен будет
последний на земле антисемит.»
>жс — функциональный язык программирования
Эта шутка никогда не устареет.
И стек!
И прерывания!
OOP по своей сути процедурщина, хуле он хотел то?
Процедурщина это когда процедурой меняется состояние чего нибудь что ты не указываешь явно. Функциональщина возвращает данные которыми ты сам распоряжаешься. ООП использует процедурный стиль. Так что хуй знает вообще чего твой тимлид-долбоеб хотел.
Ты сам долбоеб, надо было конкретно спросить что ему надо.
А почему нет? Многие языки предоставляют функциональность в той или инной степени, в жс для этого дохуя возможностей.
Чувствую аналогичное говно в голове по поводу ООП. Никто блядь вообще не знает, что это такое. В программировании вообще много где аналогичный визг, а на практике никто точно толком не знает, как это делать и зачем, и надо ли вообще.
А за такое наследование надо в жопу ебать.
Делает такой приём/паттерн твой код понятнее, проще, в том числе для других, яснее выражает решаемую проблему, удешевляет разработку?
Да: используй его.
Нет: не используй его.
Это не упоминая библиотек типо react и immutable.js, где все сделано в функциональном стиле.
Да там только функции как объекты первого класса, только и всего. Для хеллоуволдов уровня фибоначчи этого может и достаточно, но писать что-то объёмное в функциональном стиле на языке, где:
1. Not everything is an expression
2. function в качестве лямбда-оператора FUNCTION, Карл!
3. коллбек-хелл вместо монад
4. уёбищная типизация
5. отсутствуют плюшки типа каррирования,
будет только js-хипстер с подворотами, для которого функционально - значит ни так как фсе.
Алсо, first-class functions сейчас есть вообще везде, но мы не называем джаву функцинальным яп. да, там нельзя определить функцию вне класса, в отличии от s, но это не так уж существенно
>function в качестве лямбда-оператора
c разморозкой, уже давно есть (() => "yoba")()
Ты знаешь что такое монада? Объяснить сможешь? Джуну к примеру.
Для «объекта» не существует формального определения. ООП вообще никак не формализовано. Это набор ad hoc практик, интуиций и советов бывалых охотников в стиле «чтобы копье лучше било мамонта, его должна обоссать девственица в полнолуние».
Минимально необходимым для ООП, по всей видимости, должно быть определение "модули как первоклассные объекты". А вот достаточным является хуй знает что. Для Анала Кея, например, это была динамическая сгущёнка и модель акторов. Хотя этот вариант не прижился и догнивает себе в обжС. Для лисперов это был CLOS и мультиметоды. Для джява-индусов это абстракпроксисинглтонбины.
Вообще, если разобраться, то необходимость наследования надумана и прилеплена как-то сбоку. Просто статическим дебилам нужна была какая-то система, но ничего умнее сабтайпинга тогда не придумали, вот и обмазались наследованием. По этой причине, динамическим петушкам половина паттернов из GoF вообще не нужна изначально, потому как им эти проблемы совершенно чужды. В джява-ынтерпрайз ООП '90s style были просто монструозные развесистые деревья наследования и 100500 файлов содержащих совещенно вырванные из контекста что нибудь переопределящие 5 строчек нихуя непонятно что делаеющего кода. К середине нулевых народ, понажравшись extend говна вдоволь, стал писать более менее плоско, используя интерфейсы и трейты с жынериками, предпочитая композицию хрупкому быдлонаследованию. Так что из "великой тройки" быдлонаследование скоро будет отправлено на помоечку. По поводу инкапсуляции, она была ещё в модульном программированни, поэтому отдельно её упоминать нет смысла. Полиморфизм это вообще отдельный разговор; он может быть достигнут вообще ни к каким "объектам" не прибегая. Под определение "наличие множества реализаций при одном интерфейсе" попадает вообще дохуя вариантов и адхоковых, и параметрических, и структурных, и ещё хуй знает каких.
Скорее всего, подходящее определение это - "представление программы как множества объектов и связей между ними", т.е. "множества + отношения". Но это определение полностью покрывает разве что РБД, с программи всё сложнее, поскольку суть программ - это пошаговое вычисление, а не отношения. Поэтому, внутри "объектов" пашет обычный процедурный быдлокод, и связи продевает обычный процедрный быдлокод, и композитные объекты билдит обычный процедурный быдлокод и т.д. По всей видимости, суть ООП - заворачивание процедурного быдлокода в некую "объектную" оболочку, в которой его можно как-то соотнести с другим быдлокодом, так же завёрнутым в обололочку. Многие просто так увлекаются программированием всей этой надстроечной шелухи, что забывают что "всё делает" как раз тот самый быдлокод в объектах, а сами объекты и код, комбинирующих их - это лишь распределяющая администрация, следящая за порядком, так сказать. То есть, в принципе, изначального определения "модули как первоклассные объекты" вполне достаточно, всё остальное - это выдумки тех или иных видов сектантов.
Это хуйня, а не монада.
Без дженериков высшего порядка даже функтор сделать нельзя.
все просто: просишь начальника показать ЕГО код, и потом делаешь примерно так же
никаких конфликтов
второе: не нужно пытаться таки выяснить что такое ооп "в общем", а надо разбиратся как поддерживаются ключевые концепции опп в текущем языке на котором идет ваша работа
пример: в с++ есть три вида полиморфизма, статический реализуется шаблонами, динамический - виртуальными функциями, и adhoc перегрузкой функций; это официальная позиция по языку, в основном принимаемая сообществом крестовиков; НО при этом попробуйте те же самые термины применить в сообществе функциональщиков, они сразу взвоют, тк у них там свои положения по этому вопросу..
те две вещи:
делай так как раньше делали на тебя на проекте
любая речь о ооп должна идти в разрезе текущего языка, иначе бессмысленный спор и конфликт вам обеспечены
никаких конфликтов
второе: не нужно пытаться таки выяснить что такое ооп "в общем", а надо разбиратся как поддерживаются ключевые концепции опп в текущем языке на котором идет ваша работа
пример: в с++ есть три вида полиморфизма, статический реализуется шаблонами, динамический - виртуальными функциями, и adhoc перегрузкой функций; это официальная позиция по языку, в основном принимаемая сообществом крестовиков; НО при этом попробуйте те же самые термины применить в сообществе функциональщиков, они сразу взвоют, тк у них там свои положения по этому вопросу..
те две вещи:
делай так как раньше делали на тебя на проекте
любая речь о ооп должна идти в разрезе текущего языка, иначе бессмысленный спор и конфликт вам обеспечены
Это просто пример из вики на понятном большинству языке
есть правило, что должно быть не более 7 аргументов. Если больше - мутить структуры и на вход передавать структуру
Sun например официально рекомендовало процедурный стиль в джаве для энтерпрайза (разбиение на слои DAO, Service, etc). И в реальных проектах используется смесь процедурщины и ооп. Твой тимлид типичный даун, для которого идеи важнее бизнеса.
Мой например любит внедрять новомодные опердени, даже в ущерб проекту.
Сроки, задачи подождут пока он играется с очередной свистоперделкой
Пиздец.
Дайте е6му миллион долларов.
Содержание этого коротко видео нужно вбивать в голову джавогосподам ржавыми гвоздями.
Дайте линку на Ютуб плиз.
Во-первых, твой тимлид долбаеб, который или объяснять не умеет, либо сам не знает чего хочет (ну либо ты дурачек, который не может его понять).
Во-вторых программирование не наука и еще не скоро наукой станет. Нет строгой базы, на которую можно опираться. Отсюда и разночтения, недопонимания, и прочая околесица.
Я не понял че за нах.
Почему не дебил в /зк, удали немедленно.
На этом форуме разрешены только дебилы, петухи и школьники.
переведите на наш, ничего не понимаю
ООП - оперирование объектами в рамках программы. Инкапсуляция и полиморфизм сразу не при чем, так как и то и то есть в процедурном программировании. Без наследования ООП может вполне себе обойтись - без него код, порой, намного лучше выходит.
Один ООП-сектант может обмазываться SOLID - и все его классы будут состоять из одного метода + конструктора. Второй ООП-сектант будет хуярить классов-монстров на 5000 строк. Всё это не решает главной задачи - сделать программу, которая бы решала задачу.
>ничего не понимаю
Вот этот школьник-дебил разрешен на форуме /зк, например.
фы эс у эр, сука. Сюда подашел.
пффф
ты слеподырый тормоз, кстати
Д'Артаньян, залогинтесь.
Прост апдейт сообщений не нажал, я видел.
Это же Uncle Bob, наркоманы. Ссылки на ютуб нет, я вырезал из его Clean Coders, эпизод 8. Можно спиздить на пиратбее. Охуенные видео, только отредактированы говняно, особенно первые. Да и в этом заметно, как звук хромает. Но оратор он 10/10, публичные лекции на ютубе слушать одно удовольствие.
Ну хуй его знает. ИМХО мне с ООП удобней, так как позволяет делать код более логичным, что ли. Т.е. чисто процедурщина это как стена текста, а ООП все таки по умолчанию подразумевает упорядочивание кода. Да, можно добиться такого и просто используя функции, ну так ведь ООП представляет для этого гораздо больше плюшек.
Найди код ООПшника, упарывающегося SOLIDом. Там 90% классов состоят из 1 метода.
Так это уже извращения. Я писал о том, какие плюсы это даёт мне. Вот мне приятно работать с данными, которые сгруппированы в объект, а не "вот тут у нас переменная, тута массив, и вместе с вот этим десятком функций они как-бы образуют одну сущность". Т.е. для меня это просто удобная обёртка над процедурщиной, и не более.
Функциональщина логичнее и удобнее, гораздо более тестируема. Весь код состоит из набора stateless функций. Все что тебе нужно - написать эти функции и написать юнит тесты на каждую функцию. Код легко делится на уровни, на зоны ответственности согласно solid.
Что такое ооп? Это когда вся бизнес-логика размазана ровным слоем по всему коду. Как это тестировать? Хуй знает. Как разделять ответственность? Никак. Ибо зависимости внутри классов и методов.
Знаменитый паттерн active record, продвигаемый адептами ооп, является нарушением solid. Об этом даже адепты писали
Так тебе просто неймспейс нужен и инкапсуляция. Это даже в сишечке есть
>SOLID
>извращения
Хм...
1) Найди мне дохуя времени что бы разобраться в ваших ебучх монадах и функторах 2) Найди мне работу, на каком-нибудь из лиспов чтоль.
Можно. Но зачем, если ООП и нужен для такой хуйни? Вот уж чего не пойму, так это хейтерства ООП. При том ладно если бы технология была дохуя сложной, а выхлоп копеечным, но там же в общем-то и сложного нихуя нет.
Бля, я перепутал функциональщину с процедурщиной. Сори
Суть в том, что ооп в том виде, в котором его задумывали адепты, неприменима. Его можно применять только особым образом, внимательно обходя все грабли и строго следуя методичке "как приспособить ооп для реальных проектов"
>Соси
Сам соси, пидор.
Зачем ты увидел "соси" там, где это не было написано?
мимо проходил
Ну что, господа, кто что полезного вынес из этого треда?
>Суть в том, что ооп в том виде, в котором его задумывали адепты, неприменима.
Возможно, я не такой бородатый профессор что бы пояснять. Да и то, а разве там не было основной целью повышение реюзабельности кода? Ну там для продакшена хотя бы.
>Его можно применять только особым образом, внимательно обходя все грабли и строго следуя методичке "как приспособить ооп для реальных проектов"
Наверное просто не надо считать его какой-то волшебной херовиной, которая сама по решает задачи лучше, а скорее методологией, упрощающей разработку, и тогда все встанет на свои места.
>Зачем
Угадай :3
Два стула получилось: один с лямбдами точёными, другой с факторями дрочеными. Садиться надо на оба.
>кто что полезного вынес
Вынес часы и кошелек какого-то одинассника.
Cмотри попу не порви.
А это статья, но я ничего не видел 1с - нипрагроммисты, #расизм
>повышение реюзабельности кода? Ну там для продакшена хотя бы.
Stateless функции в процедурном стиле более реюзабельны
>это статья
Читал в журнал ксакеп, очень смешно интересно.
Pure stateless функции для всего, кроме инпута - и ты уже почти функциональный господин.
Слушай, это ты тот сектант что в каждом треде постит в случайных местах телеги типа "бросай технология_нейм и юзай ФП, все твои проблемы решат ф-и с неизменяемым состоянием"? Не, не то что бы я что-то особо против имел, но я бы тебя поймал и чисто по-дружески спросил бы кто ты вообще по жизни такой.
Не, я другой. Но я видимо тоже пришел к этому.
К этому много кто приходит с опытом. Каждое состояние объекта в твоём коде убивает котёнка. Каждое состояние функции убивает стадо котят.
obj.call() и call(obj) - в чем отличие?
или что stateless?
В том что в самом обже ничего не меняется.
С точки зрения железа - ни в чем отличия нет.
Функця obj.call() на чуть более низком уровне будет выглядить как obj_call(this)
Stateless - отсутствие состояния. Означает, что твоя функция не имеет внутреннего состояния. И что ты получишь на выходе зависит только от входных данных.
Pure - функция, не меняющая состояния объектов снаружи этой функции.
Это тебе надо было своего тимлида спрашивать, что ему не понравилось, мы-то как догадаемся, по-твоему?
В целом ООП-хорошая штука. Хейтерство обусловлено в основном тем, что некоторые популярные концепции из мира ООП сильно оверрейтед.
Самое-самое оверрейтед - это наследование реализации. С этой хуйни начинается любая статья или книжка про ООП, тогда как в реальной жизни довольно мало ситуаций, когда наследование реализации приносит пользу. Чаще она приносит вред, потому что вносить изменения в родительский объект с ветвистыми наследниками - дело чрезвычайно муторное.
Я постоянно сталкиваюсь с тем, что чайники очень плохо справляются с выделением абстракций, предпочитая механически выносить в методы текущего и родительского класса любой продублировавшийся код. Их не ебёт, что это дублирование могло (и обычно оказывается) случайным совпадением.
Вот кто-то из отцов (Фаулер, кажется) не так давно полыхнул в очередной раз и отметил, что объекты в ООП объединяют не какие-то там ебаные "объекты реального мира", а вещи, которые изменяются вместе. Простая штука, казалось бы, но осознать ее на практике довольно сложно почему-то.
Суть ООП в том, что можно создавать классы, описывающие объекты, с которыми работает программа. При этом в объекте собраны вместе как данные (поля), так и функции для работы с ними (методы). И программа состоит в основном из классов.
Ну например, если у тебя программа учета всякого хлама на складе, то там будут классы Склад и как минимум класс Товар. А также может быть какой-нибудь МенеджерТоваров, который не представляет никакую сущность, а просто содержит методы для управления товарами (такие классы еще называют сервисы).
Вы поехавшие, какие наследование и инкапсуляция? Это уже дополнительные возможности, но не главные характеристики ООП кода.
И что у вас за примеры? Какие еще Собаки? В какой программе будет класс Собака? Если человек приводит такие бредовые примеры то скорее всего у него понимание и опыт написания ООП кода чуть менее нуля и он пересказывает то, что прочитал в книге, но не понял (туда же идет пример про марки машин).
А тимлид наверно имел в виду то, что ты либо все сделал на статических методах, либо нагородил God Objects, либо DI не осилил. Я код не видел, сказать не могу.
Алсо по комментариям вы можете легко увидеть число студентов-теоретиков, ни разу в руках объект не державших, а только читавших про них в книгах.
Ты просто теоретик, потому и не знаешь.
>Ну например, если у тебя программа учета всякого хлама на складе, то там будут классы Склад и как минимум класс Товар.
Гуманитариев полон тред азаза.
Если в огороде бузина, то в Киеве дядька.
>Суть ООП в том, что можно создавать классы, описывающие объекты, с которыми работает программа. При этом в объекте собраны вместе как данные (поля), так и функции для работы с ними (методы). И программа состоит в основном из классов.
Это не "суть ООП", это ты сейчас описал сахарок к процедурному подходу, чтобы структуру с данными не прокидывать первым аргументом каждый раз.
Отличие ООП от процедурной парадигмы прежде всего в том, что вызывающий метод не знает точно, какой именно код будет вызван, то есть решение отдается на откуп объекту. По сути мы просто отправляем объекту сообщение "выполни такую-то процедуру, как умеешь". Этот факт может быть использован для разделения уровней абстракции, а может (и обычно используется) - для окончательного завязывания спагетти-кода в морской узел.
Пиздец, эталонный раб системы. Какой бизнес, ебанашка? Ты себе софт пишешь или дяде? Тебе не похуй какой там бизнес получается, тебе и так з/п выдадут.
Тогда форт - язык массового котоцида. Там все переменные глобальные, а функция, которая втихую пидорасит стейт - обычное дело. И ничего, работает, в космос летает.
> вызывающий метод не знает точно, какой именно код будет вызван
Ты сейчас описал сахарок к процедурному подходу, чтобы структуру с методами не прокидывать каждый раз.
Он описал виртуальные функции.
Он описал макральные монады, неосилятор процедурный.
> В какой программе будет класс Собака?
Игра какая-нибудь.
Ну или корова вот https://doc.rust-lang.org/std/borrow/enum.Cow.html
> пример про марки машин
ЖТА 5
Те кто летает в космос по другому софт разрабатывают, для начала.
Просто у них много котят.
>по другому
По-какому? Что в их софте особенного?
Форт стековый язык для узкого круга задач, не путой
>Расписал определение как студент с 1го курса...ну там товары...объекты какие-то...я классы насру, объекты вместе соберутся...
>Вы все студенты
Вот с этого в голос.
>Форт стековый язык для узкого круга задач
И что? Люди пишут с супермутабельным стейтом сложные системы и на функциональщину переходить не собираются.
Имхо сила конкатенативщины - в однострочниках. Только сами форт и фактор так себе развивают это направление.
Идеальный язык чтобы в игрушке в одну строку что-то скриптануть в консольке должен быть как минимум конкатенативным.
Идеальный язык чтобы в игрушке в одну строку что-то скриптануть в консольке должен быть как минимум конкатенативным.
>так себе развивают это направление
Потому что без переменных ты много не напишешь, а с переменными однострочник уже не получится.
Вы плохо понимаете что такое современный ванильный ECMAScript.
Монады и все остальное давно есть.
>вносить изменения в родительский объект с ветвистыми наследниками - дело чрезвычайно муторное
Такое с любым проектированием. Чем раньше допустили ошибку, тем дороже потом переделать.
>С точки зрения железа - ни в чем отличия нет.
отличие есть, на низком уровне это будет выглядеть примерно как v_table[obj.type_tag].call(obj)
> obj.call() и call(obj)
obj.call() и self.call(obj)
>Такое с любым проектированием. Чем раньше допустили ошибку, тем дороже потом переделать.
Нет. Это проблема ООП-языков вроде джавы. Если класс внутри использует какие-то другие классы через интерфейс, у пользователя должна быть возможность их заменить на другие. К этому пришли через DI, но такая возможность должна быть изначально в языке и форсироваться по дефолту.
В сишке XYJPZDA_obj_call( obj )
Это не имеет отношения к наследованию реализации
>Люди пишут
В том и дело. Ты видел стоимость такого спеца, которого мк на ракетах пустят ворочать?
>стоимость такого спеца
Всегда можно промыть мозги или заставить угрозами.
Экономия.
Просто тимлиду надо было доебаться и пидорнуть тебя, вот и все. Че как маленький?
Тысяч 30 рублей в месяц, 60 - если охуенный специалист.
1) Один хуй вызывается функция с параметром this
2) vtable не везде используются и не всегда применимы
Полный водопад, где без спеков тебе не разрешат даже начать кодить.
Наследование в таком варианте вообще не нужно. Должна быть возможность скомпоновать инстанс из готовых трейтов/миксинов, причем интерфейсы прописывает получатель. То есть у компонента спрашивают, подходит ли он под нужный интерфейс, и если да, выдается инстанс интерфейса.
Люди не только для космоса на форте пишут. Обычный софт тоже.
>Чем раньше допустили ошибку, тем дороже потом переделать.
Вот ты сейчас нечаянно прямо всю суть ООП-макаронников ебанул. "Раньше", епта. Действительно, "раньше", потому что великий оопэшник Сычев вместо нормальной абстракции выделил абстракцию "склад говна из наследников", а то и цепочку таких складов. Ясен хуй, что ни о каких вменяемых контрактах с наследниками в таких классах быть не может, и совершенно очевидно, что по достижении определенной зрелости эти склады забиваются говном доверху,и вот тогда-то и наступает ПОТОМ, в котором внезапно оказывается дорого что-то менять.
Не должно такого быть, понимаешь? Дороговизна внесения любых изменений в основном зависит от толщины слоя спагетти, намотанных поверх кога, который требуется изменить.
Ехала Зависимость через зависимость.
Видит Зависимость в зависимости Зависимость.
Сунула в зависимость Зависимость зависимости.
зависимость за Зависимость Зависимость - цап.
Видит Зависимость в зависимости Зависимость.
Сунула в зависимость Зависимость зависимости.
зависимость за Зависимость Зависимость - цап.
Наследуйтесь, я вам немножко ООП принес.
У меня от твоего поста LOOSE COUPLING.
Уважаемый senior enterprise java architect, пройдите нахуй.
Двачую этого господина, ещё и табы с пробелами перед этой строчкой намешали, ибо ТАК УДОБНИЙ И ВЫРАВНИВАНИЙ!
И этого господина двачую, хотя сейчас в НИИ тоже смекнули, что пора бы прибавлять, а то уйдут сайты клепать. Друг занимается написанием и верификацией кода для самолётов.
>чтобы структуру с методами не прокидывать каждый раз
Таблица виртуальных функций и вообще функции в качестве обработчиков сообщений - это всего лишь один из способов реализации ООП-парадигмы.
>senior enterprise java architect
Мамку твою инкапсулировал, говна ты кусок.
Джява - это язык, созданный с целью получения максимально сложных систем силами большого числа минимально компетентных сотрудников. Немудрено, что в нем, как в зеркале, отразились все пороки целевой аудитории.
Брат за брата, зависимость за зависимость.
А для нормальных людей дак тайпинг.
А на чем пишут по для самолетов?
Ада и кресты. С ады уползают, потому что специалистов мало, и все и так уже там работают.
> Джява - это язык, созданный с целью
> Петух с двачей рассуждает с какой целью создан какой-либо язык, софт на котором приносит миллиарды баксов
>Ада
Хтоничненько
Для вертолётов - Си и кресты.
Мимопроходил
Спасибо
Друг пишет на Си98 и ассемблере(MASM и FASM в основном).
Современная Ада однозначно лучше крестов. Старая - лучше сишки.
>Современная Ада
Проиграл.
>современный арбалет однозначно лучше мушкета
>старый - лучше аркебузы
>Проиграл
Ты бы и собаке проиграл. Проблема в том, что кроме арбалетов и аркебуз ничего больше и нет в этой области. кококорастхачкель
>приносит миллиарды баксов
На любом сколько-нибудь популярном языке есть софт, приносящий миллиарды, дальше-то что?
Джяву нельзя назвать плохим языком, но в силу очевидных причин именно в ней повылезал наружу весь сладкий хлебушек неудачных ООП-практик. Что ж, скажем ей за это спасибо - теперь мы, по крайней мере, знаем, как не надо делать.
Декларативные господа не слышали про dependency injection container?
Я смотрю тут все такие умные. Много умных букаф.
А вот можете мне привести два примере одного и того же кода. Но чтоб один был однозначно ООП, а второй однозначно процедурщиной. Вот чтоб прямо совсем однозначно. А мы все вместе посомтрим на сколкьо вы хуй.
А вот можете мне привести два примере одного и того же кода. Но чтоб один был однозначно ООП, а второй однозначно процедурщиной. Вот чтоб прямо совсем однозначно. А мы все вместе посомтрим на сколкьо вы хуй.
Начнём с того, что иок, как в джаве - это деградации от ООП, обратно в сторону моудльного программирования. Быдлу дали модули как первоклассные объекты, комбинируй объекты сука, строй связи блядь, кодом блять строй, ты же программист блядь, нет хотим жрать говно, пидоры, спринг взяли, иксэмэльки программруют.
Сходи-ка на хер со своими софизмами.
Могу тебе на похапе накидать, как раз в туалете сижу https://ideone.com/jHJd6l
Хотя это оче абстрактный пример. Короче хуй знает, что бы прохавать все плюсы/минусы надо самому писать и разбираться, если ты этого просишь. Иначе будешь или обьектно-ориентированным сектантом, или попросту не осилишь.
Завернули процедурщину в класс
@
Вынули из глобалов, вставили в замыкание
@
ООП!
>Завернули процедурщину в класс
Ну а что ты хочешь? ООП это и есть развитие процедурщины.
Удваиваю, какой-то старый учёный хуй ещё так сказал.
Это неправильно.
ООП это когда у тебя будет:
Абстрактный синглтон базы данных.
Синглтон mysql
Фабрика баз данных
Регистри, хранящая фабрику баз данных
Абстрактный строитель вывода
Строитель вывода из SQL
Абстрактный наблюдатель базы
Наблюдатель за mysql
Посредник, принимающий сообщения от наблюдателя
Абстрактная стратегия выбора баз данных
Стратегия выбора Mysql
Абстрактный декоратор стратегии выбора базы данных
Фабрика стратегий выбора баз данных
Посетитель, запускаемый посредником при получении сообщения от наблюдателя
Заместитель, принимающий посетителя и решающий, делегировать ли команду вывода виду
Абстрактный вид
Вид CLI
Абстрактная фабрика видов
Фабрика видов, возвращающая инстансы видов CLI
Прототип CLI-вида, используемый CLI-фабрикой
Абстрактная модель
Абстрактный ORM
ORM для Mysql
Модель, работающая с MySql-ORM сущностями
Абстрактная активная запись
Активная запись для mysql-ORM моделей
Абстрактный синглтон хранения моделей
Синглтон, хранящий активные записи
Абстрактный синглтон хранения видов
Синглтон, хранящий CLI-виды
Абстрактное мементо
Мементо активной записи Mysql-ORM модели
Абстрактная команда
SQL-команда
На самом деле, это я тут хотел показать пример похожий на реальность, только в итоге получилось жидкое не-репрезентативное говнище. Наверное, кому интересно понять зачем оно, пусть попробует покопаться в исходниках какого-то фреймворка, или просто расширения написанного с ООП, только крупного, а потом представить как бы это переписать на процедурщину. Короч ООП просто в разы повышает выразительность обычной императивной процедурщины, за это его и любят, как-то так.
Ну и аналог этого на продурщине:
$sql = "SELECT name, secondName, email FROM users WHERE id = $id";
$sth = mysqli_query($mysqli, $sql);
$res = mysqli_fetch_assoc($mysqli);
return $res;
id='; DROP DATABASE primary; --
Кстати ФПсектанты, раз уж вы такие убежденные функциональщики, перепишите этот понос на функциональный лад, что ли. Самому интересно.
ну да, придётся добавить строчку с биндингом параметров
хотя можно обойтись малой кровью с помощью божественного mysqli_real_escape_string
Зачем эта параша нужна, если есть божественный PDO?
Тогда надо сразу ORM.
Полный тред долбоебов, не осиливших RDD, принципы SOLID/GRASP и инверсию контроля. Такие мрази, как вы, способны максимум смузи хлебать в перерывах медлу крадошлезством в рельсах
Так там ORM тоже присутсвует.
Туда ли ты зашла, абстрактная фасолина?
Все что ты перечислил любая веб-макака с мозгом за полгода жуниорства осиливает, тем более что фишки типа IoC уже реализованы во всех фреймворках и можно даже не особо вникать как оно работает.
>RDD
Ого, аж новый баззворд придумал.
Какая, блять, "реализация Ioc", что ты несешь? Пиздуй в википедию читать, что значит термин. Не существует реализаций IoC, это один из (интутивных) принципов проектирования наподобии OCP
Этому "баззворду" больше лет, чем тебе, мудило, только вот его понимание отличает макаку от человека.
>RDD
Это что?
http://www.yiiframework.com/doc-2.0/guide-concept-di-container.html ой, слушай, все эта хрень давно уже и так есть. Нашел чем выпендриваться.
Не путай DI-контейнеры с принципом IoC. DI-контейнер соответствует принципу IoC а не, блять, "является реализацией IoC". DI-контейнеры не мешают хуесосам пихать вьюхаспецифическую поебень с уровней на пять ниже в слой сервисов.
Ди-контейнер это тоже самое, не конкретная реализация а принцип, и что?
ООП это по сути оптимизация программы, чтобы понять это новичку, сначала нужно написать программу в процедурном стиле, а потом функции которые делают одно и тоже но в разных частях программы вынести в отдельные классы, постепенно приводя код, к отдельным мало зависимым модулям.
>к отдельным мало зависимым модулям
А на практике получается монолитный фреймворк, из которого невозможно выдрать отдельный модуль.
Это все и за начальства которое подгоняет, капитализм хули, время деньги.
Объясните эту фразу, аноны
Т.е. я так понял изначально ООП преследовало цель максимальной независимости объекта. К примеру, сидят в офисе пять сотрудников и один из них говорит "Ребята, заварите кто-нибудь кофе" и кто-то из ребят сам решает пойти заварить кофе, а может вообще никто не пойти. В то время как текущая реализация ООП это когда работник сам подходит к другому работнику, тыкает в него пальцем и говорит "Кофе заваришь ты, без вариантов".
Если менее абстрактно, то примерно такой сценарий:
1 - Объект А говорит "Ребзя, тут запрос пришел. Я его обработал и рассортировал".
2 - Объект Б говорит "Оппа, там кто-то запрос рассортировал. Ребзя, я кароче посмотрел че там надо было и вот подготовил тут данные для записи в БД".
3 - Объект В говорит "Че-че? Там кто-то данные подготовил для записи в БД. Надо бы занести в БД. Вжух!"
4 - Объект Г говорит "Вжух? Кто-то записал данные в БД? Надо пойти пользователю сказать, что данные были записаны"
Если менее абстрактно, то примерно такой сценарий:
1 - Объект А говорит "Ребзя, тут запрос пришел. Я его обработал и рассортировал".
2 - Объект Б говорит "Оппа, там кто-то запрос рассортировал. Ребзя, я кароче посмотрел че там надо было и вот подготовил тут данные для записи в БД".
3 - Объект В говорит "Че-че? Там кто-то данные подготовил для записи в БД. Надо бы занести в БД. Вжух!"
4 - Объект Г говорит "Вжух? Кто-то записал данные в БД? Надо пойти пользователю сказать, что данные были записаны"
2 чая. Все что делает ДИ - выносит компоновку проекта в огромные простыни кода, которые надо постоянно актуализировать. Это у более-менее нормальных. У ебанатов xml.
Нет, это когда 5 одинаковых работников, которые ничего не умеют делать кроме подсчета факториалов и ничего не знают об окружающем мире.
И если ты хочешь одного научить чему либо, остальные умирают
Нет, это врожденная особенность ооп. Где объекты вынуждены знать друг про друга
Ты представляешь объекты как как Пакеты с функциями. У них есть Инкапсуляция и Полиморфизм.
То есть Работник может подойти к каждому сотруднику, и вызвать метод "Может_кофе()", там дальше сотрудник сам решит как ему обработать Вызов "может_кофе", и если все вернут false, тогда уже работник подойдет к сотруднику и сделает вызов Может_кофе(быстра_бладж);
Объекты в списке у тебя выглядят как просто пакеты с функциями(ну их конечно можно так использовать). Вся фишка как-раз в хранении статусов, и возможность общаться с интерфейсами других объектов без гемороя и так далее.
Есть объекты Ячейки. К ним произешел вызов и туда пихнули строку.
На часть ячеек подписан обсервер, и когда инвокнули Cell->set_cell там дернулся invoke
_observer(self->observer, "set") где observer и есть указатель на объект, где мы сделали вызов обсервера который подписался на эту конкретную ячейку.
обсервер достал реф на эту ячейку и забрал данные. и дальшерешает что с ними делать. Например из Cell, он возмет то что туда поменстили, и потом из другого cell он возмет тоже.
а потом он сделает return cell->get + cell->get.
так как в первом обьект string, а во втором array,
то из перового объекто вызоветься __add__ в котором уже указанно что если его пытаються сложить с типом array, то взять array, и сделать ему join и вернуть как строку, и тогда сложить строки. (вместо вашего аррей может быть любой объект, например класс КОНФИГ)
и вместо ошибок, Обсервер получить большую строку, и скормить базе и завершиться например.
сумбурно написал канешно, но это как-то так.
>Где объекты вынуждены срать друг под друга
>сумбурно написал канешно, но это как-то так.
Ебанный пиздец!
>Вся фишка как-раз в хранении статусов
Нет, это вообще порочная практика.
>На часть ячеек подписан обсервер, и когда инвокнули Cell->set_cell там дернулся invoke
Начало спагетти встретило конец спагетти, узел затянулся, котята начали массово умирать.
Ну где же пример эталонного ООП? Неужели здесь нет труЪ-адептов, способых его выдать? ну или хотя бы чужой код копи-пастнуть
Эталонное может существовать только в вакууме. В реальности появлятся нюансы и элементы процедурщины
Можешь посмотреть книжки и гитхабчик Сэнди Метц, её ООП — эталонное, правда и проекты уровня laba1
Smalltalk
Если логика, абстрагированная внутри классов, выстроена верно, то объектам не обязательно знать друг про друга. Более того, при вдумчивом подходе к инкапсуляции, большинству объектов друг про друга знать не нужно (как и рандомной макаке, которая в рандомный момент времени полезет вставлять костыли внутрь какого-нибудь модуля системы, чтобы прикрутить к нему свое охуительное улучшение).
Вот оно, явление стереотипного джявиста в итт треде.
Все проще. Есть интерфейс (или абстрактный класс) CanMakeCoffee с методом makeCoffee(), каждый сотрудник его реализует. Начальнику Ерохину в конструктор при создании надо пробрасывать нечто, что этот интерфейс реализует - это и есть частный случай DI. Если Ерохин пьет мало кофе - ему достаточно передать конкретную секретаршу Еотову, пусть он ее дергает. Если потребление кофе растет и Еотова не справляется - мы можем реализовать тот же интерфейс у робота, который будет по хитрым алгоритмам распознавать пасьянсы и втентаклик на компах всех сотрудников и отправлять бездельников за кофе в несколько потоков. Ерохин при этом даже не будет знать, что что-то поменялось в архитектуре офиса. Сложность реализации робота закрыта от него.
ну вот же, каждому сотруднику нужно знать про существование кофе-машины и уметь с ней обращаться.
Чтобы перенести их в другой офис, тебе придется переносить и кофе-машину
При процедурном же методе будет функция
Сделать_кофе( сотрудник, кофе-машина ) : кофе
При этом сотрудник и кофе машина никак не связаны друг с другом и не знают о существовании друг друга.
Если в новом офисе нет кофе машины, то можно просто не копировать эту функцию.
Эту функцию легко протестировать, она не зависит от внешних условий
Я к тому и веду, что логика хороша, если она универсальна. Если сотрудник не понимает, что в новом офисе другая кофе машина (а в идеале, что нужен другой интерфейс взаимодействия с этой машиной), выдает 25 экзепшенов и ложит за собой как карточный домик всю систему, то это повод задуматься.
Задуматься о чем?
Перевестись быстрее в другой отдел.
Чем это принципиально отличается от ООП с использованием SOLID?
Ясно. Опять эти сказки про кривые руки. Подразумевая что уж у тебя руки точно не кривые
Тем что это уже мало напоминает ооп
Какой код напоминает ООП?
>Ясно. Опять эти сказки про кривые руки. Подразумевая что уж у тебя руки точно не кривые
Я всего лишь почесал яица, а ты уже решил, что у меня между ног герпес.
в процедурном программировании нет понятия объект, дадут тебе примитивы и ебись без смазки, как хочешь, но чтобы кофе мне было.
> делать_кофе( сотрудник, кофе-машина ) : кофе
Только сотрудник, кофемашина и кофе - это массивы байтов.
>Эту функцию легко протестировать, она не зависит от внешних условий
А еще она требует от пользователя дохуя лишних знаний, про кофе-машины всякие, про сотрудников и прочую малафью. А пользователь не хочет ничего этого знать, он хочет вызывать Сделать_кофе(): кофе безо всяких там зависящих от реализации аргументов.
Есть как минимум структура
Если ты спрятал сложность, то она не исчезает. Она начнет ебать тебя в самый неподходящий момент и ты ничего не смодешь сделать.
Чо делать, если внезапно появилась вторая кофе-машина? Править все объекты и молиться чтобы ничего не сломалось?
> вторая кофе-машина
Она не умеет делать кофе?
> Сделать_кофе( сотрудник, кофе-машина ) : кофе
> Есть как минимум структура
Пока у тебя одна структура, сложностей нет.
А когда появится десять структур типа сотрудник - все похожие, но чуть-чуть разные, и пара кофе-машин, то твоя процедура разрастется до неприличных сотен строк.
И удачи, в добавлении 11 структуры или третьей кофе-машины.
Умеет. В объекты сотрудников надо добавлять вторую кофе-машину?
Почему не был сделан интерфейс ICoffeeMaker с одним методом Coffee MakeCoffee()?
Элементарно
Кофе-машины [] = {кофе-машина1, кофе-машина2, кофе-машина3}
Найти_ближайшую_кофемашину(сотрудник, кофе-машины) : кофе-машина
Сварить_кофе( сотрудник, кофе-машина ) : кофе
Заметь, добавилась только 1 новая функция, а старый протестированный код я не трогал
Выдавать интерфейс кофемашины через load balancer, а сотрудников поставить в очередь и залочить метод Сделать_кофе, чтобы пидорахи не ломились, расталкивая друг друга. Энтерпрайз решение.
А где реализация?
Зачем тебе её знать?
>Чо делать, если внезапно появилась вторая кофе-машина? Править все объекты и молиться чтобы ничего не сломалось?
Ничего тебе не понадобится править, если у тебя обязнности между объектами распределены правильно. Раньше сотрудник получал на вход интерфейс КофеМашина с методами какПройти(моиКоординаты): маршрут и сваритьКофе(): кофе - и теперь он будет получать его же. Просто при инициализации сотруднику будет подсовываться не сама кофе машина, а брокер кофе-машин с тем же интерфейсом, который направит сотрудника к ближайшей свободной машине, да еще и сварит кофе аккурат к его приходу, чтобы ждать не пришлось. Сотрудник опять-таки ничего не заметит, продолжать жить, как будто кофе-машина по-прежнему одна.
Ох и развелось же в /зк/ долбоёбов. Надеюсь, ты хотя бы из перезвоним-треда сюда пришел, а не пишешь очередного франкенштейна, проебывая деньги работодателя.
А до akka скоро дойдем?
Все объекты реализуют этот интерфейс. А где реализация? Как создавать эти объекты без реализации интерфейса?
>Весь код состоит из набора stateless функций.
Такое можно и в ооп-стиле сделать. Объекты - чистые данные, объекты - чистые функции, а между ними объекты с логикой использования(бизнес-парвила). Для такой подхода функциональное петушение не нужно.
Вообще кажется, что фп-петухи ничего серьезнее чисел фибоначи не писали, иначе они тоже охуели от количества функций в которых ровным слоем размазана нетривиальная логика, осложененая изъебствами по изменению неизменяеого состояния с приемлемой производительностью.
Про тестируемость вообще смешно. Алё, у вас там на знаменах написано ВЕРЕФИЦИРУЕМОСТЬ, а тесты можно написать для хорошо написаной программы в любом стиле. Но до верефецируемости фп-петухам как до китая раком. Никакая истеричная борьба за нулсафети к ней не приводит, а только прождает еще большую кучу проблем. Я не видел ни одного программиста на фп-языках, который это понимал бы.
Не прикидывайся дурачком, структуры сотрудников не гомогенные, тебе нужно учитывать особенности каждой. Иначе выпилишься с эксепшеном, когда Василий пошлет тебя нахер, т.к. он не любит варить кофе. С каждым новым сотрудником твоя процедура будет расти.
Вообще у тебя должен быть КофеМашинаСервис, интерфейс которого абстрагирован от количества кофе машин. А замену одной реализации (с одной кофемашиной) на другую (с тремя) берет на себя di фреймворк.
Зачем тебе что-то создавать? Контейнерный гном выдаст тебе твой ICoffeeMaker в конструкторе
Проскочили. Уже RabbitMQ.
>Почему не был сделан интерфейс ICoffeeMaker с одним методом Coffee MakeCoffee()?
А какое кофе вернет метод? С сахаром, черный, капучино? Может сотруднику нужен не абьстрактный кофе, а конкретный.
Jmx != Akka
А если я не люблю централизованные MQ и хочу долбиться в Ø?
Опять же, контейнерный гном всё и так знает.
А если я на работу с литровой кружкой хожу, халявный кофе пить? А? А? A?
Ебашь на чистом Erlange.
Слишком больно, прости.
Нихуя он не знает. Ему надо в инициализаторе пояснить. Если ты спрингобоярин, то будешь делать это через XML.
>у тебя должен быть КофеМашинаСервис
Нет, это дорога в ад. У меня должно быть ровно то, что мне необходимо, а мне необходима именно кофе-машина, а не какой-то там ебучий сервис, от которого рукой подать до абстракт-кофе-машина-фэктори-бин. Сотрудник не должен знать ни про какие сервисы и вообще про то, что кофе-машин в офисе много.
Я не жавапидор, сорян. Мой гном умнее, ему можно через [Dependancy] аттрибуты всё объяснить всё прямо внутри класса.
> что кофе-машин в офисе много
Должен конечно. Иначе пока Ерохин варит кофе себе и Еотовой, Сычевы омежки будут ждать потупя очи.
Ты уж выбирай. Либо ты знаешь то что знаешь (в офисе кофемашина), либо ты вставляешь слой абстракции на случай расширения (в офисе n кофемашин). Вместе никак.
Если такая система управления кофе машинами самая оптимальная, хли ни в одной реальной кофе машине она не применена?
Шах и мат.
идешь вместо кофемашины к Кукушкину, он говорит тебе где сегодня кофе со слифками.
Добрый день, Василий. IoC контейнерам исполняется сто лет в обед, а для вас это всё еще новость.
>Иначе пока Ерохин варит кофе себе и Еотовой, Сычевы омежки будут ждать потупя очи
Так они и не будут, их сервис направит к другой кофе-машине которая как раз сломается и ошпарит паром, но не суть. Омежкам будет казаться, что кофе-машина в офисе одна, просто перемещается с места на место постоянно почему-то.
>Ты уж выбирай. Либо ты знаешь то что знаешь (в офисе кофемашина), либо ты вставляешь слой абстракции на случай расширения (в офисе n кофемашин). Вместе никак.
Выше уже написал, как не вставлять заранее никому кроме твоей мамки, конечно же.
Если Магомед не идет к кофемашине, то кофемашина идет к Магомеду.
>Такое можно и в ооп-стиле сделать
Это и есть ООП стиль, убогий.
Еще раз.
Для особо упоротых идиотов.
ООП подход не требует наличия абстракции объектов в коде и языке.
Хоть сколько то современное ооп пляшет от интерфейсов и композиции. Боги, да классика банды четырех начинается с пояснения превосходства композиции над наследованием.
>ООП подход не требует наличия абстракции объектов в коде и языке.
Формально - нет, конечно, можно хоть на ассемлере с ООП пердолиться. На практике, конечно, лучше иметь поддержку на уровне языка, чем вручную реализовывать иерархии типов.
Интерфейсы - гарантируют наличие метода, но ООП работает и без этий гарантий. Уточка крякает, и б-х с ней, это уточка, хуй с этим сертификатом для нее.
Хорошо поболтали, расходимся, до завтра.
Что-то убогий тут только ты.
>Это и есть ООП стиль
Это не единственный стиль в ооп. Монолиты никто не отменял. В маленьких программах их делать быстрее и проще, чем петушиться чистыми функциями и слабой связаностью.
С изменением предка не должно быть проблем, наследование нужно как раз для того чтобы пихать в базовый класс дублирующий код, который во всех наследниках одинаковый. Если нужно исключение, пишется виртуальный метод.
Сам наследование стараюсь не использовать, хотя бы чтобы IDE не предлагала сотню левых методов, лучше сделать базобый объект приватным полем.
Сам наследование стараюсь не использовать, хотя бы чтобы IDE не предлагала сотню левых методов, лучше сделать базобый объект приватным полем.
>3. коллбек-хелл
Ну это уже не смешно. Как там, в 2010?
С изменением предка наипреогромнейшие проблемы, библиотеки нужны как раз для того чтобы пихать в каждую из них дублирующий код, который во всех программах одинаковый. Если нужно исключение, пишется виртуальный метод.
Сам библиотеки стараюсь не использовать, хотя бы чтобы IDE не предлагала сотню левых перфокарт, лучше сделать точку входа в библиотеку приватной перфокартой.
>С изменением предка не должно быть проблем, наследование нужно как раз для того чтобы пихать в базовый класс дублирующий код, который во всех наследниках одинаковый.
Ловите этого и бейте по голове до тех пор, заставляя после каждого удара повторять: "fragile base class - фундаментальная проблема ООП". Я про таких дегенератов уже писал вот здесь . Искренне желаю ему, чтобы его предки IRL так же мучительно утонули в говне, как и базовые классы его авторства.
Наследование в ООП - оно, блять, для создания иерархии полиморфных типов, а не для того, чтобы классы с верхних этажей срали на головы тем, что живут пониже. В подавляющем большинстве случаев от дублирующегося кода можно и нужно избавляться при помощи агрегации, а если таки возникает нужда наследовать реализацию - должен быть жесткий контракт между предком и наследниками. Пусть наследники пользуются публичным интерфейсом предка на крайняк, или жестко ограниченным подмножеством защищенного интерфейса.
>Что-то убогий тут только ты.
Чейэто ты так взорвался, аж сажу прилепил?
>Это не единственный стиль в ооп.
Да, не единственный.
>чем петушиться чистыми функциями и слабой связаностью.
>и слабой связаностью
Мущи-мущи.
Земля вызывает убогого, ответь, убогий.
Повторяю, ООП - это отсутствие связи между получателем сообщения, и отправителем.
Повторяю, отсутствие связи.
Связь только через сообщение, повторяю, сообщение.
Если у тебя отправитель связан с получателем, то это НЕ ООП.
Это кодолапшевая интерпрайз дристня.
Повторяю, дристня.
>Формально - нет, конечно, можно хоть на ассемлере с ООП пердолиться. На практике, конечно, лучше иметь поддержку на уровне языка, чем вручную реализовывать иерархии типов.
Иерархии типов не имеют к ООП вапще никакого отношения.
Более того, они в 120% случаев ломают ООП.
>Уточка крякает, и б-х с ней, это уточка, хуй с этим сертификатом для нее.
Сказал как боженька.
>а если таки возникает нужда наследовать реализацию
Не возникает, никогда.
Это чисто религиозный позыв может быть.
>ломают ООП
Что-то они делают?..
Обратное тоже верно.
Уточка крякает, и х-й с ней, это уточка, главное, что сертификат есть, и бог с ней с єтой реализацiей её.
>Вот же объекты поделены, вот они взаимодействуют, никто внутрь другого объекта не лезет, за переменной через весь проект тянутся не нужно, что же не так?
Просто твой тимлид - хуесос. У тебя и был настоящий ООП, анончик. Уходи оттуда, если не ушёл ещё.
вся суть обсуждений ооп в интернетах:
250 постов и ни строчки кода
250 постов и ни строчки кода
Тут вкатывальщики с лабами2 за архитектуру энтерпрайза рассуждают, не мешай.
> за архитектуру энтерпрайза
Бтв, друг рассказывал, ООП в 2,7 раза веселее, при активном использовании метапрограммирования в ран-тайме, энтерпрайзу и не снилось.
Бтв, друг рассказывал, ООП в 2,7 раза веселее, при активном использовании метапрограммирования в ран-тайме, энтерпрайзу и не снилось.
В рантайме - это долбоебизм. Раскрытие макросов должно происходить перед компилляцией.
Не обижай @dhh, плохой ты мальчик. Смотришь на рантайм депенденси ресолвер менеджер релисы и просветляешься.
Похуй на интерпретируемую парашу. В нормальнах языках депенденсы резолвятся через граф зависимостей.
Ну и живи дальше в своем ко-ко-компилируемом манямирке, противный.
А вот и динамикогоспода подъехали. Вечер в хату, подходи, присаживайся возле двери
ну, епт, они даже на реализацию adhoc полифорфизма в крестах не сагрились
обычно если есть в треде фп задрот он сразу на это визг поднимает
в общем, слабенько
Не совсем согласен. По моему мнению, для ООП достаточно существования объектов (внезапно, да). Что такое объект - это некоторый отдельный кусок данных и некоторый набор функций, которые связаны с этим куском данных. То есть скорее всего примерно тоже самое, что и модуль в твоём посте, но только не модуль, а некоторая единица, которая в принципе может и не поддерживать сокрытие данных на уровне языка.
Нет, я не прав. Объект - это просто набор функций, пользователю объекта не обязательно даже знать, что у объекта есть какие-то данные.
Двачую .NET господина, а ещё все кофе машины - стандартные и работают только под Windows, впрочем как и офис с работниками.
System.Console.WriteLine("Ydy, podmoysya, Manyaaa!");
System.out.println("Sosi hui bidlo!");
Джава рулет, пасаны угорайте по кроссплатформенности, бейте спермохлебов, ломайте винду, пишите смело прямо в интерпретатор:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3; //String Wuindows must die!
5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
Байт код?
Почему шитый код так мало используется?
>Объект - это просто набор функций, пользователю объекта не обязательно даже знать, что у объекта есть какие-то данные.
Это пространство имён.
Объхекты — они именно с данными. В єтом йих смысел.
Потому что даже для форта сейчас есть нормальные компиляторы с оптимизацией.
Не, ты чо, пехапешник написал запрос в мускул. Что в общем-то тоже отражает суть: пока остальные пиздят, пехапешники хуярят.
Тот пехапешник, что реквесты к бд из вьюх хуярит? Сильный ООП-программист, ничего не скажешь.
>пока остальные пытаются питаться правильно или хотя бы вовремя добегать до туалета, пехапешники снимают штаны и хуярят
Ну такой себе повод для гордости.
>250 постов и ни строчки кода
А зачем тебе код? Ты не способен мыслить абстрактно? Какой же ты тогда программист. Ты, наверное, из этих, из джявистов? Стек-оверфлоу-дривен девелопмент во все поля, да? Даже на борде уже попиздеть не можешь без того, чтобы код откуда-нибудь скопипастить, мразь.
Проверь ancestors у слоника, чёт он какой-то неправильный и грустный.
У него Fragile base class
>У него Fragile base class
Не у него, а он и есть этот самый класс. Будьте же людьми, говорит, не складируйте в меня сладкий хлеб.
> как работать с ООП правильно
Правильно работать так:
1) в случае если сам себе хозяин - как тебе удобно;
2) в случае команды - как тимлид велит.
И ниибёт.
>но тимлид говорил "Неее, это процедурщина, давай заново"
ООП - это и есть процедурщина, лол.
>я открыл гугл и охуел
Ну да, ооп не существует. То есть оно существовало когда-то, но было сто раз закопано и превратилось в базворд, спасибо маркетолухам.
Вообще ооп всегда было чисто маркетологической фичей. ООП должно было решить проблему "кризиса программирования". Что такое кризис программирования? Маркетологи обычно отвечают что-то вроде: "ну тип все писали маленькие программы и копипастили код, а потом понадобилось писать большие программы и повторно использовать код, чего обычный процедурный подход не позволял делать".
Это, конечно же, ложь. До ооп код был более чем модульным, см те же емаксы, юниксы и техи.
В действительности кризис программирования выражался в следующем: все больше компаний вливалось в ойти, требовалось все больше программистов. Но чтоб писать модульный и красивый код на сях, лиспе или любом другом не ооп языке, нужно иметь скилл. Симула-стайл ООП придумали для того, чтоб создать инструмент, насильно принуждающих говнокодеров писать более модульный и абстрактный код с реюзом и проч.
Иными словами симула-стайл ооп придумали для того, чтоб макаки тоже могли писать код. Надо ли объяснять, что вскоре макаки придумали, как писать лапшу на жабе, и все вернулось на круги своя (только кода теперь в десять раз больше, ибо вместо простых конструкций теперь десятиэтажные иерархии)
http://loup-vaillant.fr/articles/deaths-of-oop
>function в качестве лямбда-оператора
Это ты сейчас ml из функциональных языков выписал, умник? Ох уж эти хаскеллисты местные.
Вот тут под каждым словом подпишусь.
> нет никакого четкого однозначного ответа, примера о ООП
Java Cryptography Architecture
.NET Security
Java Cryptography Architecture
.NET Security
>которая в принципе может и не поддерживать сокрытие данных на уровне языка.
Ну так я ж и говорю, в той же Модуле и Обероне можно было определить что ты выставляешь из модуля наружу, а что нет.
Еще один пидорас разделяет ООП и функциональщину, найс
То есть ООП это отказ от естественного синглтон паттерна в модульной парадигме, при возможной максимальной открытости? Ну в целом зайдет, но отсутствие ипкапсуляции - ну не знаю, хуево это.
>(OP)
>Чем все закончилось-то с тимлидом?
Послал нахуй этого мохрового долбоеба, ибо это у него процедурщина.
Че за срач, я не пойму? Ооп мне помогает тем, что наследование и прочая хуйня есть, чего нет в процедурках. И код короче и понятнее.
/тред нахуй
/тред нахуй
>что наследование помогает
Увозите этого в дурку
Школьник, уймись
За ультимативный вскукарек, о том что тебе помогают сильные формы связи, за это сажают на бутылку. И правильно делают. Предпочитай композицию над наследованием.
Какой жи ты мерзкий петухан.
Ну да, огня из кремня не существует. То есть он существовал когда-то, но было сто раз закопан и превратился в базворд, спасибо маркетолухам.
Вообще огонь из кремня всегда было чисто маркетологической фичей. Кремень должен был решить проблему "кризиса огня". Что такое кризис огня? Маркетологи обычно отвечают что-то вроде: "ну тип все как лохи палочки терли, экстремалы за молниями бегали, потом как лохи за кострами смотрели, а внезапно понадобилось разводить повторно огонь и забить на блядские палочки".
Это, конечно же, ложь. До кремня огонь был святым посланием богов в виде молнии, см те же наскальные рисунки и узелковые послания.
В действительности кризис огня выражался в следующем: все больше общин вливалось в жор, требовалось все больше смотрящих за огнет и трущих палки. Но чтоб развести огонь на сыром дереве, намолить дождь или угореть по грибам, нужно иметь скилл. Кремень-стайл огонь придумали для того, чтобы создать инструмент, насильно принуждающих слабков и ленивцев вызывать огонь когда они вздумают.
Иными словами Кремень-стайл огонь придумали для того, чтоб ленивые макаки не сдохли от холода. Надо ли объяснять, что вскоре хилые макаки придумали, как жарить мясо, и все вернулось на круги своя (только огня теперь в десять раз больше, ибо вместо специальных людей и шаманов теперь кто угодно)
пещерный человек об огне и способах его добычи
студентик, плес
Давай объясню. Когда ты наконец-то закончишь свою шарагу и попадёшь в уютненькую говноконторку, тебе дадут какой нибудь ультрапримитивный таск, типа сделай архивирующую сохранялку для нашего кокореша. Начав делать таск, ты обнаружишь, что в проекте уже есть сохранялка, только не архивирующая. Ты создашь её наследника, что-то там в нём переопределишь и доимплементируешь, всё простестишь и закроешь таск. На ближайшем код ревью, тима поставит тебя к стенке, обольёт из брандспойта и ебанёт пару раз шокером. Таск будет справедливо завёрнут на реимплементацию.
На второй раз ты что-то вспомнишь про композицию, и на этот раз напишешь чистый класс, в котором создаётся объект обычного логгера и оборачивается слоем архивирующей логики. На близжайшем код ревью тебя опять же поставят к стенке, обольют из брандспойта и ебанут шокером пару раз.
Наконец, на третий раз, когда ты что-то вспомнишь про агрегацию и используешь DI, таск будет принят, и ты, волосатая макака, будешь приучена как нужно делать правильно. Жаль конечно, что всё такими вот примитивными средствами обучения, но что поделать, если ты, сука, тупое животное.
>Петушиные кривлянья, опущенские понты, и мерзкое юродство.
>Какой жи ты мерзкий петухан.
Мда.
Тот анон на 90% прав.
А твоя петушиная "аналогия" в корне ошибочна.
Инкапсуляция есть как в ООП так и в модульном программировании. Просто в ООП, у тебя вместо модуля его первоклассные экземпляры. Это всё принципиальное отличие.
>До кремня огонь был святым посланием богов в виде молнии, см те же наскальные рисунки и узелковые послания.
>был святым посланием богов
Как ООП-макака видит код настоящих программистов, лол, посланием богов. Действительно, TeX и UNIX - послания богов в сравнении с типичным тырпрайз поделием в виде морде к бд на 20млн строк кода.
Ебал твою мамашу.
тяны вообще дают или как?
Мамка твоя дает.
>код настоящих программистов
Тупопездное выражение. Любой кто управляет выч.техникой - программист без градаций настоящести.
Так-то программирование граммотность 21 века, потому умерь свой снобизм и представь себя в конце 19 века, такого красивого, умного, умеющего читать и писать на трех языках один из которых функциональный мертвый и вдруг такой обсер перед деревенским быдлом: ЩА ТУТ ШОП МЕНЯ ЧЕРНЬ УЧИЛА ЧИТАТЬ ДА У МЕНЯ ПОТОМСТВЕНЫЕ ГЕНЫ ПЕРЕВОДЧИКА А МОЙ ДЕД ПЕРФОКАРТЫ ЕБАЛ
>без градаций
Вовсе нет, бывают просто говнокодеры - а бывают и безнадежные дебилы, вроде тебя.
Есть люди, которые узнали про какой-то принцип и думают, что его нужно придерживаться всегда, иначе произойдет что-то страшное, какой-то большой-большой взрыв. Это долбоебы. Когда пишешь код нужно руководствоваться не абстрактным говном, а практическими соображениями: насколько код понятный, насколько легко его будет поддерживать. Думать наперед, короче.
Что касается конкретно ООП: использовать какую-то одну парадигму в чистом виде - это полнейший долбоебизм. Человек не мыслит только в объектно-ориентированном стиле или только в функциональном или еще в каком-то. Человек использует абстракции из разных парадигм. Нужно писать так, чтоб было понятно и хорошо поддерживалось. Это единственный критерий. Любой нормальный современный ЯП должен быть мультипарадигменным. Пока что лучше всего в этом плане Scala.
Может возникнуть вопрос, как узнать, что будет понятно другим людям? Ну, нужно не быть дауном, изучать CS и математику, всякие общие для программирования принципы, иметь широкий кругозор. Индусы так не могут, поэтому молятся на ТДД, паттерны из ГОФ, СОЛИД и прочую индусскую хуету, а как только видят, что кто-то их религии не придерживается, у них сразу начинает идти пена изо рта.
>2ch.mail.ru/зк
>Думать
>не быть дауном
>изучать CS и математику
>иметь широкий кругозор
привет ты че охуел))))
Добавлю все-таки, что СОЛИД не такая уж хуета, нормальные принципы, части из них я стараюсь следовать, но эти принципы можно понять просто читая чужой код и руководствуясь здравым смыслом, не нужно их специально учить и, тем более, воспринимать так серьезно, как это делают некоторые адепты.
Поучи меня еще, щенок. Я тебе ебало сломаю и обоссу еще в добавок.
>эта фантазирующая девственная омежка
Ясно.
> На ближайшем код ревью, тима поставит тебя к стенке, обольёт из брандспойта и ебанёт пару раз шокером.
Не будет такого.
мимо-тимлид
ЗАО "Пилим госзаказы", надо полагать?
Нет, работаем только с бизнесом, в том числе с зарубежным. Не галера.
Будет, будет
мимо тимлид из нормальной конторы
Инкапсулирование - это не только ограничение доступа к интерфейсам, но и ограничение по видимости переменных экземляра класса, даже когда те находятся в public.
>Человек не мыслит только в объектно-ориентированном стиле или только в функциональном или еще в каком-то. Человек использует абстракции из разных парадигм. Нужно писать так, чтоб было понятно и хорошо поддерживалось. Это единственный критерий. Любой нормальный современный ЯП должен быть мультипарадигменным.
Очень часто встрачаю этот тезис, и всякий раз удивляет и смешит одно и то же: произносящий его человек, как правило, не умеет привести внятного примера ситуации, в которой ООП даёт сбой, то есть категорически неэффективен. В лучшем случае кукарекают про конечные автоматы на метках, но это как бы не совсем хороший пример, да и ирл с конечными автоматами на практике сталкиваются единицы за пределами институтских лаб. Удиви меня, а? Ну пожалуйста.
Еще раз, чтобы исключить слив на холивар: я не утверждаю, что таких ситуаций нет, но я хочу, чтобы именно ты, как автор процитированного вскукарека, привел внятный бытовой пример, не связанный с численными методами и оптимизацией под высокие нагрузки. Вот где-то там на уровне всех этих кофе-машин выше по треду, плиз.
bool fileExists = Net.OS.Windows.MustDie.Filesystem::Static::This.Self->FileExists(Net.OS.Windows.MustDie.Filesystem::CHECK_EVERYWHERE, Net.OS.Windows.MustDie.Filesystem::IGNORE_FUCK_YOU as Boolean) or die(Net.OS.Windows.MustDie.OOP::SUXX::USE_NAMESPACES_INSTEAD);
>Так-то программирование граммотность 21 века
И че, теперь каждый, кто писать умеет - Лев Толстой, и может называться писателем?
Ну уж хуй, есть программисты, а есть говнокодеры.
>Ну уж хуй, есть программисты, а есть говнокодеры.
Спешу развеять твои наивные мечты.
Хоть джава программист, хоть пишешь ты на си.
Неважно где и как, ты хаскель изучил.
Ученым ты не стал, и миру не открыл,
Ни новых горизонтов, ни истин старых быль.
Ты просто грязный раб, конвейерный дебил.
Нет-нет, это пример не самого удачного дизайна с применением замаскированного под ООП процедурного подхода. Так и знал, что начнешь сливаться с темы, петушок, ну ёбаный же стыд.
>Ученым ты не стал, и миру не открыл,
Wrong.
Дальше не читал.
bool fileExists = Filesystem->fileExists(CHECK_EVERY_WHERE | IGNORE_FUCK_YOU);
Что за хуйню ты написал? Причем тут ООП?
Тебе спросили где ООП дает сбой а не просили срать тут
другой анон
>Покажите мне неудачный дизайн
>Нет-нет, это пример не самого удачного дизайна
>Так и знал, что начнешь сливаться с темы, петушок
>Wrong.
>Дальше не читал.
Стол учоным на харкаче?
Доктор анонимных наук?
Доцент траллинга?
Открыл принцип сохранения батхерта?
Если ты ученый, то ты уже не программист.
А то, с тем же успехом ученый может называться грузчиком, от того, что дома временами мебель переставляет.
Но это ж необычный грузчик, есть будлогрузчки, а есть тру грузчики.
>Покажите мне неудачный дизайн
Перестань долбиться в глаза и прочитай еще раз, что я просил:
...привести внятный пример ситуации, в которой ООП даёт сбой, то есть категорически неэффективен
Не пример неэффективного ООП и не смищнявочки вроде тех, что ты тут высрал, а пример задачи, которую в принципе нельзя эффективно решить через ООП.
Оке, весь SOLID - доказательство неффективности ООП. Классы, состоящие из 1 метода. Придумывание названия абстрактным фабрикам билдеров декораторов, передача инстанса класса для выборки из коллекции вместо лямбды.
Да пиздец, без элементов функциональщины ООП жрать могут только отборные копрофаги
Ну тогда погугли «Linear Algebra and its Applications». Любая вычислительная задача, которая вызывает большое количество прыжков по оперативной памяти — решается процiдурным быдлокодом. Потому, что всё упирается в кеш процессора, вот почему.
>и не смищнявочки вроде тех, что ты тут высрал
Ты меня с кем-то путаешь.
Я в шоке от 15летних ньюфагов путающих имейджборду с форумом.
Сириусли, раньше школьники легко определяли собеседников.
>пример неэффективного ООП
Критерий эффективности коков?
Тот кот, приведенным тем аноном, вполне себе пример, вполне себе неэффективности.
Неудачный дизайн, внезапно, неэффективен.
А ООП ведет к неудачному дизайну почти везде.
По крайней мере джава ооп.
А ООП вообще ->
>вычислительная задача, которая вызывает большое количество прыжков по оперативной памяти
Я это специально оговорил, см. пассаж про конечные автоматы и численные методы.
>ООП ведет к неудачному дизайну почти везде
Такое же безапелляционное утверждение, как и исходный вскукарек. Поясни на примере с контрпримером, использующим другую парадигму.
>как и исходный вскукарек
Это ты о чем?
>Такое же безапелляционное утверждение
Тебе кажется.
Апеллируй сколько душе угодно.
>Поясни на примере с контрпримером, использующим другую парадигму.
1) Что ты под "другой" парадигмой подразумеваешь? ООП это принцип, а не парадигма. Или ты о джаве?
2) Извинись за свое хамство в отношении меня, и за свое мерзкое поведение в целом. Тогда я подумаю, стоит ли тебе что либо объяснять, или нет.
О, эти жалкие манявры. Как я и предсказывал, петушок не понимает смысла собственного же кукарекания.
>лээ блэт извинис, ваша парадигма не парадигма, маам ну скажи им
Не продолжай, все уже всё поняли.
> ООП это принцип, а не парадигма
Без гугла сможешь рассказать, в чем разница, и доказать, что ООП - не парадигма?
Только на хаскеле.
Как насчет перестанешь маняврировать и ответить на ?
Как насчет навернуть /го/вна.
Я думаю ему лет 12, если не 10.
Так что просто забей.
Как ты узнал что мне 11?
По твоей фотке с флажком в жопе из /b/
Зарепортил педофила.
Немного философии.
ООП это программирование на уровне сущностей.
Каждый объект, как маленький живой организм, клетка. Есть функции рождения и смерти, размножения и реакции на окружающую среду.
И вся ООП программа получается как большой организм. Насколько он будет живучим, зависит от качества программирования, от живучести всех составных объектов.
Процедурки - это программа-механизм или одноклеточный монолитный организм. Может как нибудь реагировать на внешние и внутренние события, присоединять и отсоединять свои части, но рождается и умирает при запуске и завершении программы.
Ну ты тоже хорош: «Ко-ко-ко приведи пример кагда ниработает‽¿» Зачем возводить все в абсолют? Даже думать не хочу сколько абстракций нужно возводить на обработку чего-нибудь асинхронного, если для решения достаточно шпонькнуть каллбек на замыкание, это буквально две скобочки поставить. И это круто если в оопе можна юзать функцие первого порядка, пусть они и называются по-другому. Так что вскукареки о мультипарадигменности не понимаю. Другой анончик
возможно
>Как насчет перестанешь маняврировать
Ну а на что там отвечать-то? На "солед гавно"? Там там на каждую букву можно отдельный срач развести, это ж тупо очередная попытка слиться. Если ты имел в виду, что вон, мол, к этому вашему ООП еще инструкции в виде соледов-хуёледов читать надо, чтобы не срать в штаны - ну так я тебя разочарую: нет и не будет парадигмы или механизма, заставляющего писать хорошо. В том числе на твоих любимых блямбдах макароны пишутся, пожалуй, еще более ветвистые, чем на классах.
Ну вот ты и привел более-менее нормальный пример. Собственно, я от него примерно это и хотел бы услышать, но результат был немного предсказуем.
>И вся ООП программа получается как большой организм.
Ага, единый организм говно.
>Ну а на что там отвечать-то? На "солед гавно"?
Ты жопой читаешь.
>Придумывание названия абстрактным фабрикам билдеров декораторов
Вот тут, кстати, отдельным постом выскажусь, ибо повод для отдельного срача.
Дело в том, что язык (человеческий я имею в виду) в программировании очень важен, про это все время забывают. Это прекрасный детектор говнища. Если для класса или метода трудно придумать название, как в примере выше - значит, выделены хуевые абстракции и надо делать по другому. Любовь масс к элементам функциональщины зачастую обусловлена именно тем, что лямбдам можно не давать имени. Так шахтеры, заебавшись выскакивать из забоя раз в полдня из-за постоянно срабатывающего газоанализатора, вырубают его нахуй; ура, план план перестает проебываться = но, увы, через некоторое время проебывается шахта вместе с планом и шахтерами.
>Немного философии.
Это неудачная аналогия, а не философия.
>Дело в том, что язык (человеческий я имею в виду) в программировании очень важен, про это все время забывают. Это прекрасный детектор говнища.
Тащемто, ты реально "философствующий" школьник, натырыбонькался из википедии всякого, и давай умствовать.
>повод для отдельного срача
Так ты просто срач разводишь? Покакулин?
Дело в том, что в компутере, нет ничего человеческого.
Единицы и нолики, регистры, кеши, прочие машинные потроха.
Поэтому человеческий язык, для управления комлуктером, не подходит от слова совсем.
И чем более человеческим языком ты пытаешься комплуктером управлять, тем хуже и непредсказуемее получается результат.
>Дело в том, что в компутере, нет ничего человеческого.
Спорное утверждение. Как минимум он продукт человеческой мысли и реализует механизмы, придуманные человеком.
>Единицы и нолики, регистры, кеши, прочие машинные потроха.
Ты только что сам себя опроверг, описав эти механизмы нормальным человеческим языком.
>Поэтому человеческий язык, для управления комлуктером, не подходит от слова совсем.
Утверждение основано на ложном тезисе и, таким образом, само является ложным.
>И чем более человеческим языком ты пытаешься комплуктером управлять, тем хуже и непредсказуемее получается результат.
Заблуждение пошло ветвиться и развиваться.
Вся история развития языков программирования демонстрирует постепенный переход от внутренних абстракций вычислителя к абстракциям, удобным для понимания и выражения человеком для человеческих же задач. Ты просто пытаешься прикрыть уязвленное самолюбие софизмом и жалобными воплями про шкальников и википузию.
Я утверждал и продолжаю утверждать, что если у погромиста вызывает затруднение именование некой абстракции - это верный сигнал того, что абстракция хуевая, что сфера ответственности этой абстракции размыта, что в будущем с хорошей вероятностью приведет к катастрофе.
JS, конечно не функциональный ЯП, но это не отменяет что ты высираешь информацию о том, чего абсолютно не знаешь. Ознакомся с предметом для начала, чтобы дебилоидом не выглядеть.
Он прав, а мамкин словоблуд тут ты, причем очень унылый. У компьютера свои абстракции, своя терминология и особенности, и пытаться адаптировать этот мирок в мирок привычный для человека работает до определенной степени, но в конце-концов когда дело доходит до передовых и реально нужных вещей все спускаются с маняоблачка привычных человеку ОБЫЧНОМУ понятий и описывают мир в понятиях придуманых специально для машины и удобства вычислений.
А все твои мартыханские описания предметной области естественным языком работают только в тех рамках, на какие хватило ума писавшим очередную говнобиблиоткеку.
>Спорное утверждение. Как минимум он продукт человеческой мысли и реализует механизмы, придуманные человеком.
Это софистика.
Можно в чем угодно пытаться узреть человеческое.
Даже в небе, даже в Аллахе.
Можно прийти к телесности мира и спящему Адаму.
>Ты только что сам себя опроверг, описав эти механизмы нормальным человеческим языком.
Я их описываю человеку. Поэтому язык человеческий.
На самом деле язык неформальный, но ты такой упоротый, что об этом лучше даже не пытаться говорить. Компьютерам подходят формальные языки, причем не все, а только те, которые близки к внутреннему устройству компутера.
А вот ДЛЯ КОМПЬЮТЕРА, решение задачи нужно описывать компьютерным языком, он, человеческого не понимает.
>Утверждение основано на ложном тезисе и, таким образом, само является ложным.
Тезис верный. См выше.
А ты совершаешь смешные логические ошибки, и вообще, просто "умствуешь", о вещах, в которых ничерта не понимаешь.
Более того, даже размышлять ты не умеешь, логика ломается через каждые два слова.
>Вся история развития языков программирования демонстрирует постепенный переход от внутренних абстракций вычислителя к абстракциям, удобным для понимания и выражения человеком для человеческих же задач.
1. Нет. Не демонстрирует.
2. Подобная очевидная потенция не отменяет того факта, что программы с таким подходом работают хуже.
>Ты просто пытаешься прикрыть уязвленное самолюбие софизмом и жалобными воплями про шкальников и википузию.
Я думаю, в скором времени, станет возможным давать задание комплуктеру неформальным языком. Постепенно эти технологии внедряются, и вероятно лет через 20, потребность в идиотах вроде тебя, вбивающих код, отпадет.
>Я утверждал и продолжаю утверждать, что если у погромиста вызывает затруднение именование некой абстракции - это верный сигнал того, что абстракция хуевая, что сфера ответственности этой абстракции размыта, что в будущем с хорошей вероятностью приведет к катастрофе.
Нет ничего идеального.
Пиздец, мамкины хаскелисты весь тред засрали.
>весь SOLID - доказательство неффективности ООП.
Чот не могу понять этот кукарек. Как рекомендации по написанию классов могут быть доказательством чего-то.
Сам солид ведет к очень хорошему дизайну, если не расшибать лоб об крайности в 1 класс = 1 метод (для такого годятся статические стейлесс хелперы с кучей похожих методов).
>передача инстанса класса для выборки из коллекции вместо лямбды
Лол, это норма. Твоя ебаная лямда имеет захваченые аргументы т.е. некоторое состояние и функцию предиката выборки - т.е. она суть каноничный объект класса, и я не понимаю, какой укурок догадался запихиваь его в функцию у которой очень неочевидные правила захвата переменых. Функционально-петушиное лабоуми не иначе.
Дико двачую. Если чему-то трудно дать нормальное имя без слов-маркеров размытой всеобщности, то это говно.
Опять же, было ещё в модульном программировании.
Какое ещё состояние? Под состоянием обычно понимается что-то мутабельное, в то время как в нормально ФП языке захваченную переменную ты изменить не можешь, ни снаружи, ни изнутри, так что referential transparency не нарушается, в отличие от маняобъектов, для которых, к тому же, даже не определена операция композиции.
> Если чему-то трудно дать нормальное имя без слов-маркеров размытой всеобщности, то это говно.
> это говно.
Или регулярное выражение.
>А вот ДЛЯ КОМПЬЮТЕРА, решение задачи нужно описывать компьютерным языком
Ну так и описывай на здоровье. Только вот компьютеру внезапно насрать, как ты обзываешь свои абстракции. Он перемелет все, что проектанты хуевы вроде тебя выблевали в IDE. А кому не все равно, догадаешься сам или подсказать, хомски ты комнатный?
>того факта, что программы с таким подходом работают хуже
Настало время охуительных фактов. Ну-ка, поведай миру, как абстракции вроде abstractComponentModuleFactoryBean, $x1 или movEaxEbx() заставляют программы работать лучше.
>Нет ничего идеального
Так можно говорить про хорошие вещи, дальнейшие попытки улучшения которых приводят к неприемлемым сайд-эффектам. Про говнище, которое ты привык высирать в виде кода и которое ты тут пытаешься оправдать, так говорить нельзя.
>в то время как в нормально ФП языке
Так речь не про "нормальные", а про объектные с блямбами. Например, в легендарном языке PHP объекты всегда передаются по ссылке, таким образом, захваченному в переменной объекту можно менять состояние в два смычка. А в популярном языке JavaScript захваченная переменная просто видна изнутри как локальная, этим часто пользуются для создания аналога private-переменных.
Так что в целом я согласен с предыдущим оратором: блямба в целом эквивалентна объекту с методом. В довольно узком ряде случаев они бывают удобны (в основном когда их объявление и использование происходит в пределах одного блока кода), но вот передавать их аргументами в методы в общем случае вряд ли можно считать хорошей практикой.
> А в популярном языке JavaScript захваченная переменная просто видна изнутри как локальная, этим часто пользуются для создания аналога private-переменных.
По твоему если ты передаешь javascript объект, егj состояние нельзя менять в два смычка?
>По твоему если ты передаешь javascript объект, егj состояние нельзя менять в два смычка?
Может, и можно, не помню уже. Явная немутабельность вообще не так уж и часто в языках встречается, в расте вот разве что.
Rust
ML
Haskell
Clojure
Erlang
Ada
Swift
Не так уж и редко
>Haskell
Такого языка не существует, это локальный мем /зк/.
Мутировать захваченные объекты тебе никто не запретит. Как и писать ебанутые иерархии наследования с god-классами, которые не используют IoC. Хочешь стрелять себе в ногу - пожалуйста. Писать говно можно используя любую парадигму.
managedByVasya= users.Where(new UserFilterByManager(managerName: "Vasya")) требует написания никому нахуй ненужного класса UserFilterByManager (имплементацию опустил потому что нахуй всё это нужно).
managedByVasya = users.Where(user => user.Manager.Equals("vasya")) лаконично делает то же самое.
Нет никакого смысла писать код ради кода.
Учитывая что все современные компьютеры построенны на гарвардской архитектуре - если тебе очень-очень хочется, ты сможешь мутировать всё что угодно. Даже код. Было бы желание.
ЭЙ ТАМ ЗА ОКНОМ! ДА-ДА, ВЫ, АЛКАШНЯ! А НУ ХВАТИТ ШУМЕТЬ! СЕЙЧАС ПОЛИЦИЮ ВЫЗОВУ!
>Мутировать захваченные объекты тебе никто не запретит.
Як не запретит, запретит. Вон цельный список запрещаторов накатал. Но не суть.
В твоем коде как раз узкая задача (фильтрация) и использование сразу после объявления, здесь блямба отлично зашла.
Кстати, тут хорошая такая мина замедленного действия из-за этой блямбы. В отличие от сконфигурированного фильтра, она не поддается сериализации, а значит, как только возникнет необходимость, скажем, вывести базу юзеров в микросервис, мамкин функциональщик заебется все это рефачить.
Это не значит, естественно, что так нельзя делать, просто важно понимать, что там, где задействованы лямбды, масштабированию пришел пиздец заранее.
>узкая задача (фильтрация)
Хуя, блять, узкая. В нашем 5М LOC проекте примерно 15% кода - работа с коллекциями.
НЕТ, ВЫ ПОСМОТРИТЕ НА НИХ. ОБМАЖУТСЯ СВОИМ ООПЕ И ДОЛБЯТСЯ ДРУГ В ДРУЖКУ И ДОЛБЯТСЯ. ПОЛИЦИЯ! ПОЛИЦИЯ!
Узость задачи никак не связана с частотой.
1) Если вы выделяете что-то в микросервис, в первую очередь надо думать над API к нему. Мамкин функциональщик наткнется ровно на такое же кол-во проблем, что и оопидор.
2) Сериализацию лямбд в expression tree никто не отменял.
ПИУ! ПИУ! РАБОТАЕТ СПЕЦНАЗ! ВСЕМ ЛЕЖАТЬ! ВЫ АРЕСТОВАНЫ! СОПРОТИВЛЕНИЕ БЕССМЫСЛЕННО! ПИУ! ПИУ!
аноны, матанопитухи спрятались под шконарь и нехуя за базар не поясняют. НАХУЙ функциональное программирование нужно? в чем его преимущество перед процедурным и ооп? какие бля задачи я не смогу без него решить? ну это же очередной развод хипстерков лошков, со стороны жидоматематиков, ну еб.
Брейнфак - тьюринг полный. На нем можно решать все вычислимые задачи. Поясняй, нахуй нужны другие языки программирования.
>Брейнфак
>На нем можно решать все вычислимые задачи
ну решай, вычисляй, поддерживай, кто тебе не дает
> НАХУЙ функциональное программирование нужно?
кококо Quipper (диалект хаскеля) кококо Квантовые вычисления кококо Гугл. Ну как-то так.
Ходят слухи, что передовой функциональный петушатник гугла пытается в квантовые алгоритмы на Квиппи. Больше не знаю зачем нужна.
АХ ДА РУКИ НЕ ОПУСКАТЬ, ДЕРЖАТЬ НА ВИДУ, НОГИ НА ШИРИНЕ ПЛЕЧ, ПОПКУ ВПЕРЕД! ВЫ АРЕСТОВАНЫ ЗА НЕЗАКОННЫЙ МИТИНГ У СЕБЯ НА КУХНЕ.
Итак, где твое объяснение зачем нужны другие языки программирования?
>Итак, где твое объяснение зачем нужны другие языки программирования?
объясняю, они уже есть, есть библиотеки, есть обученные люди, есть продукты. теперь ты объясняй, нахуй нужна функциональщина?
Не объяснение нихуя.
объясняю, она уже есть, есть библиотеки, есть обученные люди, есть продукты.
>квантовые алгоритмы
на квакваквантовом кампутере? лол
>объясняю, она уже есть, есть библиотеки, есть обученные люди, есть продукты.
джва с половиной хипстера и их лисапед?
>Quipper
Само по себе существование такого языка с высокоуровневыми абстракциями и реализованными на нём алгоритмами поможет в создании новых алгоритмов для квантовых компьютеров, считают авторы языка Quipper.
а, ну теперь понятно, авторы этой хуеты считают, что нужно.
Ты и твоя мамаша.
лямбду тебе защеку
>Если вы выделяете что-то в микросервис, в первую очередь надо думать над API к нему.
При чем здесь API? Речь идет о выделении уже написанного фрагмента программы, а не изначальном проектировании.
>Мамкин функциональщик наткнется ровно на такое же кол-во проблем, что и оопидор.
Оопидору придется только переписать реализацию Where, захуярив оттуда обращение к микросервису, и допилить сериализацию фильтра, если ее еще не было. Сам код переписывать не придется.
>Сериализацию лямбд в expression tree никто не отменял.
НЕТ НИКАКОГО СМЫЛА ПИСАТЬ КОД РАДИ КОДА, лол.
Все эти элементы функциональщины в ОО-языках - обычное срезание углов, жертвование гибкостью ради сиюминутной экономии. Где-то можно и пожертовать, но подавать этот тришкин кафтан как неебический прогресс просто смешно.
>managedByVasya = users.Where(user => user.Manager.Equals("vasya")) лаконично делает то же самое
Нет не делает, а поощряет копипасту и говнокод.
Три таких лаконичных лямды в разных местах программы делают тебя снчало грустным, а потом упаковываются в объект предиката, который обладает внезапно большими возможностями фильтрции, чем вытесянет половину скобочно-стрелочной копипастной дрисни из проекта.
А предикат инициализируется лямбдой. Оухенно, ящитаю.
>>Сериализацию лямбд в expression tree никто не отменял.
>НЕТ НИКАКОГО СМЫЛА ПИСАТЬ КОД РАДИ КОДА, лол.
В нормальных языках это есть из коробки.
>Оопидору придется только переписать реализацию Where, захуярив оттуда обращение к микросервису, и допилить сериализацию фильтра, если ее еще не было. Сам код переписывать не придется.
То же самое с мамкиным функциональщиком
>В нормальных языках это есть из коробки.
Да вот только микросервис может быть написан на другом языке, так что коробку свою на хуй себе надень.
> в которой ООП даёт сбой, то есть категорически неэффективен
При чем тут категорически неэффективен? Можно и на чистом си все писать, и работать будет, но зачем?
Полно примеров, когда уродливо и в 10 раз больше кода, чем должно быть. Например, до 8й джавы не было лямбд и чтобы передать коллбэк создавали анонимный класс. Есть такой поехавший адепт ООП Егор Бугаенко, который считает, что так до сих пор и надо делать, лямбды нельзя использовать, потому что это не в духе ООП.
Я лучше себе твой анус на хуй надену.
Кто о чем, а функциональшик об анусах.
Снимай штаны уже.
>Полно примеров, когда уродливо и в 10 раз больше кода, чем должно быть. Например, до 8й джавы не было лямбд и чтобы передать коллбэк создавали анонимный класс.
Надо же, как все уцепились за эти лямбды, прям кушать не могли без них. Они хороши для набросков, для прототипов, но они не фиксируют контракта, это мусор, записки на туалетной бумажке, примотанные скотчем. Это нормально - иметь какие-то локальные компактные помойки такого рода в коде; но постоянно раздаются голоса о некоем прорыве. Хуй знает, что там у кого прорвало, по мне так у нас есть теперь удобная туалетная бумажка для набросков, только и всего.
> Есть такой поехавший адепт ООП Егор Бугаенко
Обожаю его, настоящий больной ублюдок, рекурсивный тролль. Очень полезно его читать и разбирать, в чем его ошибки.
> но они не фиксируют контракта
Ты ебанутый? Лямбда это функция, её контракт это её тип. И в отличие от маняобъектов, операция композиции функций определена. ООП по типу контрактности вообще сосёт, и как показал Эфель, единственный способ это исправить - ебашить ассерты до и после каждого вызова.
Как будто в фп контракты не сосут, лол
>Лямбда это функция, её контракт это её тип
Удачи с переносимостью этого дерьма.
Сер, у вас микросервис головного мозга. Проверьтесь на переносимость!
С анонимными функциями в ООПе связана другая опасная неожиданность - каждый раз когда ты её шпонькаешь, где-то умирает один котик - причем в роли котика выступает сборщик мусора, который немножко охуевает, так можно и незаметить, как твоя программа засрет всю свободную память и будет искать чтобы засрать еще. Или попробует вызвать удаленный объект, что приведет к событию #ПИЗДЕЦ!1!!1!1
> Надо же, как все уцепились за эти лямбды
Это очевидный контр-пример against your вскукарек о мульипарадигменности. Все сравнений с функциоОНАЛьщиной ООП обоссать даже попроще - оно тупо не в состоянии полноценно заменить специализированные инструменты наподобии б-жественного Structured Query Language. Ну или твои конченные автоматы, на примере регулярок - эти тоже плохо поддаются ООПизации.
Очевидный вывод - очевиден, ООП имеет узкую степень применимости в реальном мире.
Мань, это мой первый пост и пишу я на плюсах, с микросервисами дел не имею к сожалению ( или нет ).
Под переносимостью я имел ввиду неоднозначность интерфейса функции в зависимости от контекста: поддерживает язык мультиметоды/не поддерживает, поддерживает язык функции высшего порядка/не поддерживает, поддерживает язык неявные пользовательские преобразования типа или нет. И еще дохуя подобных факторов ломают однозначность функционального интерфейса в пользовательском контексте. А ведь если взять тот же .net или jvm то учитывать придется сразу множество языков. Плюс версионирование от которого правила вывода аргументов точно так же варьируются.
>пишу я на плюсах
Это прямо как в конеебле признаться.
>...
поне- ?
А на самом деле у лаборанта выше просто про каких-то коллекторов пассажи, решил уточнить.
Нахуй ты собрался язык менять посреди испольнения программы?
Обыкновенная практика в этих ваших байткододрочильнях, VB->C#->F#->IronPython и все в одном домене.
Но ты можешь это пропустить и прочитать первую часть, про контекст в рамках одного языка.
Имея
foo ( int, wchar )
foo ( long, wchar )
Надо знатно поебаться чтобы гарантировать какие-то последовательности исполнения для
foo ( user_struct_castable_to_double, user_struct_castable_to_short_and_wchar)
Кресты правда так калечат?
x86 ассемблеру поебать на то, какие классы, интерфейсы и абстракции ты написал на своих спермокрестах. Он знает про регистры процессора, опкоды инструкций и указатели на разные области памяти. Все спеки на x86 у тебя есть.
MSIL/JVM bytecode высираются при компиляции по такому же принципу: будь добр сгенери байткод, который с поймет твоя виртуальная машина. Похуй какие у тебя там сверху абстракции, высри мне байткод по спекам JVM/MSIL.
Так он тебе именно что и высрет. Только ты не будешь значить что именно происходит для произвольного ввода. При чем тут ассемблер?
Зачем ты споришь с этим дауном? На ущербов топящих за парадигму X и хуесосящих Y надо только харкать и ссать.
Есть спек, который показывает однозначно, как перевести из MSLI/JVMbytecode в нужный язык. Где все описанные тобой нюанусы уже описаны
Ебучие ситы, возводят всё в абсолют.
>рекурсивный тролль
Это что-то новое, поясни это как?
Троллит сам себя. Очевидно же.
Но зачем?!
Хотя мне кажется, что тролит сам себя - это self-troll, а рекурсивный, это когда он затралил кого-то, то ещё кого-то и т.д.
тот*
>рекурсивный, это когда он затралил кого-то, тот ещё кого-то и т.д.
Так и есть, просто этим "кем-то" всякий раз оказывается сам Егорушка.
Меня зовут Геннадий возбудитель телок. Вы про меня слыхали нет?
>Только вот компьютеру внезапно насрать, как ты обзываешь свои абстракции.
Наверное.
>проектанты хуевы вроде тебя выблевали в IDE
Ну вот, начал с софистики, а скатился в мерзкую клоунаду и хамство.
>Настало время охуительных фактов. Ну-ка, поведай миру, как абстракции вроде abstractComponentModuleFactoryBean, $x1 или movEaxEbx() заставляют программы работать лучше.
Ты говоришь о языках, или о политике именования в них?
Названия переменных\функций\модулей должны быть лаконичными, отражать максимально смысла в минимальном объеме.
Или по твоему не должны?
Причем, лаконичность во многом зависит от общепринятых контрактов в том или ином языке(матаппарате).
>Так можно говорить про хорошие вещи, дальнейшие попытки улучшения которых приводят к неприемлемым сайд-эффектам.
Можно.
>Про говнище, которое ты привык высирать в виде кода и которое ты тут пытаешься оправдать, так говорить нельзя.
У тебя шизофрения. Я тебе своего кода не показывал. И уж тем более не пытался в чем либо перед тобой, либо еще кем-то, оправдываться.
Ты про меня слыхал нет?
Да, сегодня шел в банк мимо школы, обналичить свои 300к\c и видел как один школьник опускал тебя в мусорное ведро, а два других распотрошили твой портфель и вырывали страницы из дневника.
>Ты про меня слыхал нет?
Егор?
Илья?
Шизик?
>Шизик?
Бинго!
ну и дебилы вы тут все, это просто пиздец - что шизик с обострением, что очкастый дятел с "хамством" головного мозга
многопоточность, можно делать нормальные системы с обработкой большого количества данных в дохуя потоков не пердолясь с всратыми локами как дебил
еще код легче читается и система прозрачней.
нужно не
assertEqual f(x), f(x)
а,
assertEqual f(getCurrentState()), f(getCurrentState())
вот что вернет getCurrentState() ты не знаешь. в фяп или еще где, пофиг.
в erlang ты передаешь состояние как параметр и меняешь его отсылая сообщение или tail recursive call. в других яп ты просто по другому его меняешь. я поулачал блокировки на erlang. но я не опытен.
я имею ввиду, что sort(x) == sort(x) в любом яп. если что сложнее, то всегда есть состяние которое меняется.
в веб, у тебя состояние определяется параметрами браузера, данными в бд. в какой-то момент ты просто не знаешь что сейчас за состояние. хотя все обработчики запросов, чистые - не используют глобальные переменные, если не считать бд глобальной переменной.
https://www.youtube.com/watch?v=7Zlp9rKHGD4
Посмотри хотя бы 30 минут видео, там объясняется, почему любые переменные - это изменение стейта программы. Нет присвоения переменных - стейт остается одинаковым в любой момент времени, ничего не меняется.
>в веб
Что веб? Веб - это пользователь в браузере отправил запрос, твоя программа его обработала и отправила ответ, от работы с вебом никакой уникальности в работе программы не появляется и появиться не может.
>там объясняется, почему любые переменные - это изменение стейта программы. Нет присвоения переменных - стейт остается одинаковым в любой момент времени, ничего не меняется
Любые переменные, это область в ОЗУ компьютера.
Любое изменение ОЗУ\кеша\регистров - изменение стейта.
Нет изменений памяти - стейт остается одинаковым, ничего не меняется.
)))
Как же хочется выстрелить дробовиком тебе в лицо )))
>16:56
>Functional
>Like a function
>y=f(x)
>no external force, believe me 11111111111
>y=f(t)
>Not like a function
>Not functional111111111
Боже, это видео можно разбирать тобою написанное бесконечно.
> от работы с вебом никакой уникальности в работе программы не появляется и появиться не може
Писать отрытые, statelessness айпопишки чревато неконтролируемыми нагрузками. Хранить информацию о соединениях на стороне пользователя бессмысленно - прошаренный мамкин хакир удалит куку и будет таков.
Поэтому забудь про RESTful, чтобы хуяк-хуяк и запоминал с какого айпи-адреса и токена сколько пришло запросов. И в зависимосте от состояния ОТДАВАЛ или 200 код или 403.
Это ведь так очевидно, твоя фасоленка не способна принимать в себя толпы озлобленных папуасов с > 20 см (а хотелось бы, да?).
Нет серьезно.
Это пушка на пушке.
Просто пиздец.
Состояния нет, поехавшие.
У любой программы есть минимум 2 состояния.
Блядь.
Не бывает систем без "побочных эффектов".
> int x=1 //x is an id that has a value
Блядь. Нет. Это псевдоним для адреса в ОЗУ.
Идиоты с расплавленными мозгами.
>x=x+1 //now x changed state
Нет, теперь процессор извлек значение из памяти в регистр, регламентировал его, и записал обратно в память.
И эта простая операция потребовала несколько последовательных изменений состояний компутера.
Операция присваивания это запись информации память.
А запись информации - оператор присваивания.
Пиздец, от присваивания они избавились, ублюдки безмозглые.
>регламентировал
инкрементировал
Вот что бывает когда жс-дегенерат пытается выдать себя за байтоеба.
Нет, они конечно тоже охренительно далеко не гении - но ты-то вообще дебил, мартышка.
Ты петух ебаный бывший сотрудник пизда тебе
Сука очкобарсук ебать я тебя обманываю хахаха
Хахаххахаха ебасоска тупая малолетка блять хаха тупой лох а ты обманка
Хаха чмырдяйко афанасиевич тупой дибилоботан
Маня плиз маня маня ахахахаха дебич плиз инфибо что в 2к17
Ахаха лох тебя попустили
Что сказать-то хотел? Словами сформулируй, а не хрюканьем.
Наркоман, никто не говорит, что ты не можешь хранить данные на сервере или что нужно отказаться от БД, потому что это ужасный стейт.
Хахаххахаха шизик дебич прийми таблетки маня
Хахаххахаха лох тупой угораю с тебя
>Да, сегодня шел в банк мимо школы, обналичить свои 300к\c и видел как один школьник опускал тебя в мусорное ведро, а два других распотрошили твой портфель и вырывали страницы из дневника.
>Наркоман, никто не говорит, что ты не можешь хранить данные на сервере или что нужно отказаться от БД, потому что это ужасный стейт.
Обоснуй вскукареки о функциональщине - то стейты у вас не мутабельные, то отдельные состояния изменяемые. Или вы из этих, которые на два стула?
>Нет, теперь процессор извлек значение из памяти в регистр, регламентировал его, и записал обратно в память.
То есть значение поменялось в результате какого-то действия, это и есть изменения стейта, хуй знает, чего ты так раскукарекался.
>Операция присваивания это запись информации память.
Не операция присваивания, а операция присваивания переменной. Слово переменная тебе объяснять нужно или сам значение знаешь?
https://8thlight.com/blog/uncle-bob/2012/12/22/FPBE1-Whats-it-all-about.html - Можешь еще почитать, там по сути то же самое, что и в видео, но статьей. А то тебе как-то сложно дается новая информация в таком формате, судя по всему.
В мире нет ничего идеального, если ты конечно не школьник-максималист. В идеальном мире ФП - да, стейт не меняется и вообще все всегда заебись. В реальном - иногда можно, но это не поощряется и нужно прыгать через жопу для достижения цели, поэтому подобное зарезервировано для крайних случаев, в остальных - просто нерационально.
как я понял
1. https://medium.com/everydayhero-engineering/elixir-variable-rebinding-342c5d0fd961
в elixir - erlang vm -- можно менять identity. но дело в том, как это работает.
2. дело в scope.
в elixier, при присваивании, в родительском контексте, значение не изменится. дело не в операции присваивания, а в том, как мы ее используем.
в видео и в статье пример с циклом. это прост опример.
если процедура не использует и не меняет переменные из родительской области видимости, то все ок, всегда: assetEqual foo(x), foo(x) -- для любого языка.
функ. языки гарантируют
assertEqual foo(x), foo(x) -- для любой foo.
но у сложной программы есть состояние. тебе как-то его нужно менять. могут быть и блокировки и что там еще.
то-есть то, что программа написана на яунк. языке еще не гарантирует что не будет блокировок.
Я УКРАЇНЕЦЬ ПОВАЖАЙТЕ МОЮ БАТЬКІВЩИНУ
ФПзадрот закукарекал, заместо процедуры.
>Слово переменная тебе объяснять нужно или сам значение знаешь?
Переменная - это абстрактная хуйня.
CPU не знает никаких переменных.
Абстрактной хуйней нельзя сделать несостоятельной состоятельную систему.
А следовательно и избавится от "побочных эффектов".
"Лекция" в приведенном видео - нелепа, и больше похожа на мотивирующие выступления сектантов вылезаторов.
В общем, есть мнение, что несостоятельные функции, и несостоятельный подход в программировании, несостоятелен.
О чем, кстати, говорится в выступлении с видео, мол
>мы хотим делать несостоятельно, но вот у нас тут есть состояния, и тут вот есть состояния, и от присваивания мы не избавились, но мы как бы будем считать что это несостоятельный код, потому что, а хуй, вот почему.
Про время которое все портит я вообще молчу, это пушка из пушек из пушек из пушек. Гипер фрактальная рекурсивная пушка.
Переформулировав,- нет IO нет проблемы.
Сумасшедшие.
Теперь понятно откуда ноги растут у доказательстве теорем через функциональщину.
Нет времени нет проблемы.
Ага.
И неважно что без времени любые расчеты бессмысленны.
И неважно, что в реальном мире на вход приходят какие угодно данные(и года угодно), которые никак обобщенно не формализировать.
И что с вычислительной системой может произойти все что угодно.
В общем это пиздец и сектанство.
Я проваливаю с этой планеты.
Поддвачну мьсе
>CPU не знает никаких переменных.
Вселеная не знает никаких CPU. Сложатся звезды - и стуннелируют электроны через квантовые барьеры, и всё - пизда рулю.
>Вселеная не знает никаких CPU. Сложатся звезды - и стуннелируют электроны через квантовые барьеры, и всё - пизда рулю.
И такое происходит периодически.
Потому ECC память и изобрели. А еще обработку ошибок.
Ты все врешь.
Не стоит так расстраиваться: мнение данного оратора можно смело проворачивать на хую - его единственным актуальным занятием является продажа себя как говорящей головы и своих книжек. Если надо продать что-то ФП-манькам, он сделает соответствующую лекцию. Одно время он даже лисперам пытался что-то впарить, но его вроде как погнали.
Собственно, библиография красноречиво поясняет:
Designing Object-Oriented C++ Applications using the Booch Method. — Prentice-Hall, 1995. — ISBN 0-13-203837-4.
Agile Software Development: Principles, Patterns and Practices. — Pearson Education, 2002. — ISBN 0-13-597444-5.
Agile Principles, Patterns, And Practices in C#. — Prentice Hall, 2007. — ISBN 0-13-185725-8.
Clean Code: A Handbook of Agile Software Craftsmanship. — Prentice Hall PTR, 2008. — ISBN 0-13-235088-2.
The Clean Coder: A Code of Conduct for Professional Programmers. — Prentice Hall, 2011. — ISBN 0-13-708107-3.
Несколько раньше он точно так же двигал за ООП.
что не гарантирует что ЕСС сработает ибо электроны в парити бите тоже стуннелировали.
>Agile Principles, Patterns, And Practices in C#
Где-то на хабропараше читал, что в одной из своих книжек по шарпу он полностью игнорит тему делегатов/эвентов, а использует допотопные обсерверы в джава-стайле. Ну и в книге копипасты много из аналогичной книги про джаву. Такой-то халтурщик-наебщик, лол.
ебать тут байтослесаря разорвало на пол треда))
Ты ебанутый школьник-максималист, никто не говорит, что нужно избавиться от IO или от любой динамики. Это сравнение ФП с другими парадигмами в вакууме. И примеры там очевидно детские, потому что лекция 40 минут и для широкой аудитории.
>его единственным актуальным занятием является продажа себя
И? Кодингом он занимался в два раза дольше, чем ты жил, и теперь захотел продать свои знания.
>двигал за ООП
Что это значит? Да, он дохуя объяснял принципы ООП-программирования, что, как, почему. Вот дал пару лекций по ФП. В чем суть твоего вскукарека? Программист должен придерживаться строго одной концепции и топить за нее, иначе он не разбирается в теме?
Ad hominem по всем пунктам.
Не было печали, вспомнили про лямбды - и понеслась, понабежали мамкины функциоанальщики.
>примеры там детские
>лекция для широкой аудитории
>Ты школьник-максималист
Ну, ладно.
>Кодингом он занимался в два раза дольше, чем ты жил,
>Ad hominem по всем пунктам.
Ну, хорошо.
>И? Кодингом он занимался в два раза дольше, чем ты жил, и теперь захотел продать свои знания.
Не время приводит к опыту, а события.
Продавать там откровенно нечего.
Но, как говорится, без лоха, и жизнь плоха.
Скоро каждый грузчик начнет семинары проводить, о своем охуенном 30летнем опыте грузчика, вдохновлять школьников становится грузчиками, ага, лолд.
>Не время приводит к опыту, а события.
Бля ну я в ахуе, мне просто нечего сказать. Охуительные истории от 23-летнего тимлида.
>от 23-летнего тимлида.
Вообще-то 19 летнего.
И судя по всему жизнь я знаю куда лучше тебя.
>Бля ну я в ахуе, мне просто нечего сказать. Охуительные истории от 23-летнего тимлида.
Я таким не занимаюсь.
Но мой знакомый в 23 уже тимлидил понемногу.
Сейчас он ведущий специалист в области.
Но это к теме отношения не имеет.
>Кодингом он занимался в два раза дольше
Извини, но кодингом он как раз таки вообще не занимался, почти в начале своей карьеры (отработав 6 лет) съебнул на менеджмент и консалт.
>отработав 6 лет
Для нормального человека это много.
К дебилам уровня /зк, разумеется, не относится.
так ты вроде все понял, а финальный вывод сделать ссыкотно?
Подозрения начинают закрадываться с самого начала - ебанутых примеров "правильного дизайна" во всех книгах - постоянные обещания хороших аналогий и метафор с прикладной областью и физическим миром (много аналогов синглтонов и абстрактных фабрик ты встречал в теории и практике финансов, документооборота или распознавании речи? то-то же.)
ООП - лажа, набор ебучих догматов построенных вокруг перфоманс хака 20-ти летней давности, а ты ждешь от набора догм внутренней непротиворечивости уровня зрелой целостной теории.
OOD, Буч, GOF, POOD, SOLID - это лажа все, братан.
Догматы, весьма открытые для интерпретации, "паттерны", "проектирование" -- ПИЗДЕЖ
Думал миллионы мух не могут ошибаться?
Не волнуйся - все просто - они не выбирают инструментарий... Еще раз - почти все программисты не выбирают инструментарий, его выбирают те кто программистов нанимает - занавес.
Ты думал Enterprise Patterns, единая платформа и вот это вот все продавались как технологическое решение? Хуй на.
Всем корпорациям единые стандарты и пул стандартизированных и сертифицированных дятлов для написания оперденей.
Фраза "правильное ООП" - маркер гандона, который считает, что те блоги которые он читает - самые охуенные, и возвышают его над окружающей чернью.
Посмотри на историю терок про OOD, GoF, TDD, BDD, SOLID - везде догматы, хуевые примитивные примеры и поливание говном несогласных. Цифр, исследований, предметной полемики с оппонентами - нет как таковых.
Сходи в футбик погоняй, не расстраивайся.
Подозрения начинают закрадываться с самого начала - ебанутых примеров "правильного дизайна" во всех книгах - постоянные обещания хороших аналогий и метафор с прикладной областью и физическим миром (много аналогов синглтонов и абстрактных фабрик ты встречал в теории и практике финансов, документооборота или распознавании речи? то-то же.)
ООП - лажа, набор ебучих догматов построенных вокруг перфоманс хака 20-ти летней давности, а ты ждешь от набора догм внутренней непротиворечивости уровня зрелой целостной теории.
OOD, Буч, GOF, POOD, SOLID - это лажа все, братан.
Догматы, весьма открытые для интерпретации, "паттерны", "проектирование" -- ПИЗДЕЖ
Думал миллионы мух не могут ошибаться?
Не волнуйся - все просто - они не выбирают инструментарий... Еще раз - почти все программисты не выбирают инструментарий, его выбирают те кто программистов нанимает - занавес.
Ты думал Enterprise Patterns, единая платформа и вот это вот все продавались как технологическое решение? Хуй на.
Всем корпорациям единые стандарты и пул стандартизированных и сертифицированных дятлов для написания оперденей.
Фраза "правильное ООП" - маркер гандона, который считает, что те блоги которые он читает - самые охуенные, и возвышают его над окружающей чернью.
Посмотри на историю терок про OOD, GoF, TDD, BDD, SOLID - везде догматы, хуевые примитивные примеры и поливание говном несогласных. Цифр, исследований, предметной полемики с оппонентами - нет как таковых.
Сходи в футбик погоняй, не расстраивайся.
> "паттерны", "проектирование" -- ПИЗДЕЖ
>студентик считает себя самым умным и высрал целое полотно, оправдывая свой говнокод
Ты вообще хоть раз в жизни что-то сложнее лаба2 писал?
топи по тезисам или сливайся, и определение термина 'сложнее' сформулируй четенько, когда будешь перезадавать вопрос
За щеку тебе топил.
По каким тезисам, ебанутый? Сначала напиши проект на хотя бы 5к+ строк кода, не следуя никаким паттернам, а просто хуяря говнокод, потом будем слушать твое кукареканье, когда придется его поддерживать.
Паттерны - это определенные правила, которые люди придумали, исходя из накопленного опыта, чтобы не срать под ноги себе и другим программистам в команде. Но тут высирается студент, у которого опыт нинужон, паттерны нинужны, а любая организация кода - это заговор жидокомпаний. Ты меня троллишь тупостью или реально дебил уровня /зк?
Та утрись петух, у меня 9 15-75 KLOC проектов.
"Люди придумали исходя из опыта" уязвимо к интерпретации (людей-то нет тут, а кто из нас правильнее книжку понимает - большой вопрос), ну и про фальсификационизм погугли, чмо малолетнее. Плюс когда в команде работаешь - человеческий фактор вылазит. Ну и best practices мягко говоря эволюционировали и сегментировались за 15 лет нихуево.
>проект на хотя бы 5к+ строк кода
Один из проектов: вспомогательный - 1.5к, основной - 6к.
Ебал все патерны, принципы, и вообще всё и всех.
Но вам так лучше не делать.
И да, я не этот дебил если что.
Это уже слишком толсто, попробуй что-нибудь кукарекнуть по делу.
Никто и не спорит, что написать можно хоть 20к строк без всяких паттернов. Проблемы вылезают, когда нужно этот говнокод поддерживать, рефакторить и добавлять что-то новое. А если программу нельзя улучшать и изменять, то я не знаю, нахуя такая программа нужна любому бизнесу.
Ой блядь, ты ж даже не понимаешь что значит "по тезисам"
У тебя не было никаких тезисов, кроме одного "паттернов много, значит они все говно, я самый умный, остальные долбоебы".
>поддерживать
Мне бы твои сложности.
>рефакторить
С этим вообще никаких проблем никогда, люблю всё сломать нахуй и переделать лучше
>добавлять что-то новое
Тем более.
Для дебилов пронумерую:
1) Обещание метафоричности OOP/OOD для моделирования предметных областей - наебалово.
2) Наличие нескольких интерпретаций "хорошего объектного дизайна" сильно различающихся, блядь да изобретатель термина OOP в ахуе от того что этим термином называют.
3) Нефальсифицируемость постулатов школ OO
4) Преобладание апелляции к авторитету в дебатах по вопросам OOP
5) Плюс ты, мышонок забываешь, что технической составляющей во многих паттернах не так много - они выполняют важную коммуникационную роль - стандартный набор подходов и терминов в команде , для чего ясен хуй необходимо их схожее понимание между членами команды, ну или диктатура архитектора.
Одиночка и дизайн - это вообще другая вселенная.
В 2000-2005 тут у джавистов был первый архитектурный коллапс - когда на рынке зарплата и тайтл стали сильно зависеть от количества паттернов названных на собеседовании - тут же появилась прослойка мальчиков, которые их задрочили в количестве трех десятков и лепили куда ни попадя.
^ Неосиляторы оправдываются.
Удваиваю сего оратора.
>Ой блядь, ты ж даже не понимаешь что значит "по тезисам"
Тут 90% анонимусам 16 лет не исполнилось еще.
И 90% из этих 90% клинические дебилы, постсовок же.
>Обещание метафоричности OOP/OOD для моделирования предметных областей - наебалово.
Суть ООП не в охуительной метафоричности, суть ООП в
>Наличие нескольких интерпретаций "хорошего объектного дизайна"
И что? Почему тебя это смущает? У каждого подхода есть плюсы и минусы и каждый формировался в иной среде и в разное время. Нужно сравнивать конкретно, а пока это звучит как "многа подходов эта плоха!!! дайте меньше выбора!!"
>постулат
>нефальсифицируемость
Значение знаешь?
>Преобладание апелляции к авторитету в дебатах по вопросам OOP
Людям свойственно допускать логические ошибки в любом дебате, каким образом это должно быть связано с OOP?
>они выполняют важную коммуникационную роль
Одна из целей, но обычно она сама собой подразумевается и никогда не является главной.
>Одиночка и дизайн - это вообще другая вселенная.
До определенного момента, но рано или поздно отсутствие дизайна и выливающийся из него говнокод дают о себе знать.
>прослойка мальчиков, которые их задрочили в количестве трех десятков и лепили куда ни попадя.
Каким образом неправильное/необдуманное применение паттернов говорит об их хуевости или ненужности?
Удивляюсь с убогости здешних ОО-хейтеров. Так упорно вайнить на то, в чем не разбираешься.
По сути, ООП - это три простых, логичных и необходимых принципа:
1. Инкапсуляция - когда ты вместо дрочева с полями структур грамотно выделяешь операции над каждым классом объектов, и используешь только их, гарантируя сохранение инвариантов класса и увеличивая реюз кода.
2. Полиморфизм - когда ты замечаешь, что для некоторых классов объектов можно выделить общие наборы операций и обрабатывать их единообразно. Тогда ты создаешь для них интерфейс и пишешь для этого интерфейса обобщенный код.
3. Наследование - когда ты выделяешь общие части кода для объектов, реализующих один интерфейс - чтобы не копипастить, или чтобы гарантировать соблюдение инвариантов, и делаешь базовый класс.
Если тупорылым функциональным кретинам это кажется ненужным и они больше любят копипасту лапши и вытаскивание наружу кишок класса без шансов что-то потом отрефакторить, то вряд ли имеет смысл что-то с ними обсуждать. Каждому адекватному человеку совершенно ясно, что описанное выше - единственный разумный способ разработки программ. Ну а сахарок в виде клож и алгебраиков совершенно спокойно добавляется поверх ООП.
По сути, ООП - это три простых, логичных и необходимых принципа:
1. Инкапсуляция - когда ты вместо дрочева с полями структур грамотно выделяешь операции над каждым классом объектов, и используешь только их, гарантируя сохранение инвариантов класса и увеличивая реюз кода.
2. Полиморфизм - когда ты замечаешь, что для некоторых классов объектов можно выделить общие наборы операций и обрабатывать их единообразно. Тогда ты создаешь для них интерфейс и пишешь для этого интерфейса обобщенный код.
3. Наследование - когда ты выделяешь общие части кода для объектов, реализующих один интерфейс - чтобы не копипастить, или чтобы гарантировать соблюдение инвариантов, и делаешь базовый класс.
Если тупорылым функциональным кретинам это кажется ненужным и они больше любят копипасту лапши и вытаскивание наружу кишок класса без шансов что-то потом отрефакторить, то вряд ли имеет смысл что-то с ними обсуждать. Каждому адекватному человеку совершенно ясно, что описанное выше - единственный разумный способ разработки программ. Ну а сахарок в виде клож и алгебраиков совершенно спокойно добавляется поверх ООП.
Твоя попытка ответа - неплохая иллюстрация к озвученным замечаниям. Дать каноническое определение ты - несмогла, а упомянутая цитата заканчивается признанием практической несостоятельности подхода. Выделение и перенос (метафора, сучка) объектов из предметной области - первый шаг OOA.
>> И что? Почему тебя это смущает?
Проблема идентичности дорогуша, cобственно выходит что никакого OOP нет - и если тебе нравится какая-то школа, то ты и выдвигай тезис, мол есть такие-то люди - я их мнение уважаю. А то не ясно за какой OOP базар (и так, все время, блядь - родовое проклятие).
Это, кстати, похоже на терминологический софизм - обогащай вокабуляр.
> Людям свойственно допускать логические ошибки в любом дебате, каким образом это должно быть связано с OOP?
Ну - в рамках дебатов - это показывает интеллектуальную несостоятельность одной из сторон - я ща примеры приведу:
>Значение знаешь?
Это уход от вопроса,и переход на личности.
>Одна из целей, но обычно она сама собой подразумевается и никогда не является главной
Это отрицание без контр-тезиса. (Бля, cерьезно?)
>До определенного момента, но рано или поздно отсутствие дизайна и выливающийся из него говнокод дают о себе знать.
Это - подмена тезиса:
Программы дизайнили до OOA/OOD/OOP, SOLID и будут дизайнить после.
> Каким образом неправильное/необдуманное применение паттернов говорит об их хуевости или ненужности
Эээ, как каким - через приведение примера практической несостоятельности.
Смысл в методологии которая обещая эффективность и прочие плюшки дает говно на выходе? Ну и с моей точки зрения это ожидаемо учитывая отсутствие единой четкой формулировки, открытость к интерпритации.
>Говнокодили до OOA/OOD/OOP, SOLID и будут говнокодить после.
Кто б сомневался.
>неправильное/необдуманное применение
>через приведение примера практической несостоятельности
Осталось пример привести.
>Смысл в методологии которая обещая эффективность и прочие плюшки дает говно на выходе?
Спроси у ФП-фанатиков. Они должны знать.
>интерпритации
иди домашку по русскому делай.
другой анон
[iИнтерпритировал[/i] вам за щеку.
Но как определить - действительно ли ты ООП-бро, или просто гад, зазубривший Три Святые Тайны ООП,и втирающийся к нам в доверие?
Ты - типичный софист, который собственных логических ошибок не замечает, но в остальных их детектит на каждом шагу, в большинстве случаев притягивая за уши.
Когда захочешь писать %(рефакторить код в)% классы по одному методу - значит ООПизация мозга практически завершена.
>Каждому адекватному человеку совершенно ясно, что описанное выше - единственный разумный способ разработки программ
>зазубривший Три Святые Тайны ООП
Зачем мне втираться в доверие к функциональным макакам?
Дорогуши, вы у меня не единственные: на сегодня - все - идите подмывайтесь
Ух ты, шизик.
У нас так - так мы и поняли, что приемлемый примитив - метод/функция, и мы на пути к ФП, хоть сами не понимали.
>Классы с 1 методом
cool story
суть ооп - уйти из плоскости логики машины в плоскость моделей реальных обьектов. все остальное - лишь реализации
Реальный абстрактный фактори бин прокси синглтонов.
>OOD, Буч, GOF, POOD, SOLID - это лажа все, братан.
>Догматы, весьма открытые для интерпретации, "паттерны", "проектирование" -- ПИЗДЕЖ
Бааа, еще один познал ИСТИНУ. Собственно, такие слова выдают того кто хочет волшебную таблетку от всего, хотя никто никогда и не задумывал ООП как оную. И если ты реально задрачивал всю хуйню что перечислил и вообще ничего не нашел полезного в этом - ну не знаю, проблемы в тебе наверное, т.к. все это просто способы удобней организовать свой говнокод. Т.е. даже простой пример с абстрактной фабрикой - на самом деле хорошая штука, только всякие долбоебы плюются и подрываются. Ну или тот же СОЛИД - да бля, не вижу особых проблем в том что бы хуярить классы с одним методов и конструктором, т.к. это легко может затянуть на 30-50 строчек кода, и когда этот класс логически составляют одну сущность/сервис так тупо удобнее поддерживать эту писанину. Ну, не исключаю что такие хейтерки работают в уёбищных галерах где погонщики сами особо не вдупляют что к чему и пихают все это в проекты потому что ТАК НАДО, более чем реальная картина.
> все это просто способы удобней организовать свой говнокод.
Лол, это 'просто' способы организовывать код, а то что он будет удобнее - не факт.
> пример с абстрактной фабрикой - на самом деле хорошая штука
Больной уебок
>а то что он будет удобнее - не факт.
Не факт что у тебя вообще получится что-то дальше чем "laba2", но тем не менее.
>Больной уебок
Лол. Тут как бы стоит заметить, что до фактори любой нормальный погромизд сам своими умозаключениями доходит даже не зная понятия проетирование, а если ты не можешь понять зачем нужна абстракция над ней - ты просто не дорос, в общем.
>Суть ООП не в охуительной метафоричности
На самом деле он отчасти тоже прав. В мире существует как бы джва ООП, друг с другом не связанных: одно - это как его втюхивают менеджерам и как его понимают шкальники всех сортов (абстракции как в реальном мире, автоматическое решение всех проблем разработки и поддержки, хуяк-хуяк объединили данные с методами и в продакшен), и другое - как с ним работают профессиональные разработчики.
Фундаментальная ошибка первой группы товарищей - это святая вера в то, что набор неких практик заменит им мозг или хотя бы сильно ограничит необходимость его напрягать. Неудивительно, что их постигает жестокое разочарование, как, видимо, и твоего оппонента. Для профессионалов же ООП - всего лишь набор подходов, облегчающий при умелом использовании написание хороших программ. Таким образом, отмежевавшись от первой группы товарищей, тот анон поступил правильно.
Он также прав в том, что в паттернах как таковых смысла довольно мало. Они важны скорее для анализа подхода к решению типовых задач, чем для прямого применения; тем не менее, в реальности мы видим миллионы поехавших, пытающихся натягивать эти несчастные паттерны на самые невероятные части тела своих программ. Я регулярно слышу, как словосочетание "применять паттерны" употребляют в смысле улучшения кода; то есть, по их мнению, код без паттернов - говно, а с паттернами он сразу становится лучше. Эти люди совершенно не поняли идею, и именно от них чаще всего приходится слышать, что она не работает.
И вот здесь вот он еще очень сильно прав:
>Программы дизайнили до OOA/OOD/OOP, SOLID и будут дизайнить после.
Главное и основное - это дизайн как таковой. Конкретная методология (ООП, ФП и т.д.) вторична. Даже в этом итт треде часто звучит: вот, если ты не придерживаешься ООП, то твоя программа - говно. Несмотря на то, что чаще всего это утверждение верно, необходимо понимать, что дело тут вовсе не в ООП.
мимо автор процитированного тобой поста
>то дело тут вовсе не в ООП
Как раз таки в нем. ООП и ФП это два способа размазывать говно по проекту, написанное в лучшем случае процедурно. ООП требует меньшего от программиста, а следовательно оно лучше. ФП требует сильно много дохуя, чтобы начать извлекать профиты самого ФП - следовательно стоит использовать исключительно под ответственность того кто пишет. Говнокод будет в обоих случаях, разнится только вероятность того что он обернется в итоге продуктом.
пацаны, катитесь к хуям с этой лажей про 'правильное использование', 'в умелых руках' и вот это вот все - я прекрасно помню как стада таких профи аплодировали Бучу, молча наблюдая как EJB доросло до второй версии (с 5 java файлами на сущность, сука) - это был отраслевой стандарт, и толпы сертифицированных блядей с умелыми руками его прославляли, и если бы опенсорц фрики не провернули бы все это движение на своем мощном фаллосе PORO движения, то щаз было бы 7 java файлов и 4 XML на сущность, а сертифицированные профи бляди с умелыми руками все так же аплодировали бы.
Курс движа OOP/OOD/OOA менялся и расщеплялся несколько раз, и по ходу движения обсирались все - Sun, Oracle, ASF.
Девочкам будете встегивать про то, что OOP - это что-то конкретное и сформулированное, и про то как абстрактные фабрики переливаются в ваших умелых руках, я вашего брата наблюдал 20 лет - и уже после 2005 стало окончательно понятно, что король голый, и проблем с OOP/OOD/OOA больше чем решений - собственно приблизительно тогда и начался расцвет языкового разнообразия, продолжающийся до сих пор.
Лучший псто треда, я так не ржал с самого начала. Видать, и впрямь наболело, лол.
Я джява-мир наблюдаю лишь опосредованно, и каждый день наблюдений лишь подтверждает высказанный мною вот здесь
>Джява - это язык, созданный с целью получения максимально сложных систем силами большого числа минимально компетентных сотрудников.
Так вот, на работе я ежедневно наблюдаю кодлу ведроидных котлинистов, которые время от времени советуются со мной по ряду вопросов. Всё то, от чего их милостиво предохраняла добрая джява, послано к хуям. Это, блять, праздник непослушания, а не программирование. Мне стоило серьезных усилий довести до понимания ихнего тимлида, что эти их ебучие инфиксные функции, применяемые без четкого понимания их ограничений - это не то что дорога в ад, это он самый и есть, здесь и сейчас. Причем дошло это до него только тогда, когда он наткнулся яйцами на остутствие приоритетов наколхоженных "операторов"; до этого у него ехало удобство через лаконичность, блять.
Под "правильным использованием" и "умелыми руками" я понимаю именно исконный смысл этих понятий, а не то, что с ними сотворила джява при попустительстве отцов-основателей.
Надо же, довели до бамплимита, сучечки.
Как боженька пояснил.
Внимательно прочитал тред, понял что лучше чем ООП ничего нет. Можете закрывать.
Внезапно из твоего поста понял следующее: в треде есть две категории людей - те, кто софт еще не писали но очень хотят (или так думают) и медленно но верно обмазываются зависимыми типами и прочими практиками. Те, кого этот цирк с конями уже заебал и они хуесосят все и вся, частично обоснованно. Третьей категории нет - она, собственно, натужно тянет свои галеры прямо здесь и сейчас ночью субботы исправляя очередной прокси фактори бин. Такие дела.
>прямо здесь и сейчас ночью субботы
Деда мороза несуществует, бтв.
Сейчас ночь и сейчас суббота. Что тебе не так?
Сейчас утро субботы, утиный типизатор ты мамкин.
На картинке не ту надпись шпонькнул, должно быть что-то кодика обросшего нехорошей зависимостью.
Каким хуем два часа ночи - это утро?
>Каким хуем два часа ночи - это утро?
Таким, что ночь субботы бывает после дня субботы, но никак не раньше.
После дня субботы бывает вечер субботы. Т.е. сейчас по твоему 2 часа утра, а три часа назад было 11 часов ночи? Я правильно понял твои монады?
У кого небыло бумажного календаря, тот не умеет из сегодня перемещаться в послезавтра =/
>Я правильно понял твои монады?
Полиморфировал в голос.
> сейчас ночью субботы
а вы не думали, может этот анон говорил про абстрактное сейчас?
Хорошо, вот вам на двоих задачка. Вася говорит Маше: чет хуево мне сегодня ночью спалось. О каком времени говорит Вася?
Отвечать надо так, как если бы вы хотели что бы вам обязательно перезвонили.
> если бы вы хотели что бы вам обязательно перезвонили.
Чот в голос
Вася - космонавт и в своем настоящем он говорит о будущем для Маши.
Когда до неё дойдет сообщение, то для обоих - будет прошлое, причем для Марии более удаленное относительно момента отправки сообщения Василия.
И да, Васе нужно принимать таблетки перед разгоном - они улушают сон и пищеварение.
Развели блять. Ночь субботы длится с 00:00 до 23:59 субботы.
Двачую этого адеквата - все спать, навеки вечные. Или только у субботы ночь длится 24 часа?
>ООП - лажа, набор ебучих догматов построенных вокруг перфоманс хака 20-ти летней давности, а ты ждешь от набора догм внутренней непротиворечивости уровня зрелой целостной теории.
И кое-кто из здесь присутствующих даже помнит, как это было.
>>Говнокодили до OOA/OOD/OOP, SOLID и будут говнокодить после.
>Кто б сомневался.
ВРЁТИ.
На обыкновенных пространствах имён делали, с очередью сообщений в единственном потоке. Погугли «C Interfaces and Implementations», хотя это прошлый век сейчас.
Что еще раз подтверждает тезис о том, что если ты говнокодер сам по себе то никакая парадигма не сделает твой код менее говнистым от одного факта ее применения. Другое дело, что ООП зачастую это последний шанс выпрямить руки юному дарованию.
Перекот.
Перекот.
Перекот.
Блестяще.
В SICPе эту концепцию называли "чёрный ящик" и применяли в рамках ЛИСП-а, который, как вы все знаете, функциональный язык.
Я ньюфаг, но как это понимаю-то, братишки: все эти парадигмы-хуигмы это просто концепция, методология, если хотите. Возможность использования конкретной методологии выражается в инструментарии языка. Очень грубо говоря: если язык поддерживает возможность писать функции, это УЖЕ значит, что можно кодить в "функциональном" стиле. Вопрос в количестве инструментов.
А ещё я не понимаю, почему ООП это такое волшебство? Есть же концепция модульности, например, которая в ООП называется ИНКАПСУЛЯЦИЯ. Винегрет какой-то, бля, для опущей.
Я не надеюсь что увижу тут дельный ответ, совет, рекомендации, скорее всего всё скатится в такой же срач как и повсюду.