Целесообразность приминения ООП в некоторых задачах

> И вообще есть ли выгода использования ООП в тех задачах, где и без него получается простой и логичный код?

Какой язык? Если Java, то есть. Структурный код на Java не может быть простым и логичным. Сам сейчас с таким работаю. :(

Если C/C++/D/что-то-ещё-не-навязывающее-свой-стиль, то ИМХО нет.

ООП в наипервейшую очередь это полиморфизм. В случае с файлами этот полиморфизм есть (иконка, действие при дабл-клике, удаление, etc), поэтому модель подходит.

Для примера сделай delete для любого элемента. По-любому тебе придётся отличать каталог от регулярного файла.

>Для примера сделай delete для любого элемента. По-любому тебе придётся отличать каталог от регулярного файла.

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

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

>Какой язык?

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

можно немного перефразировать вопрос: вот мы имеем уже написанный код без ООП который выполняет определённую задачу, и является достаточно простым и в меру логичным, будет ли выгода если мы заменим его на код с ООП'ом?

без ООП

void deleteItem(item_t item) {
    if (item->type != TYPE_DIRECTORY) {
        unlink(item->name);
    } else {
        for (subitem : item->children) {
            deleteItem(subitem);
        }
        rmdir(item->name);
    }
}

с ООП

void RegularFile.delete() {
    unlink(name);
}

void Directory.delete() {
    for (subitem : children) {
        subitem->delete();
    }
    rmdir(name);
}

во втором случае динамическая диспатчеризация заменяет if. Т.е. отличие выполняется автоматически.

не будет.

Вот заладили: ООП, ООП, ООП. Лисп учите и ukegst вопросы возникать не будут.

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

Читать:

1. Pragmatic Programmer про метаданные
2. Эрика Реймонда "Art Of The Unix Programming" про метаданные, протоколы, policy/mechanism
3. А. Легалов "Разнорукое программирование", критика ООП как универсального инструмента, предложение других вариантов расширения, сочетание этого + ООП + процедурное программирование
4. М. Горбунов-Посадов, "Расширяемые программы" про метаданные, "однородный набор", варианты/гнёзда для расширения. Аспекты, короче говоря, если отвлечься от терминологии велосипедизма которая проходит через всю книгу.

А. Легалов, М. Горбунов-Посадов...

Что-то не доверяю я русским авторам. По мне так SICP заменяет все книги одним разом.

А по теме - автор молодец, что задумываеться по таким вещам. А истина как всегда лежит где-то по средине=)

> ну вот возьмем сферический язык в вакууме, где можно написать простой и логичный код без ООП для определённой задачи.

Лисп?

>Лисп?

Tcl :-P

>1. Создать некоторый объект, который будет привязан к файлу, его допустим сделать родителем для других объектов (например директория). Каждый этот объект реализовывает некоторые методы, имеет свойства, взаимодействует с другими объектами, ко всему этому приделываем гуй - всё казалось бы логично.

>2. Написать несколько ф-ций, которые реализуют некоторые операции (copy, move, ...) и состряпать к этому гуй.

>Вот мне например кажется, что второй вариант намного проще, однако первый вариант мне кажется логичнее. Вот и думаю, что выбрать? Стоит ли использовать ООП в данном случае? И вообще есть ли выгода использования ООП в тех задачах, где и без него получается простой и логичный код? Или я немного не понимаю что такое ООП?

Видишь ли, то что для тебя кажется серьезными и большими задачами, в развитых странах отдают подмастерьям aka русским, индусам, чтобы они сварганили по-быстрому и даже не задумываются о том, как подмастерье будет это делать. Там серьезные люди делают серьезные системы, гораздо, на десятки порядков сложнее файл-менеджера. Например Adobe Photoshop CS4, со всей инфраструктурой Adobe Cue. Или системы для биржевых котировок. Или СУ для марсоходов. Или движки поисковиков а-ля Google. И т.д. и т.п. Ты думаешь, в недрах движка google.gom все написано на C без ООПодхода? Или Photoshop написан без ООП?

>ну вот возьмем сферический язык в вакууме, где можно написать простой и логичный код без ООП для определённой задачи.

Без ООП получится структурное программирование в стиле 70-х годов прошлого века. Со всеми вытекающими траблами. От этого ушли к ООП, а ты хочешь вернуться в прошлое. Штож, барабан в руки.

Ну или без ООП получится функциональное программирование со всеми вытекающими напряжениями для железа, т.е. непомерным потреблением памяти и процессорных ресурсов. Тебя этот подход устраивает? Покупай 8Гб для виртуальных машин лиспа и хаскеля и барабан тебе на шею. Как ты думаешь, сколько памяти сожрет виртуальная машина лиспа, отрисовывая содержимое директории C:\windows\system32 с 1715 файлами? Правильно, метров эдак 128. А редактор а-ля Word для редактирования в WYSIWYG файлика метров в 10 все 2Гб лиспа сожрет

>можно немного перефразировать вопрос: вот мы имеем уже написанный код без ООП который выполняет определённую задачу, и является достаточно простым и в меру логичным, будет ли выгода если мы заменим его на код с ООП'ом?

Нет, конечно. Конечно не будет выгоды. Это же вполне очевидно. Только вот напиши сначала простой и в меру логичный код без ООП для реальной сложно задачи, а не для файл-менеджера. ООП оправдывает себя при УСЛОЖНЕНИИ ПО. Когда уже старыми структурными подходами не получается быстро и качественно налабать решение очередной более сложной, чем вчера, задачи. А на простых задачах ООПодходу лишь _обучают_.

Например, вот тебе для затравки http://www.linux.org.ru/view-message.jsp?msgid=3008720 http://www.linux.org.ru/view-message.jsp?msgid=3009137 Попробуй их функционал со всеми свистелками и перделками реализовать просто и логично. Без помощи ООП и на императивных языках.

> Нет, конечно. Конечно не будет выгоды. Это же вполне очевидно. Только вот напиши сначала простой и в меру логичный код без ООП для реальной сложно задачи, а не для файл-менеджера. ООП оправдывает себя при УСЛОЖНЕНИИ ПО. Когда уже старыми структурными подходами не получается быстро и качественно налабать решение очередной более сложной, чем вчера, задачи. А на простых задачах ООПодходу лишь _обучают_.

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