Полиморфизм? - Можно кормить Зайку мясом?

А это не шутка. Реальная история из жизни. Но смешно, да. Я ведь даже не понял в чем прикол, совершенно искренне ответил.

Ооп придумали чтобы упрощать жизнь, а не мозг насиловать.

O’Rly? А мне казалось как раз чтобы мозг насиловать на собеседованиях. Расскажите что такое полиморфизм. Объясните зачем нужны getter/setter. Какие паттерны вы знаете? Тьфу.

Ну так про сильных программистов, я тоже в реальности попал. Пришлось таскать старые компы в подвал.

Можно кормить Зайку мясом?

возможно если котлету завернуть в капусту, то можно

А мне казалось как раз чтобы мозг насиловать на собеседованиях.

Так а кто говорил, что программирование это легко? Или ты думал, что пацаны пишут нацчные труды, защищают дипломы, а тут ты такой «хоба», и в программисты?

ТСу. Что, не получается троллить? Волну пустить не можешь? Наводящими вопросами разогнать тред клёпы не хватает?

Смешно. Ты что, правда думаешь что все эти паттерны и прочее ООП придумали не гуманитарии для зарабатывания денег, а программисты?

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

Многие языки пишут что у нас ооп нет хотя по факту есть (тот же golang).

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

А где «гёрла»?

Язык программирования – это прежде всего средство выражения смыслов

Язык программирования это инструмент написания рабочих программ. А смыслы выражать это к теоретикам

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

А в чем проблема то с летающими стульями? Берешь стул и швыряешь. Он летит? Летит. Аналогично отвозишь на МКС любимый бабушкин буфет.он там летает? Летает. С точки зрения физики никаких противоречий нет

Смотря какой ЯП.

Разумеется. Но, я про большинство ЯП с ООП. В среднем, множественное наследование напрямую скорее запрещено, чем разрешено.

Так в жизни оно связано только с интерфейсами.

Да? Маша унаследовала черты от папы-Пети и мамы-Лены. Где тут интерфейсы?

Смешно. Ты что, правда думаешь что все эти паттерны и прочее ООП придумали не гуманитарии для зарабатывания денег, а программисты?

Программисты. См. ниже,

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

Т.е. программисты

1. Заколебались разгребать спагетти-код с goto в том чиле.
2. начали массово писать UI - и им естественным образом в голову пришла концепция ООП

А в чем проблема то с летающими стульями? Берешь стул и швыряешь. Он летит? Летит. Аналогично отвозишь на МКС любимый бабушкин буфет.он там летает? Летает.

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

И тут пойдут абстракции вида

Джорджи, мы здесь все летаем

Уф. Мальчику хочется дать Розенталем. А gui’щики - не программисты.

Главное в ооп это то что методы прывязаны к обектам,

ООП на обобщённых функциях врывается в обсуждение.

Абстракция это чтоб начальник написал:

$tablica(chutchutvlevo);

И думал - что он программист.

Так?

Герла уже сложнее, надо пилить интерфейс Размножаемый.

Наследование

Позволяет расширить функционал без копипасты

И ломать к херам всю иерархию одним небольшим изменением в базовом классе.

Полиморфизм

Это крестовые шаблоны.

Один интерфейс — несколько реализаций (open-closed principle). Есть, скажем, интерфейс «сруль» (метод срать()), и всё, что его реализует, может быть использовано как сруль, даже небо, даже зайка.

Инкапсуляция - Зайку резать нельзя

Тут скорее для того чтобы зайка погадил нужно вызвать метод срать()

Зайка обладает идентичностью и имеет своё внутреннее изменяемое состояние, которое не должно изменяться мимо его интерфейса — набора собственных и унаследованных методов (на которых лежит ответственность за его, состояния, целостность и согласованность).

Заодно это дело плодит уйму уникальных интерфейсов (по одному на каждого сраного зайку), и поэтому условные жабабыдлокодеры не способны вообще ничего делать без IDE — потому что всё это выучить никакой памяти и никакого терпения не хватит.

Абстракция

Это дрисня

Мы вам перезвоним.

Короче, единственная стоящая вещь во всём ООП — это полиморфизм. И та, если разобраться, прекрасно работает безо всякого ООП %)

Джорджи, мы здесь все летаем

В общем, где ООП, там и клоуны. ЧТД.

«существуют кровожадные зайцы, которые любят полакомиться плотью. Правда скорее не любят, а вынуждены. Речь идет об арктических зайцах или арктический беляк, не путайте с нашими зайцами-беляками. Раньше считалось, что это один и тот же вид, но позже арктических выделили в отдельный вид.»

Начнём с того что эти принципы далеко не только про ооп. Это в целом про то, как правильно разделять код на композабельные блоки, независимо от парадигмы.

Язык программирования – это прежде всего средство выражения смыслов

Язык программирования это инструмент написания рабочих программ. А смыслы выражать это к теоретикам

Удовлетворить железяку – уровень мидла. Уровень сеньора – удовлетворить мидла который будет читать твой код.

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

Независимо от парадигмы не выйдет. Потому что в парадигме «Дождался команду - выполнил - вывел в stdout - goto 0» ООП не с руки.

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

Расскажите что такое полиморфизм

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

Объясните зачем нужны getter/setter

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

Какие паттерны вы знаете?

Дофига, все сразу не вспомнить. Синглтон, абстрактная фабрика, фабричный метод, итератор, билдер, фасад, адаптер, шаблонный метод... Но обычно я не вспоминаю как метод называется, а просто беру и использую его. Как ты не вспоминаешь как рукой жопу почесать, какие мышцы для этого надо напрягать. Когда какая-то экзотика происходит что надо задуматься а какой паттерн тут бахнуть ИМХО уже какая-то дичь творится, раз сразу не понятно что делать. Принцип KISS нарушен полностью. Да можно сказать что опытный проектировщик проектирует с умом по-хитрому, но это глупость. Потому как ему всё понятно не значит что это будет понятно тем кто будет работать с этим говнокодом после него. Потому блин не ленитесь писать к своему говнокоду сопроводительную документацию и основные идеи о том, как вы это проектировали. Это даже вам самим потом поможет. А то будет как у автора fb2 формата. Вроде и работает, а спроектировано хреново (всё в каше строго говоря и даже в fb3 каша и проблемы не исправлены полностью, вот нафига давать сслыки переопределять? Чтоб попа горела ярче у разрабов? И так далее. А главное конечно мы не пишем, как жанры реально называются и получается что у нас есть adv_geo а что это и куда? Реклама геолокации? Приключения глобуса? Геополитические приключения?). Обратное тоже верно - если ты думаешь что ты соблюдаешь KISS и пишешь всё просто, то ты тоже ошибаешься, потому что пишешь просто для себя, а тебе надо просто для других. Потому не ленись и высри из себя документацию, не делай как авторы некоторых хороших библиотек на гитхабе, где документации нет вообще и только когда ты доходишь до того что начинаешь писать свой код то у тебя выстраивается +- тоже самое что и у них и приходит понимание как предполагалось использовать эту библиотеку без документации вообще. Простите подгорело.

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

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

Наследование - всё ясно. Из одного Зайки - можно сделать второго.

Зайка - финальная реализация, наследуются от какой-то категории, типа животное. Хотя жоопэшники уже стараются не наследоваться, на практике оказалось, что основной принцип оопэ - мёртвый.

Гораздо большего размера с разным цветом глаз - Свойства

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

Инкапсуляция - Зайку резать нельзя. Можно кормить - вход. Убирать дерьмо - выход. Зайка может прыгать - Методы.

Можно везде сделать a.getX(); a.setX(1) нельзя делать a.x. Не ищи в этом смысл. А так, в целом, удачной отладки инкапсулированного в какую-нибудь жопу зайца с инкапсулированным, в этого зайца, всем его тухлым ливером. Ой, вей, заяц серет больше чем есть, в чем же причина.

Полиморфизм?

Неее. Все животные жрут. У тебя есть пачка животных и пачка еды. Можешь ли ты кормить этих животных этой едой? Жоопэ не знает. Оно решает это в рантайме, а потом его адепты открывают пасть за типизацию.

Java эффективное программирование

/0
кек

Любая идея доведенная до абсолюта превращается в абсурд. Концепция ООП не заслуживает излишнего теоретизирования. ООП - это просто способ «эргономично» связать текст кода с некоей идеей прикладной логики.

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

Очередной клован порвался. Может ты еще без ассертов код пишешь?

Оно решает это в рантайме, а потом его адепты открывают пасть за типизацию.

Шел 2024-й, на ЛОРе ретарды всё так же не могли понять, что такое типизация…

Один интерфейс — несколько реализаций (open-closed principle). Есть, скажем, интерфейс «сруль» (метод срать()), и всё, что его реализует, может быть использовано как сруль, даже небо, даже зайка.

class Shape {}

class Circle extends Shape {}

class Line extends Shape {}

// ...

class Canvas {
  void draw(Circle shape) 
  { 
    /* ... */ 
  }

  void draw(Line shape) 
  { 
    /* ... */ 
  }

  void draw(Rectangle shape) 
  { 
    /* ... */ 
  }
}

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

Можно везде сделать a.getX(); a.setX(1) нельзя делать a.x. Не ищи в этом смысл

Смысл тут такой что setX легко найти текстовым поиском, в отличие от просто x в котором будет куча ненужного включая локальные переменные функций. А так же такой что в setX может быть спрятана доп. логика. Впрочем, некоторые языки (js) позволяют прятать логику и в a.x так что второй аргумент для них неактуален. Но первый остаётся.

Ты чет даже до таких простых вещей дойти не можешь:

class MyURL {
  constructor(url) {
    this.url = url
  }
  get hostname() {
    return this.url.split('/')[2]
  }
  // ...
}

let u = new MyURL('https://youtu.be/XXXX')
console.log(u.hostname) // 'youtu.be'
u.url = location.href
console.log(u.hostname) // 'www.linux.org.ru'

геттеры и сеттеры - это просто удобно

Это и есть полиморфизмус

Хреновенький, правда — чтобы добавить новую фигуру и реализацию draw() для неё, придётся править класс Canvas (и с некоторой вероятностью сломать уже работающие реализации). Open-closed principle (O in SOLID) не рекомендует так делать.

Лучше, если бы метод draw() был у самих фигур — тогда при добавлении новой фигуры старый код гарантированно не ломается, потому что его не нужно изменять.

void draw(Line shape)

void draw(Square shape)

Кстати, можно заметить, что ООП тут как бы и ни при чём. По сути, это обычные полиморфные функции.

Можно сказать что в питоне нет полиморфизма, нет инкапсуляции, есть только наследование в привычном понимании, а абстракция - лишь в общем понимании

Всё в петоне есть, просто не всем удобно пользоваться. Даже полноценную инкапсуляцию можно наворотить, например, на замыканиях. Выглядеть, правда, будет как говно, но тем не менее.

Ооп это просто концепт разделения данных и поведения. И всё. Все эти вумные слова придумали, чтоб преподавать это в школах и универах. Не надо в них искать мегасмысл. Идея/концепт первична. Что такое зайка и как его кормить имеет кучу реализаций исходя из первичной постановки. Разработка сродни строительсту, тебя же не удивит, что сарай нужно строить одним методом, дом в деревне другим, небоскрёб третим, а завод десятым? Тут тоже самое.

Объясните зачем нужны getter/setter.

Как раз наличие этого обычно говорит об отсутствии поведения и является нарушениеи первичной концепции ооп - разделения данных и поведения.

Лучше, если бы метод draw() был у самих фигур

А с каких пор фигуры сами себя рисовать умеют?

что ООП тут как бы и ни при чём. По сути, это обычные полиморфные функции.

У круга есть свойства типа радиуса, у квадрата координаты 4-х точек, линии - двух. Не получится тут без ООП

Даже полноценную инкапсуляцию можно наворотить, например, на замыканиях

И это будут просто замыкания

Да сахарок это чтобы вместо url.getHostname() писать url.hostname. Ничего криминального нет

У круга есть свойства типа радиуса, у квадрата координаты 4-х точек, линии - двух. Не получится тут без ООП

В любом словаре могут быть ключи center, radius и points. Добавим ключ type и switch по нему — вот тебе и простейшая полиморфная функция на словарях, без всякого ООП.

с каких пор фигуры сами себя рисовать умеют?

С тех самых пор, как ты научишь их это делать %)

это будут просто замыкания

Данные будут спрятаны за интерфейсом? Будут. Получить к ним доступ мимо интерфейса будет нельзя? Нельзя. Вуаля — инкапсуляция.

Нет. У круга всякие методы для расчета координат точек а у Canvas’а есть тоже свойства: ширина и высота, начальная закраска, уровень и способ сглаживания, а так же все «нарисованные» фигуры в стеке лежат, причем перекрывающиеся не рисуются…

Если же ты будешь словарик первым аргументом передавать, то лишь изобретешь жООП: разницы нет писать send_request(client, url, ...) или client.send_request(url, ...), но второй способ решает проблему с засиранием глобальной области видимости иначе как в похапе будет some_long_function_name_with_prefix($res, $other_args)

Нет, если url соотаетствует концепции ооп, но и то и другое концептуально не правильно. Должно быть аля url.openConnect либо new Connect(url) либо ... поэтому и говорю говорение про get/set обычно не имеет к ооп никакого отношения.

С тех самых пор, как ты научишь их это делать %)

Когда машина «едет», то она может двигать и без человека, если зажать педаль газа и выпругнуть из нее, а круг сам себя не нарисует. Я если бы в коде увидел круги которые сами себя рисуют, то посчитал бы что это код шизофренника, с расчетом длины окружности и тд - еще нормально, потому как если бы круг обладал сознанием, то он бы мог сообщить о своих размерах

url.openConnect

Это как с саморисующимися кругами - такого в коде быть не должно ибо бред

Нет

Похапешника ответ %)

разницы нет писать send_request(client, url, …) или client.send_request(url, …)

Ты начинаешь понемать? %)

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

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