C的FILE是否具有面向对象的接口？

Question

Does the FILE type used through standard C functions fopen , etc. have an object-oriented interface?

I'm looking for opinions with reasoning rather than an absolute answer, as definitions of OO vary by who you ask. What are the important OO concepts it meets or doesn't meet?

In response to JustJeff's comment below, I am not asking whether C is an OO language, nor whether C (easily or not) allows OO programming. (Isn't that a separate issue?)

Answer 1

Is C an object-oriented language?

Was OOP (object-oriented-programming) anything more than a laboratory concept when C and FILE were created?

Answering these questions will answer your question.

EDIT:

Further thoughts: Object Oriented specifically means several behaviors, including:

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())

Although there are well known C "tricks" to accomplish something resembling each of these behaviors, this is not built in to FILE, and is not the original intent.

I conclude that FILE is not Object Oriented.

Answer 2

If the FILE type were "object oriented", presumably we could derive from it in some meaningful way. I've never seen a convincing instance of such a derivation.

Lets say I have new hardware abstraction, a bit like a socket, called a wormhole. Can I derive from FILE (or socket) to implement it. Not really - I've probably got to make some changes to tables in the OS kernel. This is not what I call object orientation

But this whole issue comes down to semantics in the end. Some people insist that anything that uses a jump-table is object oriented, and IBM have always claimed that their AS/400 boxes are object-oriented, through & through.

For those of you that want to dip into the pit of madness and stupidity that is the USENET comp.object newsgroup, this topic was discussed quite exhaustively there a few years ago, albeit by mad and stupid people. If you want to trawl those depths, the Google Groups interface is a good place to start.

Answer 3

No. C is not an object-oriented language.

I know that's an "absolute answer," which you didn't want, but I'm afraid it's the only answer. The reasoning is that C is not object-oriented, so no part of it can have an "object-oriented interface".

Clarification:

In my opinion , true object-orientation involves method dispatch through subtype polymorphism. If a language lacks this, it is not object-oriented.

Object-orientation is not a "technique" like GTK. It is a language feature. If the language lacks the feature, it is not object-oriented.

If object-orientation were merely a technique, then nearly every language could be called object-oriented, and the term would cease to have any real meaning.

Answer 4

Academically speaking, certainly the actual files are objects . They have attributes and you can perform actions on them. Doesn't mean FILE is a class , just saying, there are degrees of OO-ness to think about.

The trouble with trying to say that the stdio FILE interface qualifies as OO, however, is that the stdio FILE interface doesn't represent the 'objectness' of the file very well. You could use FILEs under plain old C in an OO way, but of course you forfeit the syntactic clarity afforded by Java or C++.

It should probably further be added that while you can't generate 'inheritance' from FILE, this further disqualifies it as OO, but you could argue that's more a fault of its environment (plain C) than the abstract idea of the file-as-object itself.

In fact .. you could probably make a case for FILE being something like a java interface. In the linux world, you can operate almost any kind of I/O device through the open/close/read/write/ioctl calls; the FILE functions are just covers on top of those; therefore in FILE you have something like an abstract class that defines the basic operations (open/read/etc) on an 'abstact i/o device', leaving it up to the various sorts of derived types to flesh those out with type-specific behavior.

Granted, it's very hard to see the OO in a pile of C code, and very easy to break the abstractions, which is why the actual OO languages are so much more popular these days.

Answer 5

It depends. How do you define an "object-oriented interface"? As the comments to abelenky's post shows, it is easy to construct an argument that FILE is object-oriented. It depends on what you mean by "object-oriented". It doesn't have any member methods. But it does have functions specific to it.

It can not be derived from in the "conventional" sense, but it does seem to be polymorphic. Behind a FILE pointer, the implementation can vary widely. It may be a file, it may be a buffer in memory, it may be a socket or the standard output.

Is it encapsulated? Well, it is essentially implemented as a pointer. There is no access to the implementation details of where the file is located, or even the name of the file, unless you call the proper API functions on it. That sounds encapsulated to me.

The answer is basically whatever you want it to be. If you don't want FILE to be object-oriented, then define "object-oriented" in a way that FILE can't fulfill.

Answer 6

C has the first half of object orientated. Encapsulation, ie you can have compound types like FILE* or structs but you can't inherit from them which is the second (although less important) half

Answer 7

There are different definitions of oo around. The one I find most useful is the following (inspired by Alan Kay):

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

This means you can program in an object-oriented way in any imperative programming language - even assembler. A purely functional language has no state variables, which makes oo impossible or at least awkward to implement (remember: LISP is not pure!); the same should go for purely declarative languages.

In C, message passing in most often implemented as function calls with a pointer to a struct holding the object's state as first argument, which is the case for the file handling api. Still, C as a language can't be classified as oo as it doesn't have syntactic support for this style of programming.

Also, some other definitions of oo include things like class-based inheritance (so what about prototypal languages?) and encapsulation - which aren't really essential in my opinion - but some of them can be implemented in C with some pointer- and casting magic.