Есть ли в C FILE объектно-ориентированный интерфейс?
Ли FILE тип, используемый в стандартных функциях C fopenи т.п. есть объектно-ориентированный интерфейс?
Я ищу мнения с аргументацией, а не с абсолютным ответом, поскольку определения ОО зависят от того, кого вы спрашиваете. Какие важные концепции ОО встречаются или не встречаются?
В ответ на комментарий JustJeff, приведенный ниже, я не спрашиваю, является ли C языком OO, и разрешает ли C (легко или нет) программирование OO. (Разве это не отдельная проблема?)
7 ответов
С научной точки зрения, конечно, фактические файлы являются объектами. У них есть атрибуты, и вы можете выполнять над ними действия. Это не значит, что FILE - это класс, просто сказать, что есть степени OO-сущности, о которых нужно подумать.
Проблема с попыткой сказать, что интерфейс FILE stdio квалифицируется как OO, однако, заключается в том, что интерфейс FILE stdio не очень хорошо представляет "объектность" файла. Вы могли бы использовать ФАЙЛЫ под простым старым C ОО способом, но, конечно, вы утратили синтаксическую ясность, обеспечиваемую Java или C++.
Вероятно, следует дополнительно добавить, что, хотя вы не можете сгенерировать "наследование" из FILE, это дополнительно дисквалифицирует его как OO, но вы можете утверждать, что это скорее ошибка его среды (обычный C), чем абстрактная идея файла as -объект сам.
На самом деле... вы, вероятно, могли бы обосновать, что FILE является чем-то вроде Java-интерфейса. В мире Linux вы можете управлять практически любым устройством ввода-вывода с помощью вызовов open/close/read/write/ioctl; функции FILE - это просто обложки над ними; поэтому в FILE у вас есть что-то вроде абстрактного класса, который определяет основные операции (open / read / etc) на "устройстве ввода-вывода abstact", оставляя его на усмотрение различных типов производных типов, чтобы дополнить их специфичными для типа поведение.
Конечно, очень трудно увидеть ОО в куче кода на С, и очень легко сломать абстракции, поэтому настоящие языки ОО гораздо более популярны в наши дни.
Является ли C объектно-ориентированным языком?
Было ли ООП (объектно-ориентированное программирование) чем-то большим, чем лабораторная концепция, когда создавались C и FILE?
Ответ на эти вопросы ответит на ваш вопрос.
РЕДАКТИРОВАТЬ:
Дальнейшие размышления: объектно-ориентированное определенно означает несколько вариантов поведения, включая:
Наследование: Можете ли вы получить новые классы из FILE?
Полиморфизм: Можете ли вы рассматривать производные классы как файлы?
Инкапсуляция: Вы можете поместить ФАЙЛ в другой объект?
Методы и свойства: есть ли у ФАЙЛА методы и свойства, специфичные для него? (например, myFile.Name, myFile.Size, myFile.Delete())
Хотя существуют хорошо известные "трюки" C для выполнения чего-то, напоминающего каждое из этих поведений, это не встроено в FILE и не является первоначальным намерением.
Я пришел к выводу, что FILE не является объектно-ориентированным.
Если бы тип FILE был "объектно-ориентированным", по-видимому, мы могли бы извлечь из него какой-то осмысленный способ. Я никогда не видел убедительного примера такого происхождения.
Допустим, у меня есть новая аппаратная абстракция, немного похожая на сокет, которая называется червоточиной. Можно ли извлечь из FILE (или сокета) для его реализации. Не совсем - наверное, мне нужно внести некоторые изменения в таблицы в ядре ОС. Это не то, что я называю объектной ориентацией
Но весь этот вопрос в конечном итоге сводится к семантике. Некоторые люди настаивают на том, что все, что использует таблицу переходов, является объектно-ориентированным, и IBM всегда утверждала, что их блоки AS/400 являются объектно-ориентированными, сквозными и сквозными.
Для тех из вас, кто хочет окунуться в яму безумия и глупости, которая является новостной группой USENET comp.object, эта тема обсуждалась там довольно подробно несколько лет назад, хотя и безумными и глупыми людьми. Если вы хотите обойти эту глубину, вам следует начать с интерфейса групп Google.
Нет. C не является объектно-ориентированным языком.
Я знаю, что это "абсолютный ответ", который вы не хотели, но, боюсь, это единственный ответ. Причина в том, что C не является объектно-ориентированным, поэтому ни одна его часть не может иметь "объектно-ориентированный интерфейс".
Разъяснение:
На мой взгляд, истинная объектная ориентация включает в себя диспетчеризацию метода через полиморфизм подтипа. Если в языке этого нет, он не является объектно-ориентированным.
Объектная ориентация не является "техникой", как GTK. Это особенность языка. Если у языка нет возможности, он не является объектно-ориентированным.
Если бы объектная ориентация была просто техникой, то почти каждый язык можно было бы назвать объектно-ориентированным, и этот термин перестал бы иметь какое-либо реальное значение.
Это зависит. Как вы определяете "объектно-ориентированный интерфейс"? Как показывают комментарии к посту Абеленки, легко построить аргумент, что FILE является объектно-ориентированным. Это зависит от того, что вы подразумеваете под "объектно-ориентированным". У него нет методов-членов. Но у него есть определенные для него функции.
Он не может быть выведен из "обычного" смысла, но он кажется полиморфным. За указателем FILE реализация может широко варьироваться. Это может быть файл, это может быть буфер в памяти, это может быть сокет или стандартный вывод.
Это инкапсулировано? Ну, это по существу реализовано как указатель. Нет доступа к деталям реализации того, где находится файл, или даже к имени файла, если вы не вызовете для него надлежащие функции API. Это звучит инкапсулировано для меня.
Ответ в основном то, что вы хотите, чтобы это было. Если вы не хотите, чтобы FILE был объектно-ориентированным, тогда определите "объектно-ориентированный" таким образом, что FILE не сможет выполнить.
C имеет первую половину объектно-ориентированного. Инкапсуляция, т.е. вы можете иметь составные типы, такие как FILE* или структуры, но вы не можете наследовать от них, что является второй (хотя и менее важной) половиной
Есть разные определения oo вокруг. Одна из них, которую я считаю наиболее полезной, - это следующее (вдохновлено Аланом Кей):
- объекты содержат состояние (т.е. ссылки на другие объекты)
- объекты получают (и обрабатывают) сообщения
- обработка сообщения может привести к
- отправка сообщений самому объекту или другим объектам
- изменение состояния объекта
Это означает, что вы можете программировать объектно-ориентированным способом на любом императивном языке программирования - даже на ассемблере. Чисто функциональный язык не имеет переменных состояния, что делает невозможным или, по крайней мере, неудобным для реализации (помните: LISP не чист!); то же самое должно быть с чисто декларативными языками.
В C передача сообщений чаще всего реализуется как вызовы функций с указателем на структуру, содержащую состояние объекта в качестве первого аргумента, как в случае с API обработки файлов. Тем не менее, C как язык не может быть классифицирован как oo, так как он не имеет синтаксической поддержки этого стиля программирования.
Кроме того, некоторые другие определения oo включают в себя такие вещи, как наследование на основе классов (так что насчет прототипных языков?) И инкапсуляцию - которые, на мой взгляд, не очень важны - но некоторые из них могут быть реализованы в C с помощью некоторого указателя и приведения магия.