Who needs C++ to write OO Code

[TheCPUWizard]

The goal of this topic is to highlight the fact that C++ (and other languages) provide an environment to facilitate the implementation of OO concepts, but that these concepts can be implemented in any language that provides the programmer with sufficient granularity of control [notably straight C]

In Order to even start a discussion on this topic, we need to define what "Object Oriented Programming" really is. Of course the simplest answer is "Programming that is Oriented towards dealing with Objects" ;) It may sound silly, but it actually points out a number of key points. The first is that we will need to decide that an "Object" is. The second is that is does NOT mean that any specific construct or syntax or capability is required! I am going to cover the second issue first.

People often focus on such terms as "Function Overloading". The reality is that functions per se are not even required! Consider "human" languages. The vast majority of current languages are based on alphabets with are grouped into words. But this NOT a requirement for a language! Any mechanism which is understood and agreed upon can be used as an implementation basis. Of course an "easier" mechanism will usually be adopted over a "difficult" one, but even here there will be exceptions if there are special needs.

Turning to the definition of an "Object", we can begin by saying an Object is a "Thing". Again using human languge (english) as a reference point, this will typically map to a Noun. Things can be described by features they possess [Adjectives] and actions that they perform (or actions that are performed on them) [Verbs]. We also realize that there are relationships between various types of objects and that understand these relationships are important in dealing with them.

As a final point in this post, I want to make sure that the difference between "Object Oriented Programming" and an "Object Oriented Language" is understood. The latter is a tool that will help promote the former. These languages will often have specific features that provide a context that is easy to implent and understand. I am often reminded of old comedy skits where one person (speaking a foriegn language) utters words (or at least sounds) for a fairly long period of time, the second person (speaking the listeners tongue) asks "What did he say?", the third person (again speaking in the listners tongue) responds "He said 'Yes'". The consiseness or verbosity of a tongue does not define its validity.

Hopefully this will evolve into a lively discussion (and not a spitting contest) that will allow readers of all experience levels and backgrounds to gain some insight.

[panayotisk]

I consider polymorphism to be the most important benefit of OO design and programming. Implementing the virtual function mechanism using straight C would require hard work...
An OO language facilitates the implementation of OO concepts (polymorphism, encapsulation, e.t.c. - which are becoming generally acceptable as beneficial) as you already said...

[TheCPUWizard]

Thanks for the Post :) It brings up a number of good points that I would like to cover.


I consider polymorphism to be the most important benefit of OO design and programming. Implementing the virtual function mechanism using straight C would require hard work...


Lets look at this further....

polymorphism - the quality or state of being able to assume different forms.


In context of OO programming, the most common meaning of this is that the effects of an action are dependant on the run-time type of the object being acted upon. In C++ this is implemented as virtual functions.

My next (planned) post on this thread will cover various means of achieving this, looking back at techniques that date back to the mid 1970's and looking forward to some C++ template abilities that are now just coming into common use.


Finally....

An OO language facilitates the implementation of OO concepts

Here we agree. I was very careful when I created the title for this thread, specifically the word "Need". There are a great number of reasons why you WANT and OO language to implement the various concepts [who likes to do extra work]. If you factor in "real world requirements" such as Time Constraints, Budgets and the like, the choide of language used to express the concepts can easily make the difference between success and failure. And I will easily conceed that success is a "need" ;) , albiet not a technical one.

Look at so many things in the world. You will quite often hear "I could not survive without ...", yet people did for centuries or longer. So many technologies are taken for granted by the masses, that they have no understanding of how they work, or why. This is becoming increasingly common in the computer field and [IMHO] resulting in software that is disctinctly less than optimal in most cases, and downright bad in many.

When computer resources were slow, expensive and scarse [pre 1980 as a rough point] and tools were fairly limited [most coding done in assembler], programmers NEEDED to understand the detailed operations of the CPU, they had to understand how every peice of data was represented by the hardware and how if flowed from memory to registers to output devices.

Various tools were developed which helped the programmer to not have to explicitly code each of these steps, but proper usage of these tools DID require an understanding of the process or the results were so dismal as to be completely useless.

Fast forwarding twenty some odd years, the hardware capabilities have increased tremendously and so have the expectations of what the computer "should" do. These expectations could not possibly physically [much less cost effectively] be met without corrrespondingly advanced tools. My contention is that blind usage and dependance on these tools, without a through understanding of what they do, how they do it, and why we want them to do it is just as disasterous.

...until next time...

[cloureir]

Interesting post, thanks :)

>>Various tools were developed which helped the programmer to not have to explicitly code each of these steps<<

I think these are called abstractions. A good example could be a grid/table. In modern languages you just invoke it and definen the source, i.e. from which table(s) you are going to populate the grid. Before you had to "draw" the whole thing. Another example is memory management, with modern languanges people don't worry about garbage collection.

The concept of objects help the creation of asbtractions. I have developed business applications, actually I worked at a university. Once I developed an application to register students in modules. The application invoked objects/methods from the financial system (to charge students for each module). As an analyst I only knew in detail about the functionality of the academic records, and new very little about the financial accounts and so... For me those were abstractions... I gave them the code of the module and they charged the student accordingly, I didn't know what happend inside.

But, as you say >> proper usage of these tools DID require an understanding of the process or the results were so dismal as to be completely useless.<<
eventually I had to learn more about the hidden functionallity to be able to fix problems when the programmer of the financial system wasn't available.
:wave:

[cloureir]

we used centura builder by the way... a semi-OO tool. It wasn't the big thing but helped us save time.

[spoulson]

I consider an 'object' to be a container of any number of related data. In C, this could be as simple as a struct or a plain data type. But the container is a very open ended term. Could it be an array? A linked list? Array of pointers to data?

The fact that C++ gives you member functions, virtual, interfaces, operator/function overloading, etc. is just a nicety during development.

Compare with how Perl 5 does OO. Perl can create packages (aka classes) with member data and functions, but it handles it much like how you'd probably do it in C. The new method alloc's the memory required by creating a hash ref. The ref that is returned points to the member data like so:
$object->{mydata} = "some text";

When you make method calls to a Perl object, it always puts the object pointer as the first argument to the function. i.e.:
$object->myfunc("abc");
translates to:
ObjectClass::myfunc($object, "abc");

This is interesting because in Perl you can still call the method like a static function using the second syntax and leaving out the $object parameter. The function just needs to be smart enough to detect the first option isn't a reference to the package (class).

Anyway, I bring this up because it's a slightly different way of thinking of OO than C++, Visual Basic, etc. It's more hands on, like C. i.e. Win32 API uses handles for a number of things; handle == object.

Most people will agree C is not an OO language. But this is wrong. My argument is that OO is a concept, not a language type. I could write assembler code to interface with C++ objects, though a lot more difficult.

[TheCPUWizard]

Spoulson, thanks for the comments, this is the point I was tring to make. I was hoping this thread would develop into a lively discussion on the concepts and implementations that are possible in various languages.

The only statement I take some issue with is:

I consider an 'object' to be a container of any number of related data.

I would restrict the definition to any container that is capable of holding both data and methods [often function pointers]. If you can not encapsulate behaviour then you really loose the concept of an object. Kind of like a (human) language with nouns but no verbs.

[spoulson]

I would restrict the definition to any container that is capable of holding both data and methods [often function pointers]. If you can not encapsulate behaviour then you really loose the concept of an object. Kind of like a (human) language with nouns but no verbs.

On a very strict interpretation, who says an object needs to have methods? The methods/properties make an object more complete, such as to encapsulate the work, but IMHO isn't required in order to be an object. A struct full of ints or other simple data may not need methods.

[TheCPUWizard]

It is the combination of methods and content in a single entity that forms the whole masis for object oriented design. If you eliminate this you are basically left with the principles of structured programming.

It is the philosophical differences that drive the mindset and therefore the entire approach. Consider what would happen to most spoken languages if the exactmeaning of a verb was not altered by the type of noun it was referring to!

While I agree that from a practical point of view, not every object needs methods, a common design guidline is that the number of methods should be 2x-5x the number of properties for most objects at the top level of a design!