Object-oriented programming

[Dufresne 0]

Efficacy in programming deals with how much can be accomplished by a given number of lines of code. Clearly, OOP is more efficacious in this sense. One line of object-oriented code might be mySocket.Open() whereas in C you might write ten lines of code. I don't even want to think of the equivalent in (God help me!) assembly.

Believe it or not but I've heard people say that huge programs should be written in assembler for the sake of efficiency and size. It's as if they completely ignored other limited resources like money and time. Imagine how much money and time it would cost to write an operating system like Windows XP in assembler!

[Stephen Speicher 0]

I heard several years ago that the originator of the OOP concept was an Objectivist or at least directly influenced by Ayn Rand's philosophy.  I'm afraid I don't remember more details.

←

I do not know about the originators, but the following has been posted on several lists before.

At first glance, Perl and Oracle seem like strange bedfellows, so how can they be linked so well to each other? We think there's is perhaps even a philosophical link stretching between Perl and Oracle, all the way back to Aristotle and Athens, the first state in the world to champion the rights of the individual. This link, we believe, is "Objectivism."

See this link for the full reference.

[HeroicLife 0]

As Ray pointed out, object oriented programming is a method, not a just language implementation. In fact, it is possible to use object oriented programming methods in ANY high-level language (including C and Pascal) – but some languages support it to a better extend than others. Likewise, it is possible to use entirely procedural programming in a object-based language, though it annoys me to no end when my coworkers do so.

Also, it’s important to distinguish between the properties (nouns) and methods (verbs) of objects. The key difference is that methods change the state of an object, while properties do not.

There have been a number of good and bad ideas on naming mentioned in this thread. I would like to recommend a great book on proper naming and structure (and much): Code Complete by Steve McConnell. Anyone who wants to be a great programmer HAS to read this book, as well as one on design patterns in your preferred language.

[Mercury 0]

I think one could make a great case for how understanding Objectivist Epistemology can make you a better OOP programmer. The understanding gained from studying the nature of concept-formation makes you a better abstractor and this, in turn, makes you a better OOP programmer.

If you think about how you approach a problem domain using OOP, you are essentially using concept-formation. For example, if you are creating an e-mail program you will ask yourself the question, what do all e-mails have in common? You answer this question by looking at all of the concrete instances of e-mail: text, HTML, etc. Then you abstract away from the differences and create a common object that suits all of these cases. Ahhh! All e-mails must have a Send() method.

A proper epistemology is essential to object-oriented programming. Bad abstractions lead to bad programs. I see the manifestations of bad epistemology all over the place in the software that I deal with and it ain't pretty!

←

Another student of Objectivism who works as a software engineer set my mind in this direction a few years ago. I have thought about the connection many times since then, but it wasn't until last year that the issue became really clear to me.

Bruce Eckel, author of Thinking in Java, whether he knows it or not, eminently clarifies the link between a rational (abstraction-forming) epistemology which needs to solve real-world problems and an engineering framework which aids this epistemology:

All programming languages provide abstractions. It can be argued that the complexity of the problems you’re able to solve is directly related to the kind and quality of abstraction. By “kind” I mean, “What is it that you are abstracting?” Assembly language is a small abstraction of the underlying machine. Many so-called “imperative” languages that followed (such as FORTRAN, BASIC, and C) were abstractions of assembly language. These languages are big improvements over assembly language, but their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re modeling that problem, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” which is the place where the problem exists). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.

The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems are algorithmic,” respectively). PROLOG casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches is a good solution to the particular class of problem they’re designed to solve, but when you step outside of that domain they become awkward.

The object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space. This representation is general enough that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as “objects.” (You will also need other objects that don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you read the code describing the solution, you’re reading words that also express the problem. This is a more flexible and powerful language abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run. There’s still a connection back to the computer: each object looks quite a bit like a little computer—it has a state, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad analogy to objects in the real world—they all have characteristics and behaviors.

[All emphases added.]

[Mercury 0]

At first glance, Perl and Oracle seem like strange bedfellows, so how can they be linked so well to each other? We think there's is perhaps even a philosophical link stretching between Perl and Oracle, all the way back to Aristotle and Athens, the first state in the world to champion the rights of the individual. This link, we believe, is "Objectivism."

←

Eckel also gives Aristotle the recognition he deserves:

Aristotle was probably the first to begin a careful study of the concept of type; he spoke of “the class of fishes and the class of birds.” The idea that all objects, while being unique, are also part of a class of objects that have characteristics and behaviors in common was used directly in the first object-oriented language, Simula-67, with its fundamental keyword class that introduces a new type into a program.

[...] Creating abstract data types (classes) is a fundamental concept in object-oriented programming. Abstract data types work almost exactly like built-in types: You can create variables of a type (called objects or instances in object-oriented parlance) and manipulate those variables (called sending messages or requests; you send a message and the object figures out what to do with it). The members (elements) of each class share some commonality: every account has a balance, every teller can accept a deposit, etc. At the same time, each member has its own state: each account has a different balance, each teller has a name. Thus, the tellers, customers, accounts, transactions, etc., can each be represented with a unique entity in the computer program. This entity is the object, and each object belongs to a particular class that defines its characteristics and behaviors.

[Emphases original.]

[Guest ElizabethLee]

hi everyone!

Thank you for posting! I am printing these out & will reply later

I would like to recommend a great book on proper naming and structure (and much): Code Complete by Steve McConnell.  Anyone who wants to be a great programmer HAS to read this book, as well as one on design patterns in your preferred language.

←

I'm in the middle of it!

For patterns I'm not sure if I have the right book yet.

[RayVernagus 0]

For patterns I'm not sure if I have the right book yet.

←

The book on design patterns is the Gang of Four's, Design Patterns: Elements of Reusable Object-Oriented Software. If there's a "right book", that would have to be it. But there are plenty of other very worthy titles to be sure.