- 1
https://www.youtube.com/watch?v=lfdAwl3-X_c-
Куча / Говнокод #25786
−1
Запостил:
OlegUP,
30 Августа 2019
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Мы его уже взяли.
В качестве свидетеля, последуйте за мной.
То в "ООП" надо писать:
Именно поэтому я за "процедурное программирование".
> значит их нельзя использовать.
Как из первого утверждения следует второе? Почему я, например, не могу прочитать рид-олни свойство apple.color?
ОНи вообще не нужны, так как нарушают инкапсуляцию, даже не ее, а сокрытие.
Фанатики не нужны. Идеально-инкапсулированные классы, полностью изолированные от внешней среды, пусть пишут ООП-цари.
Кстати, а каким дебагером ты пользовался в 83-м?
А в видео говорят о том, что объект - это не просто набор данных с функциями, а сущность обладающая свойствами.
В ПП нету наследования, хоть и есть композиция.
В ПП нету полиморфизма.
В ПП ты данные определяешь и держишь внутри функций, хотя и есть структуры.
В ООП ты данные определяешь в отдельном месте и не мешаешь с алгоритмом. Но при этом у тебя есть такая вещь как класс, которая именно для этого в т.ч. и придумана.
Именно поэтому я за ООП.
В си есть указатель на void, и его можно скастить в любой функции к любому типу.
Но в C++ есть шаблоны, которые решают эту залачу в CT, и при этом выглядят более наглядно.
Зато в си нету перегрузки функций, а это часть полиморфизма, а значит и нету виртуального наследования.
Ну и конструкторы с деструкторами вызывающие сначала для объекта malloc не забываем писать сами.
То есть здесь ты уже не пишешь одну функцию на несколько случаев, а целый класс функций на несколько случаев, и каждый частный случай можешь переопределить.
Но я думаю, что в ООП как раз таки можно и без этого обойтись.
Наличие в нем классов еще не говорит о том, что они плодятся без всякой на то нужды.
Полностью принцип звучит же так: "Не плоди сущности без острой нужды"
Ну и вспомним философию UNIX:
Вместо одной программы которая делает все сразу лучше много программ, мелких, которые делают свое дело хорошо.
Не очень понятно зачем вводить какое-то ограничение на количество методов. Объект должен уметь делать то, что для него было бы логично уметь.
В ответ на вопросы для примера предлагает иметь различные классы для:
- файла возвращающего целиком свое содержимое;
- файла возвращающего массив строк;
- файла с произвольным доступом;
- файла с известной кодировкой;
- файла без кодировки.
Мне не очень понятно, зачем файлу нужно уметь сплитить строки, и почему нельзя указать в конструкторе, что кодировка не известна. А все, что осталось не займет много кода и в одном классе.
Иметь несколько маленьких классов конечно лучше, чем один большой и сложный, но если с этим перестараться получится пример, что я привел выше.
Про иммутабельность согласен, но вот про отсутствие геттеров не очень, если я не могу обратиться к уже открытому файлу за путем к нему, то мне придется хранить его путь где-то снаружи, и где тогда это ваше хваленое выделение данных в отдельное место?
Классов для сортировок там нет случайно?
А я то думал - свежее мясо на гк.