Object-Oriented Programming in C (2019) [pdf](state-machine.com) |
Object-Oriented Programming in C (2019) [pdf](state-machine.com) |
The fiction has largely dissipated, except among pundits and the aggressively ignorant. Meanwhile, a backlash insisting OO is a fundamentally mistaken design element arose among some loud users of not-OO (not to say not-good!) languages. Even among users of what were called OO languages, C++ particularly, the relative importance of OO techniques has fallen off as other language facilities and conventions surfaced.
C is just not adequately equipped for what is formally defined as OO. You can cobble up a dodgy simulacrum of it, with enough effort, but what is the point? Other languages make it easy, and can invariably be used in place of C if you really feel like you want OO.
If you are coding C++, you probably long ago graduated from the notion that "OO" has any particular merit as an organizing principle, and simply use language features to achieve your goals. Some part of any big-enough system will look OO, more or less, if you care. Few working C++ programmers do.
Some languages, Java particularly, aggressively try to horn everything into the OO shoe. The result is that if what you want to do doesn't fit, you must abuse what features the language offers to achieve what you mean to do, typically with some violence to OO norms. There's nothing wrong with that. It was, rather, wrong for the language to provide you with only OO facilities to the exclusion of all else.
A similar thing happened with functional programming.
> WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease.
Apparently Microsoft does care about OOP in C++.
As does Apple,
https://developer.apple.com/metal/
https://developer.apple.com/documentation/driverkit
And Google,
https://github.com/google/oboe
https://www.tensorflow.org/api_docs
Maybe modern C++ is safe from OOP, so lets look into ranges,
https://en.cppreference.com/w/cpp/ranges
So we have factories, adaptors, concepts (aka interfaces/traits in other languages), std::ranges::view_interface as base class mixin, all stuff I can find on the Gang of Four book.
Likewise the others, with one exception. The Apple driverkit page does mention base classes.
Factories, adaptors, concepts/traits/interfaces have nothing to do with OO, beyond that OO designs often also use them. OO designs define functions, too, but functions do not imply OO.
It is, in any case, meaningless to trot out apparatus system-vendors oblige programmers to use to access proprietary facilities, and equate that to programmers' interest in whatever tech is used for them. Programmers are interested in using the facilities, and are glad when whatever they are obliged to use works at all; too often it doesn't.
My main grip with Java is that everything is by default a library.
But there is hope, recent changes in Java, records and pattern matching move away from that idea.
Excellent point, and I think in our contemporary age something similar is happening with "Agile". It has ceased to become a project management technique useful for a certain class of products. It has instead become redefined to mean "good" - for example, in popular imagination, if a team is not "Agile" then they are somehow backwards or out-of-the-loop. Now teams, products, and situations where Agile is not appropriate are finding themselves having it forced upon them, or spinning what they do as agile.
C++ had, for a long time, problem mapping classes and objects in python or ruby, and usually, that was done via C wrappers and hacks. In recent years, things are a little better thanks to clang, but there are still tons of template hacks and C workarounds if you want portable code between compilers. Even then, you often rely on compiler specific stuff.
Other languages are much worse, so the only solution, frequently, is to use a virtual machine, like JVM or .NET.
According to Alan Kay (one of the creators of Smalltalk, the first OOP), message passing is more important to OOP than inheritance. If you listen to his old speeches, what he is describing sounds a lot more like microservices and VMs/containers than what most of the later languages turned it into. (He describes objects as "mini computers" that interact with each other using only public interfaces)
Alan Kay gets credit for the name "object-oriented", not the concept. His own definition has varied radically over the years, insisting only lately on any importance of message passing, as such. Smalltalk-72 was not OO. Smalltalk gained OO features over the time from 1972 to 1980. (Message passing has anyway always been isomorphic to function calls.)
Reflection was never described as essential to OOP. It is a feature of many languages, equally useful in all.
For example Linux Kernel style is:
static const struct file_operations fops = {
.open = my_open,
.release = my_release,
.read = my_read,
.write = my_write
};
Tenuous - if you are willing to implement objects yourself then you could use C sure, but I don't think that means the language "lets you use OO". It's like you could also probably implement algebraic datatypes in C using unions and structs, but would that mean "C lets you use algebraic datatypes"? I would strongly argue no.
Thus, to meaningfully claim that a language supports some programming technique, it has to automate it to some appreciable degree. C manifestly does not; it automates nothing but stack frames and register allocation. Every detail is hand-coded, with every opportunity to make trivial, hard-to-spot mistakes that nothing but exhaustive testing can bring to your attention.
OOP has 2 main features, which have first appeared in SIMULA-67: inheritance and virtual functions.
I agree with the following definition for OOP as as a special kind of programming with abstract data types:
"There are two features that distinguish an object-oriented language from one based on abstract data types: polymorphism caused by late-binding of procedure calls and inheritance. Polymorphism leads to the idea of using the set of messages that an object understands as its type, and inheritance leads to the idea of an abstract class. Both are important." (Ralph E. Johnson & Brian Foote, Journal of Object-Oriented Programming, June/July 1988, Volume 1, Number 2, pages 22-35)
When virtual functions are not used, the operations can be considered as belonging to the type (a.k.a. class), not to the objects, which corresponds to the jargon used by programming with abstract data types.
When virtual functions are used, the operations are considered as belonging to the objects, not to the class, as each object may have a different implementation of a given method. This corresponds with the point of view of OOP.
I have used the SIMULA/C++ term of "virtual functions", but in some OOP languages all functions are of the kind named "virtual" in SIMULA, so the "virtual" term is not used.
Once you separate type hierarchy and behavior, you get a much more flexible system. That's what newer languages (Rust, Swift and co.) do. I think the reason why "classes" are so popular has to do with compiler technology — type hierarchies can implement polymorphism very efficiently via vtables, and folks jumped on the opportunity of having high-level abstractions with high performance (instead of doing expensive lookups associated with earlier per-instance polymorphism). But as the compiler tech and understanding of programming language theory have progressed, these limitations are not necessary for good performance anymore, in fact, they become limiting.
The best thing in C++ is compile-time computation (ignoring the horrible template syntax). OO is not esp. well implemented.
- you have very few objects
- you have very few virtual functions
If you have a lot of objects or a lot of virtual functions, things will be less likely to fit in cache which will entirely destroy your performance, by an order of magnitude when compared to a mostly-always-branch-predicted indirection.
I remember experimenting with a an "inlined" version of std:: function and just having inlined the 5 ctor/move ctor/copy ctor/assignment operators was already slower than the vtable version when going through hundreds of callbacks ; imagine for something like Qt where QWidget or QGraphicsItem have 20+ virtual methods.
And despite this public visibility of the object's struct members granted to provide inheritance, the examples are still using getters and setters.
Ok...
("Free" after adding some metadata comments specifying parameter ownership/lifetimes, at least.)
2. Creating functions that take a pointer to the struct as the first parameter
3. Declaring a variable with that struct type to create an instance of the object
4. Declaring another variable with that struct type for another object instance
There are formal definitions of OO. The above satisfy exactly none of them.
For example, the formal definition of the Liskov Substitution Principal:
> Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T.
This doesn't allow any change in behavior when subclassing. Not even the addition of logging, which makes the overriding of methods generally useless. Yet languages still provide this feature (perhaps to their detriment, but they still do).
There's also a common definition of the Liskov Substitution Principal:
> Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
This is, generally speaking, what people are talking about when the mention the Liskov Substitution Principal, unless they're actively writing an academic paper on the topic.
Bringing up the academic definition when someone is using the common definition is 1. not relevant and 2. usually not helpful.
This is in fact, by any meaningful definition of OOP, is a very reasonable pattern. With regards to formal definitions of OO, message passing aspect ought to be recognised rather than overemphasizing the object aspect.
As an engineer, I'm never comfortable using something when I don't know how it works.
I wish more "introduction to OO" things would start by demonstrating a dispatch table and then showing how the vtable concept maps onto that, I suspect it would make things significantly clearer to a bunch of people as they learn.
It's like saying English doesn't have a built-in politeness pronoun, so if you need to be polite you can't use English.
As long as is not C++...
Of course, so is D...
If you need to implement virtual tables and function pointers, you'd use C++ - there's no need to reinvent the wheel.
Besides software engineering is about focusing on the intrinsic complexity, and using languages and tools to mitigate the incidental complexity.
It's just not worth it. Too much casting, too much scaffolding, much too brittle and error-prone. The experience is like "how much suffering can one endure."
It does, at least, facilitate micro management and burnout.
If they use "agile" as a noun, they generally have no idea what they're talking about and you should be careful.
Generally correct, but that's why you should only be "subclassing" abstract interfaces in the first place. Subclassing concrete object methods is a footgun, precisely because you have no way of enforcing which of these "properties" any code will actually be relying on, either at any given point in time or in the future. (Including code that's itself part of the base objects hierarchy and calling possibly-overridden methods, which means subclassing also breaks encapsulation!)
Concrete inheritance is very hard to make sense of semantically in the fully general case; if it's viable at all it is as a kind of mere specialization, and that's what the LSP is trying to get at.
But the point of the comment is the formal/common divide rather than the specific example.
Failing to match any of the formal definitions, as here, is a sure way to fail to reach a level where discussion is worthwhile. So, it is not, and I leave it here.
While other programming languages became mired in OOP dispute, opinion-battles, and all the ensuing problems[1], Perl 5's built-in OO is easy to learn and understand and makes the difficult things simple. It has been stable and effective for decades.
OO is just a pattern; it can be useful or misused, some aspects are more useful than others. But the defining goalposts are moved all the time. They tend to follow the hype machine.
[1] Members of the Perl community know that OO discussions have become harsh there too.
I'm pretty glad we've mostly standardised on the M* style these days, and Object::Pad (the cpan module that will likely eventually become the template for core OO) is still pretty familiar to users of that as well.
(the days before M* style became the default were ... "fun" ... though at least it meant we got native C3 MRO support added to the perl5 VM to support my decision to use a C3 based component model when I wrote DBIx::Class)
In my jitted ruby-like VM my methods are also copied, not referenced. Javascript also prefers copying the methods. This is usually called prototype-based OO. True prototypes copy the struct fields also, without creating classes, but copying the read-only methods only is a worthwhile OO optimization, C++ cannot do.
PS: WinUI apps use plenty OOP
As for the rest, OOP doesn't imply inheritance, BETA and SELF are good examples of OOP without inheritance.
My point is that when you develop an application, you only need strawman OOP i.e. calling methods.
You don't need class inheritance if you can pass functions as parameters, you don't need encapsulation given all your pieces co-evolve at the same time (if it's not split than part into a library).
That does necessarily not mean you are programming badly, although you might be. But restricting yourself to STL and smart pointers does very strongly resemble Java Disease. You might as well switch to Java.
Throwing Rust into the pool
If you want full control and easier interfacing with the OS, C++ is probably a little better, but Rust is definitely a little easier to work with once you learn the language.
The first OO language, SIMULA-67 became public knowledge before the start of even the PDP-7 UNIX, which is extremely unlikely to have used such a pattern, which probably appeared only when UNIX was rewritten in C, starting in 1973.
Even Smalltalk-72 predated the C-version of UNIX.
However, it is likely that this pattern was chosen in UNIX independently of the previous OO languages.
Hence why C++ got so fast adopted across UNIXes and C compiler vendors on other platforms.
But it was the reason that C, as standardized, adopted several C++ innovations first.
It's certainly a form of polymorphism.
This does not make any sense. People did not wait until someone gave a name to the rule-of-three to use it, and that does not make these uses any less rule-of-three than the ones that occured post-naming.
Also why Apple moved from Object Pascal to C++ on MPW.
Apple, particularly, was not strongly influenced by Bell Labs or UNIX. Apple A/UX–a UNIX for Macintosh, a niche product from that period–shipped without a C++ compiler. MPW in 1992 shipped without a C++ compiler.
Those were the ones that cared about C outside UNIX.
Bell Labs also had nothing to say to what happened to their code when they set it free.
And Zortech was one of the first vendors to move away from CFront.