Здравствуйте, batu, Вы писали:

B>Здравствуйте, LaptevVV, Вы писали:

LVV>>Однако некоторые языки (Додиез и Ява, например) программу сразу считают неким классом. И тут легко скатиться от ясных и понятных процессов в полную неразбериху объектов... Инструмент как бы провоцирует...

B>Та а чем процедуры и функции не классы. Если в голове порядок, то классы сами организуются. Если в этом имеется смысл. у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения. ИМХО, конечно.
Как и все в этой жизни, любой навык требует тренировок.
В голове порядок — это только "потом и кровью".
Топикстартер как раз и признается в первом посте, что у него подобного навыка нет.
Путь только один: — делать и дуумать, думать и делать. Тогда и порядок в голове объектно-ориентированный наступит...

Здравствуйте, WolfHound, Вы писали:

WH>Практика показывает, что повторно использовать можно только тот код, который специально для этого проектировался.
WH>А это по факту исключительно библиотеки общего назначения.

Не совсем верно. Правильно так:

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

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

у меня коллега с вами с радостью согласится — он второй месяц не может скопипастить нужные ему фрагменты кода, т.к. это не одна функция на 1000 строк, которую он мог бы скопипастить парой кликов, а проклятые классы со сраными функциями-членами, и "фиг их разберет, чо там нужно, чо нет" — первые попытки тупо копипастить "нужную", как ему кажется, функцию, провалились — надо копипастить больше, чем один сплошной фрагмент кода (объявления членов, хотя бы), а его мозг макаки на это уже неспособен. смешно, нужного кода ~200 строк, у класса ~4-5 функций членов, но он, похоже, не осилит.

Здравствуйте, mrTwister, Вы писали:

T>Здравствуйте, batu, Вы писали:

B>>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

T>Какие конкретно задачи ты имеешь ввиду?
Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>у меня коллега с вами с радостью согласится — он второй месяц не может скопипастить нужные ему фрагменты кода, т.к. это не одна функция на 1000 строк, которую он мог бы скопипастить парой кликов, а проклятые классы со сраными функциями-членами, и "фиг их разберет, чо там нужно, чо нет" — первые попытки тупо копипастить "нужную", как ему кажется, функцию, провалились — надо копипастить больше, чем один сплошной фрагмент кода (объявления членов, хотя бы), а его мозг макаки на это уже неспособен. смешно, нужного кода ~200 строк, у класса ~4-5 функций членов, но он, похоже, не осилит.
И что? Работает программистом?
Охренеть!!
Вот потому и падают Фобос-Грунты...

Здравствуйте, Undying, Вы писали:

U>Код в виде чистых функций повторно используется прекрасно, т.к. никаких лишних зависимостей за собой не тянет.

И давно это с ним? Как быть, например, с функцией подключения к DB, в реализации которой жёстко задано имя базы, хост, логин для подключения? Или функцией, которая по завершении сложной работы отправляет отчёт по e-mail? Или привязкой к тому, что данные могут быть только в cp1251?
Прежде чем такая функция станет пригодна для включения в библиотеку общего назначения, все подобные странные свойства должны быть параметризованы или отменены, и это достаточно приличный кусок работы (и хорошо, если без перелома всей логики).

Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB.
Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C.
Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов.
Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)

WH>>Практика показывает, что повторно использовать можно только тот код, который специально для этого проектировался.
WH>>А это по факту исключительно библиотеки общего назначения.

U>Не совсем верно. Правильно так:

U>

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

Это неверно, см. выше.
Вы не учитываете, что "функция" может иметь побочные эффекты, это раз.
Жёстко заданные особенности, это два. Причём вопрос не только в логинах, это как раз самый тривиальный пример. Есть более тонкие случаи. Например, для специфики исходной задачи характерно, что одна из порций промежуточных данных не превосходит 10 единиц, поэтому был взят самый тупой метод работы с ними, имеющий суммарную сложность O(n**3). Но у первого же переиспользующего этот код их стало 20000, и код "умер" на управлении этими данными, пришлось переписывать. Таких проблем можно вспомнить десятками из ближайшей практики.

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Путь только один: — делать и дуумать, думать и делать. Тогда и порядок в голове объектно-ориентированный наступит...
Ага.. Думать, делать и иметь смелость переделать

Здравствуйте, batu, Вы писали:

B>Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.

Ну то есть конкретных примеров нет, правильно я понимаю?

E>>ваша практика очень плохая и негодная.
WH>Ну, расскажи, как ты собрался повторно использовать кусок бизнеслогики?

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

Здравствуйте, Artifact, Вы писали:

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

драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.
вы пишите:

класс такой-то...
On_Init...
On_Exit...
On_XXX...
Do_Get

главная функция...
х = новый_класс...
x.run


и ведь ни черта не понятно. ибо вызов On_Init скрыт за фасадом. и до него хрен доберешься. и выясняется, что у нас есть Do_Get, но нету Do_Post. точнее, у нас есть Do_Post, но оно вызывается из кастомного On_Event, который реализован черт знает в каком месте и который зовет Do_Post (если мы его объявили).

> И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб,
> таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться
лобовой код понять зачастую легче потому что он представляет собой пошаговый план действий, которые можно читать последовательно как художественную книгу. вот, допустим, у нас тут цикл для вывода содержимого директории. вот вызовы find_fist, find_next. все понятно. а вот мы решили засунуть это в интератор. создает объект типа "директория", инициализируем чего-то (путь к директории, флаги поиска). создаем функцию иницилизации итератора. создаем функцию "следующий элемент". создаем функцию, возвращающую кол-во объектов. создаем функцию конвертации списка элементов в строку.

пишем o = dir(base_dir, find_all);
for file_name in o...

красиво? да. и меньше вероятность сделать ошибку. но больше объем кода и менее очевидно, что реально происходит внутри for a in b. код нельзя читать линейно, потому что он нелинеен по своей природе.

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

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

> На самую простую функциональность количество порой приближается к сотни.
потому что пытаются решить задачу в общем виде. например, когда мы создаем класс "содержимое директории" нам нужно создать методы "длина" и "преобразвание в строку", ибо они _могут_ потребоваться. хотя это жопа и жуткий оверхид. если АПИ не возвращает кол-во файлов в директории и нам нужно их перечислять явно, то на чистом си мы напишем FindFist/FindNext плюс, увеличивающийся на 1 каждый проход цикла. и за один раз получим и содержимое и кол-во элементов. а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию. но если мы хотим оптимизации, то можно схитрить и считать элементы в итераторе. а при достижении конца устанавливать скрытый флаг, что кол-во элементов известно. после чего функция "Длинны" возвратит это значение и все. но это сильно усложняет логику. и простая задача вывода содержимого директории раздувается до невероятных размеров.

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

Здравствуйте, Enomay, Вы писали:

V>>Осталось только определится с критерием понятного потока сознания. А вот с этим как раз большие проблемы. Даже если мы предположим что смена интерфейса (объекта, функции и т.п.) символизирует о нарушении в каком-то смысле задачи инкапсуляции, то как нам это измерить?

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

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

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

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

V>>Тем более что последний интерфейс вполне выполняет свою задачу, иначе нафига его оставили?
E>а я не понимаю для чего вы меняли интерфейс, если он вполне выполняет свою задачу

Да, каждый раз меняя интерфейс думаю — вот болван нужно ж было все предусмотреть сразу.

V>>Только давайте без разговоров о правильном сознании, правильных программистах, правильном выборе интерфейса и правильных объектах, а также противопоставление всего этого программистам сомневающимся в ООП. Чего-то ООП не хватает, знать бы чего?
E>от вас много слов, но о сферическом коне в вакууме. полно отсутствие какой либо конкретики. и для чего вы их пишете, совершенно непонятно.

Дак если бы было понятно. Хотелось бы.

М>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.

мда.

Здравствуйте, Vaako, Вы писали:

V>Дак если бы было понятно. Хотелось бы.

давайте вы приведете какие-то примеры кода, с проблемами. так будет понятнее.
а пока это просто размышления.

LVV>И что? Работает программистом?
LVV>Охренеть!!
LVV>Вот потому и падают Фобос-Грунты...

Работает! Этот его "культ Карго от программирования" продолжается уже лет 30. Фобосы не падают, его до такого никто в здравом уме не допустит, а его код, который он высрал лет 10 назад и на поддержке багов которого он, собственно, и живет —
"работает".

Здравствуйте, Enomay, Вы писали:

М>>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.

E>мда.
что мда? реализуйте мне класс "директория" с итератором и с api функциями FindFirst/FindNext, т.е. подсчитать сколько у нас элементов можно _только_ через вызов ff/fn. и через пост-процессинг (может мы поиск файла по регуляркам поддерживаем и api оси в ни жизнь не узнают сколько у нас там чего).

len реализуется только через итерирование. и никак иначе. и вывод имен файлов тоже.
for name in dir:
print name;
print len(dir);

и
count = 0;
for name in dir:
print name
count +=1
print count;

вы можете сказать что быстрее? нет, не можете. реализацию нужно смотреть. или доки читать. это плата за унифицированность и абстракцию. с этим вообще сложно спорить.

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

М>>>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.
E>>мда.
М>что мда? реализуйте мне класс "директория" с итератором и с api функциями FindFirst/FindNext, т.е. подсчитать сколько у нас элементов можно _только_ через вызов ff/fn. и через пост-процессинг (может мы поиск файла по регуляркам поддерживаем и api оси в ни жизнь не узнают сколько у нас там чего).

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

Здравствуйте, Enomay, Вы писали:

E>не нужно кидаться в крайности и возводить всё в абсолют.
E>бизнес логику необходимо повторно использовать там, где этому место. и никто не предлагает тащить её в другое приложение.
Ну, так расскажи как надо.
Покажи свою очень хорошую и годную практику.
Я тебе показал свой очень плохой и не годный проект.
Там чуть менее чем все функции используются ровно один раз.
Покажи, как это делают реальные пацаны. Чтобы все было круто и годно.
Чтобы каждая функция использовалась хотя бы 5 раз.
Иначе что это за повторное использование...
Кстати ООП там отсутствует чуть менее чем совсем.

Здравствуйте, Enomay, Вы писали:

М>>>>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.
E>>>мда.
М>>что мда? реализуйте мне класс "директория" с итератором и с api функциями FindFirst/FindNext, т.е. подсчитать сколько у нас элементов можно _только_ через вызов ff/fn. и через пост-процессинг (может мы поиск файла по регуляркам поддерживаем и api оси в ни жизнь не узнают сколько у нас там чего).

E>сохранять промежуточные результаты уже не модно?
а думать головой? вам не попадались директории в которых файлов чуть больше, чем дохрена?

E>если len нужно знать после итерирования, то она у нас уже есть, и повторно считать ничего не надо.
об этом я писал. но тут свои нюансы. len не будет перечитывать директорию и фиг его знает как ее обновить. итерировать снова?

E>если len получают до того, мы итерируем все элементы в фолдере и сохраняем len.
E>так же мы можем сохранить все элементы фолдера.
не можем. считаем, что кол-во памяти для хранения всех элементов очень велико. если элементы можно сохранить в памяти, то их можно вернуть одним списком и на фига нам цикл с итератором?

E> тем самым любое последующее обращение к нашему классу сразу вернет готовый
E> разультат без повторного считывания информации с диска.
E> где проблема?
проблем две.
первая -- при итерировании вызывается ff/fn и возвращается актуальный контент. при сохранении контента внутри класса -- увы.
вторая -- памяти может потребоваться очень много.

впрочем, перечитывание тоже имеет проблемы. результат возвращенный len может быть иным, чем кол-во интрированных элементов, т.к. ось живет своей жизнью и абстракция типа "директория" очень кривая абстракция. и чтобы она работала правильно -- нужно еще api для перехвата событий в файловой системе. но даже в этом случае остается проблема, что делать с len. если возвращать счетчик итератора то мы получаем неактуальный результат. если возвращать кол-во элементов на момент вызова len -- оно может не совпадать с тем, что мы получили ранее при итерации.

другими словами, реализовать правильно работающую абстракцию нельзя. ну потому что нельзя и все тут. и оно либо работает в 99 из 100, либо размеры кода поражают воображение, а размер спецификации рвет крышу. у нас есть len, но либо его нельзя применять к кол-ву итераций, либо с его помощью нельзя получать кол-во элементов на момент вызова.

наиболее правильным решением будет модель, реализующая копирование при записи. т.е. мы пишем: for a in b: res.append(a); а при изменении содержимого директории res меняется автоматом. но мне страшно представить объем кода. как минимум нужно переписать весь RTL и все стандартные либы.

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

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

Здравствуйте, мыщъх, Вы писали:

[поскипано]

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

Здравствуйте, мыщъх, Вы писали:

М>драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.

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

Некоторые задачи в принципе требуют объектно-ориентированной реализации, независимо от того, на каком языке они написаны. Но в ОО языке это будет явно, на C это будет вызов по типу fdp->fd_softc->read(), на Erlang это будет gen_server:call(Ref, foo), ещё где-то это может быть вообще реализовано как вызов Неведомой Сжиженной Триокиси или обращение с заданной молитвой к Его Пастафарианству. В любом из этих вариантов автор чётко определяет "объект" для воздействия, "метод" воздействия и что говорится этому методу. Как только есть явно оформленное обращение и три перечисленных "свойства" этого обращения — мы имеем дело с ООП.
(Дальше уже кто-то может говорить, что для ООП требуется инкапсуляция, наследование и так далее. Я сейчас не об этом, а о более высоком принципе.)

М>и ведь ни черта не понятно. ибо вызов On_Init скрыт за фасадом. и до него хрен доберешься. и выясняется, что у нас есть Do_Get, но нету Do_Post. точнее, у нас есть Do_Post, но оно вызывается из кастомного On_Event, который реализован черт знает в каком месте и который зовет Do_Post (если мы его объявили).

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

М>лобовой код понять зачастую легче потому что он представляет собой пошаговый план действий, которые можно читать последовательно как художественную книгу. вот, допустим, у нас тут цикл для вывода содержимого директории. вот вызовы find_fist, find_next. все понятно. а вот мы решили засунуть это в интератор. создает объект типа "директория", инициализируем чего-то (путь к директории, флаги поиска). создаем функцию иницилизации итератора. создаем функцию "следующий элемент". создаем функцию, возвращающую кол-во объектов. создаем функцию конвертации списка элементов в строку.

М>пишем o = dir(base_dir, find_all);
М>for file_name in o...

М>красиво? да. и меньше вероятность сделать ошибку. но больше объем кода и менее очевидно, что реально происходит внутри for a in b. код нельзя читать линейно, потому что он нелинеен по своей природе.

А с чего ты решил, что он раньше был линеен? Тот же find_first() может вычитывать целую порцию данных из каталога (или его целиком) и запоминать их. А может пользоваться средствами ОС для этого. Где-то может происходить сортировка данных, чтобы выдавать записи каталога в определённом порядке. А ты надеешься на то, что find_first() тебе будет работать так же, как если бы ты шёл вдоль улицы и считал дома и деревья? Это плохой, негодный пример. То же касается и оценки количества записей. У тебя она может, например, дать другое значение, чем подсчёт прочтённых элементов, потому что пока ты их читал — что-то добавилось и что-то изменилось.

Может, ты тут в каком-то случае прав, но этот пример точно не подходит под описание.

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

М>плюс полулегальная возможность у вызываемой мной функции снимать мой обработчик исключений и ничего мне об этом не говорить.

Этого не понял, можно подробнее?

M> и у меня при выбросе исключения управление передается куда-то внутрь и вообще мне не возвращается. и получается, что баг мой (допустим, обращение к нулевому указателю), но я его не могу отловить. это даже похуже GOTO. дочерняя функция не может заставить мой код прыгать в нее иначе как модификацией кода, что очень грязный хак и напрямую в ЯВУ нереализуем. а в ООП и без исключений дочка меняет таблицы виртуальных функций (тоже грязный хак, но таки реализуемый без ассемблерных вставок) и у меня едет крыша.

Это не в ООП, это в конкретном C++ или C. Или в любом другом, где разрешена игра с указателями и генерация их из чисел.

М>потому что пытаются решить задачу в общем виде. например, когда мы создаем класс "содержимое директории" нам нужно создать методы "длина" и "преобразвание в строку", ибо они _могут_ потребоваться. хотя это жопа и жуткий оверхид.

Это зачем они могут потребоваться? Может, когда они таки кому-то потребуются — точнее, не они, но исполняемые ими задачи — будет уточнено, что именно надо делать, почему и как?
А то длина, например, может иметь разные значения в зависимости от того, как и в какой момент считать.

M> если АПИ не возвращает кол-во файлов в директории и нам нужно их перечислять явно, то на чистом си мы напишем FindFist/FindNext плюс, увеличивающийся на 1 каждый проход цикла. и за один раз получим и содержимое и кол-во элементов. а по правилам ООП мы вынуждены перечитывать директорию два раза.

Никто не вынужден. Точно так же можно возвращать длину только если явно пройдено перечисление или запрошена длина заранее (но тогда должно быть указано, что до завершения первого прогона это дорогая операция). А ещё можно закэшировать несколько первых элементов, насколько хватит памяти, чтобы сократить старт, если длину спросили до первого прогона итерирования. И всему этому ООП не противоречит, а, наоборот, способствует (ты зовёшь next() у объекта, не интересуясь, он это берёт из кэша или у ОС).

M> это плата за абстракцию. но если мы хотим оптимизации, то можно схитрить и считать элементы в итераторе. а при достижении конца устанавливать скрытый флаг, что кол-во элементов известно. после чего функция "Длинны" возвратит это значение и все. но это сильно усложняет логику. и простая задача вывода содержимого директории раздувается до невероятных размеров.

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

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

Ну так и не надо строить на неизвестное будущее. Вот зачем тебе "вывод в строку", когда он ещё не требовался?