- 1
https://www.youtube.com/watch?v=lfdAwl3-X_c
Куча говна / Говнокод #25786
0
Запостил: 
OlegUP,
(Updated )
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
- "PHP" (6228)
- Куча говна (4363)
- Кресты (2940)
- ЙажаСценарий (2225)
- Си диез (2081)
- Jawa (1688)
- Няшная (1343)
- Змея (894)
- Школоло (781)
- mysql_real_escape_string (579)
- Бухгалтерия (547)
- ДействиеСценарий (419)
- Beri bash i ebash (300)
- Яuбy (294)
- Субъективный Си (290)
- =()= (267)
- Школоло (200)
- Сборный (158)
- Метатабличный (91)
- Хламидомонада (75)
- Ябло (Свежее) (49)
- Goвно (37)
- Koko (17)
- HTML (1)
Ты не охуел ли случайно?
Мы его уже взяли.
В качестве свидетеля, последуйте за мной.
То в "ООП" надо писать:
Именно поэтому я за "процедурное программирование".
ООП далеко не всегда удобно и вовсе не серебряная пуля, однако для некоторых задач оно не так уж и плохо.
А вот что плохо, так это то, что 99% сторонников ООП на самом деле нихуя не понимают ООП.
Они думают что если вместо
get_petux
написать
new PetuxObtainer()->getPetux();
то их код сразу станет ООПным
> значит их нельзя использовать.
Как из первого утверждения следует второе? Почему я, например, не могу прочитать рид-олни свойство apple.color?
но на самом деле в нормальных языках типа котлина и C# они сами генерятся
только жабоёбы хуячат вручную
ОНи вообще не нужны, так как нарушают инкапсуляцию, даже не ее, а сокрытие.
Фанатики не нужны. Идеально-инкапсулированные классы, полностью изолированные от внешней среды, пусть пишут ООП-цари.
джава подталкивает тебя нарушать инкапсуляцию как можно чаще
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/processor-breakpoints---ba-breakpoints-
Кстати, а каким дебагером ты пользовался в 83-м?
нативный дебагер можно натравить на обращение к памяти, но есть одно но
хардварных точек останова немного
остальные реализуются патчнигом кода и вставкой туды 0xCC
А в видео говорят о том, что объект - это не просто набор данных с функциями, а сущность обладающая свойствами.
В ПП нету наследования, хоть и есть композиция.
В ПП нету полиморфизма.
В ПП ты данные определяешь и держишь внутри функций, хотя и есть структуры.
В ООП ты данные определяешь в отдельном месте и не мешаешь с алгоритмом. Но при этом у тебя есть такая вещь как класс, которая именно для этого в т.ч. и придумана.
Именно поэтому я за ООП.
>В ПП нету полиморфизма.
на самом деле есть.
В си часто можно увидеть указатель на структуру Animal, который потом кастят в указатель на структуру Tiger.
>В ООП ты данные определяешь в отдельном месте и не мешаешь с алгоритмом.
Как раз наоборот.
В ПП у тебя отдельно структуры (тупые, если конечно там нет указателей на функции) а отдельно алгоритмы.
В ООП же алгоритм "чирикнуть" находится внутри класса "Петух", и если ты хочешь чтобы чирикнул кто-то другой, то у тебя пробелмы
В си есть указатель на void, и его можно скастить в любой функции к любому типу.
Но в C++ есть шаблоны, которые решают эту залачу в CT, и при этом выглядят более наглядно.
Зато в си нету перегрузки функций, а это часть полиморфизма, а значит и нету виртуального наследования.
Ну и конструкторы с деструкторами вызывающие сначала для объекта malloc не забываем писать сами.
И потом у тебя будет 200500 классов в наследовании и все друг друга переписывают:) Особенно смешно, когда у тебя нету множественного наследования.
>В си есть указатель на void, и его можно скастить в любой функции к любому типу.
Да, но речь не об этом.
>Зато в си нету перегрузки функций, а это часть полиморфизма, а значит и нету виртуального наследования.
Ну храни в структуре указатель на функцию:)
>Ну и конструкторы с деструкторами
Это да, хотя это и не главное в ООП.
Я не против ООП, просто оно не всегда нужно
То есть здесь ты уже не пишешь одну функцию на несколько случаев, а целый класс функций на несколько случаев, и каждый частный случай можешь переопределить.
>можешь разные сущности плодить
вот это правда
в пложении охулиона сущностей у ООП равных нет
Но я думаю, что в ООП как раз таки можно и без этого обойтись.
Наличие в нем классов еще не говорит о том, что они плодятся без всякой на то нужды.
Полностью принцип звучит же так: "Не плоди сущности без острой нужды"
Ну и вспомним философию UNIX:
Вместо одной программы которая делает все сразу лучше много программ, мелких, которые делают свое дело хорошо.
Не очень понятно зачем вводить какое-то ограничение на количество методов. Объект должен уметь делать то, что для него было бы логично уметь.
В ответ на вопросы для примера предлагает иметь различные классы для:
- файла возвращающего целиком свое содержимое;
- файла возвращающего массив строк;
- файла с произвольным доступом;
- файла с известной кодировкой;
- файла без кодировки.
Мне не очень понятно, зачем файлу нужно уметь сплитить строки, и почему нельзя указать в конструкторе, что кодировка не известна. А все, что осталось не займет много кода и в одном классе.
Иметь несколько маленьких классов конечно лучше, чем один большой и сложный, но если с этим перестараться получится пример, что я привел выше.
Про иммутабельность согласен, но вот про отсутствие геттеров не очень, если я не могу обратиться к уже открытому файлу за путем к нему, то мне придется хранить его путь где-то снаружи, и где тогда это ваше хваленое выделение данных в отдельное место?
Классов для сортировок там нет случайно?
а ломбок это хуита чтобы генерить бойлерпейт типа хешкод иквалс геттеры сеттеры
кроме разве что кейсов когда там внятные стратегии
да и там омжно лямбду
Ни подмыться, ни попить.
А мне мама не велела.
Неподмытую любить
А я то думал - свежее мясо на гк.