Позвольте мне подойти к этому как к одному старому программисту из 70-х к другому (?)
Один из распространенных приемов в старые времена, когда мы писали библиотеку, заключался в вызове init, который создавал некоторыевид «cookie» (обычно указатель или индекс массива).Затем мы заставляли клиента возвращать нам куки при каждом последующем обращении к библиотеке.Это позволило нам сделать все необходимое для поддержки нашей библиотеки (с повторным входом) без ошибок клиента со всеми деталями реализации.Как программист C, вы должны быть хорошо знакомы с этим стилем, потому что C использует его для всех своих файловых операций ввода-вывода, как и Unix.Microsoft любила называть их «ручками» вместо «куки».Unix называл их «файлами» или иногда «файловыми дескрипторами».
Большая часть того, что делают ОО-языки, - это просто добавить дополнительный синтаксис вокруг этой техники.Теперь вместо всех ваших звонков, начинающихся с LibnameCallname (cookie, ..., они начинаются с cookie.callname(....Но на самом деле, во многих отношениях это всего лишь изменение синтаксиса, чтобы упростить задачу для нас, программистов (избавляет нас от необходимости набирать лишние Libname для всего).
В некотором смысле, операционные системы (включая Unix), который использовал файл в качестве основной парадигмы для чертовски почти всего), уже являются OO , а были OO в течение десятилетий .То, как они обрабатывают вызовы ОС, на самом деле просто деталь связи.Для системных программистов это не имеет большого значения, за исключением того, что связи должны совпадать.Единственная реальная проблема с вызовом C ++ из C не в том, что это "OO".Проблема в том, что C ++ использует какой-то собственный алгоритм преобразования имен для своих символов, с которым не все компиляторы C могут иметь дело.
По правде говоря, в этом есть нечто большее.Тем не менее, если кто-то напишет все свои новые вызовы ОС на C ++, вы можете поспорить, что поставщики компиляторов C найдут способ сократить разрыв, чтобы вы могли вызывать их в своем старом удобном стиле LibnameCallname(cookie,... из C.
То, что вы на самом деле говорите, что вам не нравится, мне кажется, это то, что Парнас впервые назвал еще в 1972 году как Скрытие информации - Идея, что разработчики могут быть более продуктивными, еслиподробности о том, как различные части программы скрыты от других частей.
В то время это было очень противоречиво.Даже в начале девяностых я слышал об этом громкие споры.Фредрик Брукс даже выступил против этого в Мифическом человеко-месяце .(Кстати: если вы не читали TMM-M, , вам нужно .)
Дело в том, что сегодня почти никто не спорит с этим.Для этого есть причина.Даже Фред Брукс признал, что ошибался двадцать лет спустя.Из его эссе под заголовком Парнас был прав, а я был не прав насчет сокрытия информации -
Парнас был прав, а я был неправ.Теперь я убежден, что сокрытие информации, которая сегодня часто воплощается в объектно-ориентированном программировании, является единственным способом повышения уровня разработки программного обеспечения.
Справедливости ради, обе стороны согласны с тем, что в очень малых масштабахСистемы (например, встроенные системы, с которыми вы играли?) скрывают информацию не так уж и необязательно.Только когда системы начнут становиться действительно большими, полностью взаимосвязанная система начнет падать под собственным весом.Однако сегодня большинство программ настолько велики.Это основная причина, по которой аргументы прекратились.