Вопрос по c, oop – Есть ли в FILE C объектно-ориентированный интерфейс?

4

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

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

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

Вы спрашиваете, является ли FILE объектоподобным или C? Потому что люди, кажется, отвечают на разные вопросы. JustJeff
Это не отдельная проблема; учитывая, что C не поддерживает объекты (напрямую), он не может иметь объектно-ориентированного интерфейса ни для чего. Imagist
Если объектная ориентация является не техникой, а особенностью языка (как я полагаю), и если C не является объектно-ориентированным по этому определению, тогда FILE не объектно-ориентирован. Однако, если объектная ориентация является просто техникой, тогда FILE может быть объектно-ориентированным. (В этом случае у меня нет мнения по этому поводу.) Gregory Higley

Ваш Ответ

7   ответов
3

по-видимому, мы могли бы извлечь из него какой-то осмысленный способ. Я никогда не видел убедительного примера такого вывода.

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

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

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

Или возражаю, я замечаю!
@ R.Pate Эти языки допускают деривацию - они также позволяют предотвращать ее. Вы, кажется, настраиваете ложную дихотомию. Честно говоря, меня не все интересуют, является ли язык ОО - меня больше интересует, является ли он полезным.
зависит от того, как вы определяете деривацию. Сокеты и многое другое прекрасно вписывается в абстракцию FILE. В posix почти все это ФАЙЛ. Все ли они являются производными одного и того же интерфейса? (Между прочим, я не понизил вас, просто для протокола.)
Вот Это Да! Репутация Нейла поднялась с 21,9К до 21,9К! Есть еще один, давайте посмотрим на часы до 22K.
лол, только что сделал. :п
1

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

Clarification:

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

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

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

Если в С отсутствует механизм объектной ориентации, как любая его часть может быть объектно-ориентированной?
Я не пытаюсь получить корни С, но корни полиморфизма. Я специально спросил о конкретном примере, который является (ИМХО) пограничным, чтобы избежать чистой теории. Полиморфизм кажется ключевым требованием к вам, возможно, самым важным? Есть ли другие требования?
Написав механизм самостоятельно на C. Играя в игры с приведением к void и создавая свои собственные vtables, вы можете поддерживать наследование, полиморфизм и инкапсуляцию в C, это просто боль в заднице, чтобы сделать это. Исходные реализации C ++ генерировали исходный код C, который затем компилировался.
На отдельном, но связанном примечании: если FILE не имеет полиморфного интерфейса, соответствуют ли файловые дескрипторы этому требованию? Если это так, они ориентированы на объект или каким образом им все еще не хватает?
Это действительно странная логика - «Дом не белый, поэтому никакая его часть не может быть белой».
1

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

3

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

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

EDIT:

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

Inheritence: Can you derive new classes from FILE?

Polymorphism: Can you treat derived classes as FILEs?

Encapsulation: Can you put a FILE inside another object?

Methods & Properties: Does a FILE have methods and properties specific to it? (eg. myFile.Name, myFile.Size, myFile.Delete())

Хотя существуют хорошо известные «трюки». чтобы выполнить что-то похожее на каждое из этих поведений, это не встроено в ФАЙЛ и не является первоначальной целью.

Я пришел к выводу, что FILE не является объектно-ориентированным.

@jalf: все еще не может его подкласс. Подклассы обычно рассматриваются как важная часть ОО, поэтому без возможности подкласса ФАЙЛ он не соответствует определению на полностью функциональных терминах, независимо от синтаксиса.
Хотя язык не предназначен специально для объектно-ориентированной разработки, это не означает, что вы не можете реализовать объектно-ориентированные интерфейсы вручную (используя структуры и указатели функций). Возьмите GLib / GObject для примера.
Являются ли такие функции, как fopen, fclose, freopen, не методами объектов FILE? Является ли отличительная особенность методов простым языковым синтаксисом, который вы вызываете с помощью синтаксиса .b?
Как сказал Р. Пейт, вы, похоже, определяете OO-сущность как свойство синтаксиса. Он является объектно-ориентированным, если вызов метода включает в себя точку, в основном то, на что это похоже. fopen выглядит как «метод, специфичный для ФАЙЛА»; мне. Вы не согласны? Что касается инкапсуляции, разве ФАЙЛ не инкапсулирует все внутренние детали? Можете ли вы покопаться в ФАЙЛЕ, получая доступ к деталям реализации, которые вам не нужны? Это выглядит довольно хорошо для меня. Полиморфизм? Я могу рассматривать сокет или stdin / stdout как файлы. Разве это не полиморфное поведение?
Я думаю, что в ОО будет больше, чем будет дано ответ на вопрос в результате этого вопроса.
0

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

objects hold state (ie references to other objects) objects receive (and process) messages processing a message may result in messages beeing sent to the object itself or other objects a change in the object's state

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

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

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

Не могли бы вы применить свой анализ к интерфейсу FILE?
1

actual files являютсяobjects, У них есть атрибуты, и вы можете выполнять над ними действия. Не означаетFILE этоclassЯ просто хочу сказать, что есть степени OO-Ness, о которых нужно подумать.

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

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

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

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

"как будто каким-то образом OO-сущность языка наполняет что-либо, представленное в нем, также как и OO по своей сути" - кажется очень верным для меня. Как насчет обратного: если поддержка ОО языка минимальна или не существует, делает ли это что-либо визуализируемым в нем по сути не ОО?
Что-то не ООП только потому, что это не синтаксически ясно? Считаете ли вы синтаксическую ясность требованием для ООП?
какие виды вещей квалифицируются как ОО? Может ли дизайн быть ОО? конечно! язык может быть ОО? в самом деле! Может ли реализация системы быть ОО? Да, несколько независимо от того, является ли основной язык. Может ли часть языка быть ОО? Вы также можете спросить, может ли одна травинка быть газоном?
га. какой беспорядок удалять. удалять. удалять.
лично? нет. я думаю, что OO-Ness в конечном итоге находится в дизайне. тот факт, что некоторые языки имеют синтаксис, который позволяет простой реализации выражать эти аспекты проекта, является просто изящным. И наоборот, существует множество классических процедурных / структурированных программ, выполненных на Java и рекламируемых как «OO». просто b / c "язык - это OO", как будто каким-то образом OO-сущность языка наполняет все, что визуализируется в нем, также как и по сути OO.
1

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

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

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

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

Мне нравится твой ответ, Джалф. это то, что я бы тоже сказал. я всегда рассматривал ФАЙЛ как объектно-ориентированный.
@ Чарльз: Я согласен с тем, что сложно назвать это наследованием или деривацией, но это, безусловно, полиморфизм, а не композиция. Поведение объекта FILE изменяется в зависимости от того, какую из множества реализаций вы используете.
Я не вижу, что FILE может быть получен из любого разумного смысла слова производного. ФАЙЛ не является сокетом, файл не является буфером, файл не является потоком. Он может содержать любой из этих элементов, но это может показаться примером композиции, а не полиморфизма. Ваша общая точка зрения все же принята. Нет никакого стандарта ANSI / ECMA для «объектно-ориентированного». Лучшее, что мы можем сделать, - это обычное использование, и мы могли бы провести весь день, споря об этом.

Похожие вопросы