Есть ли в FILE C объектно-ориентированный интерфейс?

Question

Имеет ли тип FILE, используемый в стандартных функциях C fopen и т. Д., Объектно-ориентированный интерфейс?

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

В ответ на комментарий JustJeff, приведенный ниже, я не спрашиваю, является ли C языком OO или C (легко или нет) допускает программирование OO. (Разве это не отдельная проблема?)

Answer 1

Если бы тип FILE был «объектно-ориентированным», предположительно, мы могли бы извлечь из него какой-то осмысленный способ. Я никогда не видел убедительного примера такого происхождения.

Допустим, у меня есть новая аппаратная абстракция, немного похожая на сокет, которая называется червоточиной. Можно ли извлечь из FILE (или сокета) для его реализации. Не совсем - я, вероятно, должен внести некоторые изменения в таблицы в ядре ОС. Это не то, что я называю объектной ориентацией

Но в конечном итоге весь этот вопрос сводится к семантике. Некоторые люди настаивают на том, что все, что использует таблицу переходов, является объектно-ориентированным, и IBM всегда утверждала, что их блоки AS / 400 являются объектно-ориентированными, сквозными и сквозными.

Для тех из вас, кто хочет окунуться в яму безумия и глупости, которая является новостной группой USENET comp.object, эта тема обсуждалась там довольно подробно несколько лет назад, хотя и безумными и глупыми людьми. Если вы хотите пробраться на эти глубины, вам стоит начать с интерфейса Google Groups .

Answer 2

Является ли C объектно-ориентированным языком?

Было ли ООП (объектно-ориентированное программирование) чем-то большим, чем лабораторная концепция при создании C и FILE?

Ответ на эти вопросы ответит на ваш вопрос.

EDIT:

Дальнейшие мысли: Объектно-ориентированное определенно означает несколько вариантов поведения, в том числе:

Наследование: Можете ли вы получить новые классы из FILE?

Полиморфизм: Можно ли рассматривать производные классы как ФАЙЛЫ?

Инкапсуляция: Можете ли вы поместить ФАЙЛ в другой объект?

Методы и свойства: Имеет ли ФАЙЛ методы и свойства, специфичные для него? (например. myFile.Name, myFile.Size, myFile.Delete ())

Хотя существуют хорошо известные «трюки» C для выполнения чего-либо, напоминающего каждое из этих поведений, это не встроено в FILE и не является первоначальным намерением.

Я заключаю, что FILE не является объектно-ориентированным.

Answer 3

C ориентирован на первую половину объекта. Инкапсуляция, то есть вы можете иметь составные типы, такие как FILE * или структуры, но вы не можете наследовать от них, что является второй (хотя и менее важной) половиной

Answer 4

Это зависит. Как вы определяете «объектно-ориентированный интерфейс»? Как показывают комментарии к посту Абеленки, легко построить аргумент, что FILE является объектно-ориентированным. Это зависит от того, что вы подразумеваете под «объектно-ориентированным». У него нет методов-членов. Но у него есть функции, специфичные для него.

Он не может быть получен из "обычного" смысла, но кажется, что он полиморфный. За указателем FILE реализация может широко варьироваться. Это может быть файл, это может быть буфер в памяти, это может быть сокет или стандартный вывод.

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

Ответ в основном такой, какой вы хотите. Если вы не хотите, чтобы FILE был объектно-ориентированным, тогда определите «объектно-ориентированный» таким образом, который FILE не сможет выполнить.

Answer 5

С академической точки зрения, конечно, фактические файлы являются объектами . У них есть атрибуты, и вы можете выполнять над ними действия. Не означает, что FILE является классом , просто говоря, что существуют степени OO-сущности, о которых следует подумать.

Проблема с попыткой сказать, что интерфейс FILE stdio квалифицируется как OO, однако, заключается в том, что интерфейс FILE stdio не очень хорошо представляет «объектность» файла. Вы могли бы использовать ФАЙЛЫ под простым старым C ОО способом, но, конечно, вы утратили синтаксическую ясность, обеспечиваемую Java или C ++.

Вероятно, следует дополнительно добавить, что, хотя вы не можете сгенерировать «наследование» из FILE, это дополнительно дисквалифицирует его как OO, но вы можете утверждать, что это скорее ошибка его среды (простой C), чем абстрактная идея сам файл как объект.

На самом деле .. вы могли бы , вероятно, обосновать, что FILE - это что-то вроде интерфейса Java. В мире Linux вы можете управлять практически любым устройством ввода-вывода с помощью вызовов open / close / read / write / ioctl; функции FILE - это просто обложки над ними; следовательно, в FILE у вас есть что-то вроде абстрактного класса, который определяет основные операции (open / read / etc) на «устройстве ввода-вывода abstact», оставляя его на усмотрение различных видов производных типов для flesh те с типо-специфическим поведением.

Конечно, очень трудно увидеть ОО в куче кода на Си и очень легко разбить абстракции, поэтому настоящие языки ОО гораздо более популярны в наши дни.

Answer 6

Нет. C не является объектно-ориентированным языком.

Я знаю, что это "абсолютный ответ", который вы не хотели, но, боюсь, это единственный ответ. Причина в том, что C не является объектно-ориентированным, поэтому ни одна его часть не может иметь «объектно-ориентированный интерфейс».

Пояснение:

По моему мнению , истинная объектная ориентация включает в себя диспетчеризацию метода через полиморфизм подтипа. Если в языке этого нет, он не является объектно-ориентированным.

Объектная ориентация не является «техникой», подобной GTK. Это особенность языка. Если в языке нет возможности, он не является объектно-ориентированным.

Если бы объектная ориентация была просто техникой, то почти каждый язык можно было бы назвать объектно-ориентированным, и термин перестал бы иметь какое-либо реальное значение.

Answer 7

Существуют разные определения oo вокруг. Одна из них, которую я считаю наиболее полезной, - это следующее (вдохновлено Аланом Кей):

1. объекты содержат состояние (т.е. ссылки на другие объекты)
2. объекты получают (и обрабатывают) сообщения
3. обработка сообщения может привести к
   • отправляемых сообщений на сам объект или другие объекты
   • изменение состояния объекта

Это означает, что вы можете программировать объектно-ориентированным способом на любом императивном языке программирования - даже на ассемблере. Чисто функциональный язык не имеет переменных состояния, что делает его невозможным или, по крайней мере, неудобным для реализации (помните: LISP не чист!); то же самое должно быть с чисто декларативными языками.

В C передача сообщений чаще всего реализуется как вызовы функций с указателем на структуру, содержащую состояние объекта в качестве первого аргумента, как в случае с API обработки файлов. Тем не менее, C как язык не может быть классифицирован как oo, поскольку у него нет синтаксической поддержки этого стиля программирования.

Кроме того, некоторые другие определения oo включают такие вещи, как наследование на основе классов (ну, как насчет языков-прототипов?) И инкапсуляцию - которые, на мой взгляд, не очень важны - но некоторые из них могут быть реализованы в C с некоторым указателем - и сотворение магии.