Как кто тут относится к ООП?

[alsoijw]

Как кто тут относится к ООП?

[asy]

Как кто тут относится к ООП?

Я пробовал что-то писать на Turbo Pascal в, примерно, 1993 году. Парадигма интересная вроде показалась... То есть, на самом Turbo Pascal я много писал достаточно, но без ООП части. ООП паскалевский смотрел чуть-чуть.

[Юра Римский]

Как кто тут относится к ООП?

Много раз начинал, но мне не удаётся применить на практике. Это не значит, что ООП - плохо, возможно я сути не понимаю. Теоретически ООП предполагал, что программисты смогут в программах оперировать сущностями реального мира, но на практике у меня не получилось этого добиться. Я не вижу смысла в методах объекта. В реальном мире у объектов нет никаких методов. В реальном мире действие совершается над объектом, а не объектом.

Как сказать, что заяц и кролик на пару съели морковку? Заяц, кролик и морковка - объекты реального мира.

Морковка->съесть(заяц, кролик)? Морковка должна знать о том, кто и в каком количестве её может теоретически съесть.
А морковка->съесть(волк) должно вызвать ошибку.

Не слишком ли много кладётся на морковку?

Вводить новую сущность пара? Пара(заяц, кролик)->съесть(морковка). Не, количество сущностей начнёт расти не по дням, а по часам.

Притом, что действие (не метод) съесть вполне может знать, кто и чего может собственно съесть :) съесть([заяц, кролик], морковка) как-то проще для понимания :)

[Александр Ерещенко]

Как кто тут относится к ООП?

Много раз начинал, но мне не удаётся применить на практике. Это не значит, что ООП - плохо, возможно я сути не понимаю. Теоретически ООП предполагал, что программисты смогут в программах оперировать сущностями реального мира, но на практике у меня не получилось этого добиться. Я не вижу смысла в методах объекта. В реальном мире у объектов нет никаких методов. В реальном мире действие совершается над объектом, а не объектом.

Как сказать, что заяц и кролик на пару съели морковку? Заяц, кролик и морковка - объекты реального мира.

Морковка->съесть(заяц, кролик)? Морковка должна знать о том, кто и в каком количестве её может теоретически съесть.
А морковка->съесть(волк) должно вызвать ошибку.

Не слишком ли много кладётся на морковку?

Вводить новую сущность пара? Пара(заяц, кролик)->съесть(морковка). Не, количество сущностей начнёт расти не по дням, а по часам.

Притом, что действие (не метод) съесть вполне может знать, кто и чего может собственно съесть :) съесть([заяц, кролик], морковка) как-то проще для понимания :)

Как-то Вы интересно восприняли сущности. :)
А если так:
Объект: Животное.
Метод объекта: Съесть (Еда)   (еда - это параметр)
Заяц, Кролик - объекты, наследованные от Животное.
Применение метода: Заяц.Съесть(Морковка)

[Юра Римский]

Применение метода: Заяц.Съесть(Морковка)

Вопрос был про одновременно, когда и заяц, и кролик едят одновременно одну и ту же морковку :) Я про параллельные вычисления и многозадачность говорю. Объекты начинают знать слишком много.

Простая задача скопировать таблицу из БД в файл. Есть объект Таблица, есть объект Файл. Кто этим занимается?

Должна ли таблица уметь записывать себя в файл? Нет, не должна. Файлов много: xml, json, html, text, cvs, serialize-array, ещё всё тоже самое запакованное в zip, rar, 7z... с паролем. А там ещё некоторые поля нужно сконвертировать, например, unixtime в нормальный datetime. И чего получается?

Файл->записать(таблица())
Таблица->сохранить(файл)
Всё не то, задача куда сложнее.


Нужно создавать некий записыватель таблицы в файл.

ЗаписывательТаблицыВФайл->записывай(таблица, файл) - это уже не отражение реального мира и, если файл ещё можно в разных форматах представить, то таблица с некоторыми сконвертированными полями - это уже выходит за рамки объектов.

Я не спорю, я как раз пытаюсь разобраться, может, есть способ лаконично решить эти задачи в ООП и я просто о нём не знаю.

[flint1975]

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

[flint1975]

Собственно - есть две задачи:
1. Составить корректную модель мира
2. Описать в терминах ООП некую (необязательно корректную) модель.

1 задача - проектирование
2 задача кодинг

[Юра Римский]

Собственно - есть две задачи:
1. Составить корректную модель мира
2. Описать в терминах ООП некую (необязательно корректную) модель.

Собственно, именно это и не удаётся.

Я концептуально не понимаю парадигму, у меня не получается создать корректную модель мира, сколько я не пытался.

Как бы объяснить максимально просто?

Нужно достать из шкафа брюки и надеть их на себя.

Код: [Выделить]

шкаф->открыть()
брюки = шкаф->содержимое(брюки)
я->одеть(брюки)

Это уровень учебников. Полный восторг, суперфантастика.

Но вот усложним задачу. Нужно найти фиолетовые брюки с пуговицами, а не молнией.

Код: [Выделить]

шкаф->открыть()
брюки = шкаф->содержимое(брюки) //? хрена два

кто отвечает за фиолетовый цвет и пуговицы?

В той парадигме, которую я использую появляется цикл:

Код: [Выделить]

каждый предмет из шкаф->содержимое():
    если брюки и фиолетовые и не молния и пуговицы:
        брюки = предмет
        выйти из цикла

Чем это концептуально отличается от процедурного программирования?

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

Как скрыть детали реализации?

[Skull]

ООП – это ещё и декомпозиция как свойств, так и действий (методов). Поэтому вводим объект поиска:
ищем = поиск_одежды()
ищем.тип = одежда::брюки
ищем.цвет = цвет::фиолетовый
ищем.исключить( фурнитура,  одежда::фурнитура::молния )
...
брюки = шкаф.получить( ищем )

Фильтром может быть или регэксп или итератор.

Да, ООП многословен. ;)

[tema]

Если честно, странная тема. Как к нему можно относится? А как можно относиться к столу или к табуретке?
ООП есть и всё. Хочешь писать на Delphi-Lazarus-Builder, значит используешь табуретку, то есть ООП. Хочешь писать драйверы или кодить контроллеры на ассемблере, значит ООП не используешь. Иногда, в зависимости от задач и/или среды программирования, выбора нет и использовать ООП надо по определению. Как тогда к нему относиться? Это же инструмент.
Что именно имеется ввиду под "относится"? Понимание концепции (именно это обсуждается почему-то)? Или принятие-отторжение такого способа программирования?
Как по мне, то я считаю, что программисту без разницы в какой концепции программировать. Обычно программисту есть разница какой язык. Есть у программиста каждого любимые языки и не любимые. Вот я очень люблю язык паскаль. Когда пишу программы на нём, мне это очень нравится. Могу подолгу отлаживать и доделывать, шлифовать каждую часть программы. Не люблю ужасно писать на прологе (иногда приходилось в учебных целях друзьям-преподавателям из Бауманского писать). Без эмоций к остальным языкам почти. Когда пишу на асемблере, си, яве, пхп - без эмоций к языку просто стараюсь, чтобы задача была выполнена и чтобы было оптимально.

[alsoijw]

tema, да вот посмотрел как в C# это сделали... Есть класс А. И нужно с экземпляр - а. И с ним нужно что-то сделать. Имхо логично писать так: а.действие().  Но авторы C# решили иначе: A.действие(а); Нечто подобное наблюдается и в питоне - вместо того чтобы написать a.len нужно писать len(a). Вроде и ООП, а в то же время и нет.

кто отвечает за фиолетовый цвет и пуговицы?

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

[bliser]

Как кто тут относится к ООП?

Отношусь как к инструменту. Он (ООП) в одних случаях очень удобен в других - мешает. Лично мне на большом (для меня) проекте удобнее пользоваться  ООП, т.к. при этом код нагляднее и проще.

[Юра Римский]

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

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

Вариант "ищем = поиск_одежды()" мне больше понравился. Шкаф знает только то, что в него может влезть некий искатель и он должен предоставить ему всё своё содержимое. Так, конечно, проще. Но всё-таки ввод на каждый чих нового объекта сильно напрягает. Мне всё равно как-то проще процедурой:
найти(шкаф, фильтр)

[Skull]

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

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

Вариант "ищем = поиск_одежды()" мне больше понравился. Шкаф знает только то, что в него может влезть некий искатель и он должен предоставить ему всё своё содержимое. Так, конечно, проще. Но всё-таки ввод на каждый чих нового объекта сильно напрягает. Мне всё равно как-то проще процедурой:
найти(шкаф, фильтр)

Описывайте одной строкой все атрибуты и ищите по ним регэкспом.

[alsoijw]

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

Не обязательно. Если нужно в шкафу с одеждой хранить ещё что-то, то тогда пишем типа того
я.одеть(шкаф.найти((вещь) => { вернуть вещь.тип == брюки и вещь.цвет == фиолетовый и ...})
Теперь одежду можно хранить хоть в холодильнике.