Object-oriented programming

[MRZ 0]

I was just thinking -- OOP (Object-Oriented Programming) is considered to be THE programming paradigm and considers the design of software from the perspective that the world consists ONLY of entities. Isn't its correspondence with a rational epistemology the reason for its efficacy as a programming paradigm? Please note that here "efficacy" would mean not only an effective representation of the "world" but (as a consequence) of an individual programmer's ability to solve complex real-world problems and to handle large amounts of code.

A programming language serves two related purposes: it provides a vehicle for the programmer to specify actions to be executed, and it provides a set of concepts for the programmer to use when thinking about what can be done.

Any thoughts?

[Free Capitalist 0]

I don't know how far I'd agree with you that OOP increases efficacy of the programmer (although it does make learning programming a lot easier). Other languages are a lot more powerful than Java or C# without its plugins. Try programming raw sockets in an OOP language, for example, or even plain old TCP sockets. As far as I'm concerned, though, all programming languages are expressions of a rational epistemology.

[MRZ 0]

I don't know how far I'd agree with you that OOP increases efficacy of the programmer (although it does make learning programming a lot easier). Other languages are a lot more powerful than Java or C# without its plugins. Try programming raw sockets in an OOP language, for example, or even plain old TCP sockets. As far as I'm concerned, though, all programming languages are expressions of a rational epistemology.

←

Would you please eleborate a bit on your last statement? I'm not sure I understand.

What I meant was that the emphasis of OOP (regardless of the particular facilities provided by specific languages) on entities rather than processes makes programming a whole lot easier and larger programs much easier to manage. Do you think otherwise? If so would you please give me some examples? I didn't quite follow the bit about sockets, not having dealt with them.

[Capitalism Forever 0]

I don't know how far I'd agree with you that OOP increases efficacy of the programmer (although it does make learning programming a lot easier).

←

I beg to differ on both counts.

I would recommend a plain procedural language for learning, simply because it is simpler. The beginning student has to grasp a lot of new concepts, so his life will be much easier if he can tackle them one at a time. It's enough to introduce him to classes and objects after he knows all about variables, instructions, conditional branches, and loops.

OOP becomes useful when writing programs that are so complex that mental unit-economy becomes a concern and the programmer needs to model the behavior of his code in terms of objects and their attributes and actions. Hardly the kind of program you would make a beginner write, but definitely the kind that OOP helps you produce faster and with less mental effort--i.e., more efficaciously.

Other languages are a lot more powerful than Java or C# without its plugins. Try programming raw sockets in an OOP language, for example, or even plain old TCP sockets.

Well, there is the java.net package. Not surprisingly, though, most of the hard work in it is done by native methods, which are coded in C (or perhaps C++). Some code at the lowest level of your call hierarchy will always have to be written in a low-level language (which might be C, assembly, or even machine code). But once your high-level language is capable of calling this code, it is "in the power" of the high-level language to do what the low-level code does.

The idea is that it should be enough to write the socket-handling code in assembly once, and from then on be able to use it by writing something as simple as "new Socket(host, port)."

[RayVernagus 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!

[RayVernagus 0]

Try programming raw sockets in an OOP language, for example, or even plain old TCP sockets.

←

Microsoft's .NET Framework is an entirely OOP/Class-based framework. They have represented everything in their framework in terms of classes including concepts like sockets. This is a wonderful thing because it allows programmers to work with a nice, tidy abstraction without having to worry about all of the gory details involved in raw socket programming. That's the power of OOP.

[Free Capitalist 0]

without having to worry about all of the gory details

Ray, if we're talking about the efficacy of a language, i.e. what can be accomplished with it, then I'd say the languages who have the gory details can do more, by definition, by the presence of those gory details which can be changed around. OOP is a concept that leads to neat understanding and good programming without having to worry about those gory details, but in pure efficacy terms I wouldn't say it has complete efficacy. To make a drastic example, .NET isn't as powerful as Assembly.

[khaight 0]

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!

←

I agree.

The group I work in has an interesting OOP design standard we call "attribute-oriented design". One of its tenets is that all the public methods on objects should be nouns. Translated into the terms of Objectivist metaphysics, this is the observation that entities have attributes. Entities do not, on the other hand, have actions, and this is reflected in banishing verbs from method names. It works well.

(Parenthetically, I might dispute the claim that an Email object should have a send() method. An Email object, in my mind, consists of the message itself. An e-mail client would have separate objects that were MessageDispatchers. One type of MessageDispatcher might take an Email and convert it to an RFC820-compliant message directed to an SMTP server. Another MessageDispatcher might take an Email and use IMAP to upload it to a mail server for storage. A third might save the Email to a local folder, or an independent file. Etc. The relevant attribute would be something like:

MessageDispatcher::newEmail( Email * mail) {

...

}

But this is getting technical, so I'll drop it here.)

[Dufresne 0]

The group I work in has an interesting OOP design standard we call "attribute-oriented design".  One of its tenets is that all the public methods on objects should be nouns.  Translated into the terms of Objectivist metaphysics, this is the observation that entities have attributes.  Entities do not, on the other hand, have actions, and this is reflected in banishing verbs from method names.  It works well.

(Parenthetically, I might dispute the claim that an Email object should have a send() method.  An Email object, in my mind, consists of the message itself.  An e-mail client would have separate objects that were MessageDispatchers.  One type of MessageDispatcher might take an Email and convert it to an RFC820-compliant message directed to an SMTP server.  Another MessageDispatcher might take an Email and use IMAP to upload it to a mail server for storage.  A third might save the Email to a local folder, or an independent file.  Etc.

Why do you say that entities do not have actions?

What is the purpose of separating the actions performed by objects from the objects themselves? Suppose an email client distinguishes between HTML and plaintext emails. You have an abstract base class "Email" and two derived classes for HTML and plaintext mails. Suppose you want to implement a search feature and use polymorphism (virtual methods) to implement the search. What would be the advantage of creating new classes (e.g. HTMLEmailSearch and PlaintextEmailSearch) for searching different kinds of emails?

[MRZ 0]

OOP becomes useful when writing programs that are so complex that mental unit-economy becomes a concern and the programmer needs to model the behavior of his code in terms of objects and their attributes and actions. Hardly the kind of program you would make a beginner write, but definitely the kind that OOP helps you produce faster and with less mental effort--i.e., more efficaciously.

←

If you think about how you approach a problem domain using OOP, you are essentially using concept-formation.

That's exactly what I was driving at. That OOP models our own thought processes makes it a powerful tool for designing large software systems that would be too cumbersome to program in say assembly.

I'd say the languages who have the gory details can do more, by definition, by the presence of those gory details which can be changed around. OOP is a concept that leads to neat understanding and good programming without having to worry about those gory details, but in pure efficacy terms I wouldn't say it has complete efficacy. To make a drastic example, .NET isn't as powerful as Assembly.

While you're right in saying that assembly does provide one with complete efficacy over system resources, that assembly has its own advantages in terms of closeness to the system and/or size of code is a different issue. What I wanted to highlight were the advantages offered by OOP languages in terms of ease and accuracy of design besides easy maintenance/rework.

[Free Capitalist 0]

OOP models our own thought processes makes it a powerful tool for designing large software systems that would be too cumbersome to program in say assembly.

What I wanted to highlight were the advantages offered by OOP languages in terms of ease and accuracy of design besides easy maintenance/rework.

Well I completely agree then. OOP objects are a lot more intuitive and akin to our concepts (without actually being concepts themselves, of course) and thus greatly increase things like capacity for modular design, and our level of comfort in general. In fact I was told that at a certain university, in a computer class for non-majors they use this program which allows them to do programming entirely visually, just by moving around and manipulating objects on screen, and the program will generate the underlying code itself. That's pretty neat .

[Capitalism Forever 0]

Ray, if we're talking about the efficacy of a language, i.e. what can be accomplished with it, then I'd say the languages who have the gory details can do more, by definition, by the presence of those gory details which can be changed around.

←

Correct, although the efficacy of a programmer using a higher-level language can be greater when the "gory details" aren't mission-critical.

[khaight 0]

Why do you say that entities do not have actions?

My car does not have motion in the same way that it has wheels. Entities perform actions as a result of their interaction with the attributes of other entities. In attribute-oriented design, objects perform actions when their attributes are modified by other objects. Suppose I have an object representing a car, and I want to drive it forward at 60 miles per hour. A verb-centric approach might look like this:

car.moveForward( 60 );

In an attribute-centered design, this would look more like:

car.gasPedal( HALFWAYDOWN );

and the gasPedal() method would, based on the new position of the pedal, modify the velocity of the car as appropriate. I think the latter more accurately reflects the way causality works in reality, and thus winds up as a more intuitive programming model.

What is the purpose of separating the actions performed by objects from the objects themselves?

We aren't separating the actions from the objects. We're internalizing the actions to the objects. You make objects act by manipulating their attributes. But the actual action taken depends on internal state of the object which the caller may not know. (Carrying on the car analogy, suppose I'm out of gas. Pushing the gas pedal halfway down is still a valid thing to do, but the resulting action will be very different.)

[Dufresne 0]

My car does not have motion in the same way that it has wheels.  Entities perform actions as a result of their interaction with the attributes of other entities.  In attribute-oriented design, objects perform actions when their attributes are modified by other objects.  Suppose I have an object representing a car, and I want to drive it forward at 60 miles per hour.  A verb-centric approach might look like this:

car.moveForward( 60 );

In an attribute-centered design, this would look more like:

car.gasPedal( HALFWAYDOWN );

and the gasPedal() method would, based on the new position of the pedal, modify the velocity of the car as appropriate.  I think the latter more accurately reflects the way causality works in reality, and thus winds up as a more intuitive programming model.

Why should the object user be aware of the internal design of the car (e.g. the car could lack a gas pedal because it was built for people who can't move their legs)? Granted this is just an example and one could use a more abstract method like "car.accelerator(HALF);". But even then in both cases ("moveForward" and "accelerator") one would attempt to change an attribute of the car (its speed or the accelerator). In both cases the desired change could fail for various reasons. Quite frankly, the only difference I see is that one method name contains a verb, while the other does not. Or is there more to it? Would you say there is a difference between the two methods "car.speed(...)" and "car.gasPedal(...)"? Both method names do not contain verbs and both methods attempt to change one of the car's attributes.

[Dufresne 0]

Why should the object user be aware of the internal design of the car (e.g. the car could lack a gas pedal because it was built for people who can't move their legs)?

Additionally, I would say that the method call

car.speed(60);

is more abstract than the method call

car.accelerator(HALF); (or car.gasPedal(...); ).

Why should the object user care about the means of changing the car's speed? If something unexpected happens (like the engine is off or the car has run out of gas) then the method could throw an exception that could be caught by the object user.

[Dufresne 0]

Another thing: Suppose the software system later on has to deal with vehicles other than cars. Then one could introduce (if one hasn't already) an (abstract) base class like "Vehicle" with a virtual method for changing the vehicle's speed. If you had used a "gasPedal" method then you'd have to change every method call throughout the project because of a method name change...

[khaight 0]

Another thing: Suppose the software system later on has to deal with vehicles other than cars. Then one could introduce (if one hasn't already) an (abstract) base class like "Vehicle" with a virtual method for changing the vehicle's speed. If you had used a "gasPedal" method then you'd have to change every method call throughout the project because of a method name change...

←

A method like car.speed() would also be acceptable from an attribute-oriented design perspective.

I didn't really intend to open a full-scale debate on object-oriented design methodology. I just thought that the approach taken where I work had some interesting and unusual characteristics, so I mentioned them.

In my experience, the attribute-oriented approach has worked quite well. I'm sure there are other approaches that also work well; in software engineering there's usually more than one good way to solve a problem.

[Guest ElizabethLee]

A method like car.speed() would also be acceptable from an attribute-oriented design perspective.

I didn't really intend to open a full-scale debate on object-oriented design methodology.

←

hi KHaight! speaking for myself I would be greatly obliged to hear a full-scale chewing of this. If there are other threads on this topic, pls point me...

I've programmed for a while, but probably not well . Now I'm upgrading myself. If I offer confused muddled questions, please be kind! I'm happy to publicly admit to any amount of muddlement for the sake of increasing my cs learning curve velocity! Btw, I would like to manage projects/engrs at some point.

Oism tells me that my definitions and namings are crucial. I've thought a fair amount but haven't wrapped my arms around naming my items.

Here, speed() could be either noun/verb. The other choice, pushPedal, seemed like pure old-fashioned non-OO; did I miss something?

Before you posted I had thought (and read?) that all methods should be verbs. The thing I like about that is then it is clear usually by inspection that something is/not an object.

I like -visual- cues. I hate seeing those long java chains of calls that require complex parsing to figure out which calls are invoked from where. And though eclipse may be good [? thoughts?] I haven't used those environments much. So easy navigation helps a lot. I figure if I can get around manually, then eventually eclipse/etc will just make it turbo-charged. [right??]

Also, I'm -very- crow-limited. I think my personal crow is really around 3 LOL. So complexity really kills my reading comprehension.

Basically I like my names to tell their origins, quickly without fuss [i like to be able to know where to look for a definition & tracing]. So far, my 'rules' [if I recall!! I keep changing them when I think they're broken] I use, mostly from java work;

. k* for constants

. v* for variables that are local to a method

.variables that are important and local to the class confuse me. I wish to highlight them, but it seems better not to, ie no prefix. [methods at least have parens, so they're visibly different]

.except for i,j for loops, but if I use a j, I usually add a prefix: iPerson, jPhoneType

. vv* for input parameters.

.Nouns are classes

. present participle verbs are interfaces (and what's the name of that other thing like interface?)

. present verbs are methods.

Maybe a meta question is what is the purpose of naming in cs? And what types of names/categories are there? Do we have prepositions? conjunctions? past tense? I feel uncertain of the range of possible tools/programs I'll need.

this maybe gives a touch of my questions Please reply!

[Free Capitalist 0]

khaight, interesting suggestion. I think, however, that Elizabeth has hit the nail on the head here, that the ".gasPedal()" approach is considerably more abstract than ".speed()" or ".move()". I also don't understand the prohibition against verbs, as you could easily make it ".pushGasPedal()", or ".changeSpeed()", etc, without really modifying the design but making the structure easier to understand. I always try to include verbs in my object methods, because the object methods represent action, and we use verbs to express action in real life, thus bridging the link between the name of the method and the action it is intended to do.

So in general, I would disagree that OOP design should be attribute-oriented and attribute-driven, because as I said it's way too abstract, and yet at the same time paradoxically, relies too much on concrete real world examples to make any sense. Absolutely anyone can understand the idea of what ".changeSpeed()" does, but it is considerably more difficult to understand what ".pushPedal()" does. Is it a gas pedal? A break pedal? A flaps pedal in airplanes? A binary pedal in a simulator where degree of pushing is irrelevant? Etc, I would find the idea unworkable in my program. ".changeSpeed()" however is completely and directly obvious.

So, I would suggest an action-oriented approach instead.

Of course, as the program gets more complicated and you need a certain number of states to be met before initiating a procedure, speciflc attribute-affecting methods could do the job best. For a startup procedure for an airplane simulator, you could have:

airplane.draw();

airplane.resetFlaps();

airplane.resetInstruments();

airplane.setFlaps(35); // 35 degrees

airplane.pushGasPedal(FULL);

and then at takeoff,

airplane.collectGear();

airplane.cruise();

All of these would modify the attributes of the object 'airplane', but as you can see even the little sub-steps are each itself action- rather than attribute- driven.

[Free Capitalist 0]

Oh and I forgot to add, the reason to use "pushPedal()" instead of "setSpeed()" is because the former constantly modifies the speed as the plane accelerates, whereas the other sets a constant speed. So the former method could call the latter a number of times, and there's still no conflict between the two.

The main point of the design would be orientation of the object- and method- design there towards action, either initiating the action by itself or collectively contributing to an action in conjunction with other method calls.

[Dufresne 0]

I didn't really intend to open a full-scale debate on object-oriented design methodology.  I just thought that the approach taken where I work had some interesting and unusual characteristics, so I mentioned them.

I was interested in attribute-oriented programming when you mentioned it and at the same time a bit skeptical. Sorry if I came across as too aggressive.

[Ed from OC 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.

[RayVernagus 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'd be interested in learning more about this theory. The two guys that are generally listed as the inventors of OOP (see Yahoo and WikiPedia) did so in the early 1960's. To the best of my knowledge, Introduction to Objectivist Epistemology wasn't first published until 1966.

[RayVernagus 0]

Ray, if we're talking about the efficacy of a language, i.e. what can be accomplished with it, then I'd say the languages who have the gory details can do more, by definition, by the presence of those gory details which can be changed around.

←

First of all, we aren't being technically correct in calling programming languages object-oriented. OOP is a method of development that is either supported or not supported by a specified language. You can get at all kinds of gory details in C# when necessary just as well as you can just call the Socket class in the .NET Framework. Object-oriented languages in-and-of-themselves don't preclude you from doing things like this.

When it comes to efficacy, however, I think it's pretty clear why OOP is the choice of anyone not dealing exclusively with machine code or pointers. 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. Both chunks of code do the exact same thing it's just that with an OOP implementation we're doing with one line of code what we would otherwise have to do in ten.

Sure, an OOP framework is going to hide all kinds of behind-the-scenes details but that's exactly why the technique is so powerful. I see your point but I think we're just talking about different senses of efficacy.

[Dufresne 0]

Oism tells me that my definitions and namings are crucial.  I've thought a fair amount but haven't wrapped my arms around naming my items.

A couple of things to consider:

(1) The length of an identifier (name of a type, class member, variable, constant, etc.):

The shorter the identifier the less you have to type. In modern development environments (IDEs) this is less of a problem because they offer name completion. When you start typing in the name they offer you a list of options that are meaningful in the given context (let's say you have typed in "sp" then the IDE might give you a list of methods that includes "speed" and "space").

More importantly, the identifier should be short enough to fit into your mind during thought. The method name "readConfigurationFileAndStoreTheResultsInTheProjectSettings" might give you a good idea of what the method is going to do but it's very difficult to use it when you are thinking about the problem you want to solve. When you feel the need to choose a long name, it might be a good time to reconsider whether you should use multiple methods instead of one:

class ConfigurationFile
{
  void Open(void);
  void Read(void);
  void Save(ProjectSettings settings);
  void Close(void);
}

Then, even better, you can create another method that calls the above methods in the right order:

class ConfigurationFile
{
public:
  void LoadProjectSettings(ProjectSettings settings)
  {
    Open();
    Read();
    Save(settings);
    Close();
  };
private:
  void Open(void);
  void Read(void);
  void Save(ProjectSettings settings);
  void Close(void);
}

ConfigurationFile cf;

cf.LoadProjectSettings(_projectSettings);

This is more work at the beginning but can quickly pay off when you are adding more functionality to your ConfigurationFile class.

(2) Methods that return a boolean value or boolean variables should be named in such a way that their usage supports reading comprehension:

if (sun.isShining()) { ... }

reads better than

if (sun.Shining) { ... }

(3) Names acquire additional meaning through their scope. In a method "PrintEmployeeName", a parameter for passing the employee's name doesn't have to be named "EmployeeName". "Name" would be sufficient if it's clear in the given context.

Basically I like my names to tell their origins, quickly without fuss [i like to be able to know where to look for a definition & tracing].  So far, my 'rules' [if I recall!!  I keep changing them when I think they're broken] I use, mostly from java work;

. k* for constants

. v* for variables that are local to a method

.variables that are important and local to the class confuse me.  I wish to highlight them, but it seems better not to, ie no prefix.  [methods at least have parens, so they're visibly different]

.except for i,j for loops, but if I use a j, I usually add a prefix:  iPerson, jPhoneType

. vv* for input parameters.

Personally, I use the prefix "l" for local variables, "g" for global variables (which I use very rarely) and "f" or "_" for class members (depending on the language I am using, the former in Pascal, the latter in C++). The reason why I'm using a prefix for class members is that they can be easily distinguished from similarly named constructor parameters.

present participle verbs are interfaces (and what's the name of that other thing like interface?)

What are present participle verbs and why do you use them for interfaces? Another thing like interface? An "abstract base class without members"?

Maybe a meta question is what is the purpose of naming in cs?

What's the purpose of naming people?