>[оверквотинг удален]
> задача не решается в рамках методов которые приняты - значит принятые
> методы плохие при условии корректного решения. Чуть позже я наткнулся на
> проект (название не сохранилось) программиста из японии (специально глянул страну автора)
> который писал проект на С++, но обильно использовал технику подобную тому
> которую использовал я в своих последних проектах на С++. Ну а
> дальше погуглил и почитал форумы и дискуссии умных и опытных людей
> и решил закончить писать на С++. Сейчас свободно пишу на Си
> придерживаясь объектной нотации. С гибкостью Си сопоставим только Perl (возможно есть
> еще языки вроде фортрана, PL/1, ...), ну а превосходит Си только
> Asm.С++ -- язык, имеющий к ООП крайне отдаленное отношение. Он не поддерживает один из двух основных краеугольных камней ООП -- механизм обмена сообщениями. Объекты между собой в ОО парадигме взаимодействуют, исключительно обмениваясь сообщениями и это есть единственный способ их взаимодействия. Если же подходить менее строго, то есть еще и системные коммуникации типа совместно используемой памяти и всего остального, если сообщений окажется недостаточно. По моему этого более чем достаточно. тем не менее, в C++ нет ни операторов, ни протоколов. Зато есть полиморфизм, никакого отношения к ООП не имеющий, но активно, прямо таки надрывным криком выдваемый за признак ООП.
Наследование, несомненно, облегчает жизнь программисту, но никакого отношения к ООП оно опять же не имеет. Неомненно, это удобно и в языке должно быть. Но все это должно обрабатываться статически и не добавлять лишних проверок и вызова темных функций из темных шареных либ. Иначе эффективнее возложить синхронизацию на внешний по отношению к языку механизм.
Кто-то где-то отрыгнул, что сообшения в C++ заменены во сто крат более эффективным механизмомм -- объект, который хочет послать сообщение другому, может залезть в его адресное пространство через специальную дырку (с помощью специально предоставленного получаюшщим сообщение объектом метода) и посрать там как он хочет -- глваное, чтобы оба понимали, какая кучка что означает. Тут конечно мы спрашиваем -- т.е это я сам должен реализовавать ту часть протокола взаимодействия, которая отвечает за установелние соединения, его обслуживание и завершение? Но таки этот процесс должен быть скрыт от пользователя. В ООП языке должен присутствовать оператор установления соединения между объектами и оператор бродкаста. Ну или чтото-то похожее. Иначе два объекта не смогут обмениваться друг с другом. В C++ ничего похожего нет. Зато там есть хрень типа template, которая облегчая жизнь ленивому программисту, оставляет гору подводных камней в отношении производительности -- часто код годами работает у клиента, будучи собранным в отладочном режиме. И когда на замечание о вычислительной производительности компилята из-под С++ я слышу мантры об оптимизации кода, я говорю -- возможно этот код всегда будет собираться с опцией -O0, но это никак не должно отражаться на юзабилити. И тогда я слышу сладкое -- ну тогда его надо было писать на голых сях -- а кто вам мешал? -- а как-то в падлу -- ну так прописывайся у клиента и ремонтируй.
|
