Hi! I'm a casual C programmer (really a hobby, so no deep knowledge or whatever), and I'm trying to get into OOP (looking at both ObjC and C++). Everything I read says that "the beauty of OOP is that everything is an object, thereferore you can reuse them in other program" or something similar. What is so different? Can't you reuse functions and data structures from C as well? Aren't they as good as fundamental building blocks for programs?

I just don't get the fundamental difference between the two, and would prefer to really understand the basic concepts before diving into it.

Thanks!

[DaGuy]

OO is a whole different way of thought. Procedural tends to hide some complexity behind function calls and subroutines; despite these helpers, you are pretty much thinking linearly -for OO you may benefit from thinking of it as a network of agents. OO is sort like creating die cast (class) from which to create these well-defined robots that have a solid sense purpose and know how to talk and listen to other robots. You could do something like that in a procedural language but it is not designed out of the box to accomodate or leverage the latter "networked" way of thinking.


One thing to keep in mind is that OO could be overkill for many programming tasks. For example, If all you need to do is draw a simple X-Y graph, then a procedural language may be the wisest solution. On the other hand if you are thinking of extending the graph with a user interface and have it publish to the web, then a procedural language will likely be suboptimal.

There is a ton of good books out there -even Apple has some good intros in their Cocoa tutorials.

[This message has been edited by DaGuy (edited 05-27-2001).]

I'm really not sure I understand your point, but I think the idea will probably "sink" into me while reading/practicing.

Thanks anyway!

[DaGuy]

Sorry, I didn't get through. Keep reading, OO will make a lot of sense at some point.

[mr_sonicblue]

It's hard to explain. But, in object-oriented programming, you are allowed to encapsulate both data and functions into logical, self-reliant groups (classes). The data in those groups can be shared between the functions, or in single functions. But, the data is kept within the group, and does not conflict with data anywhere else in the program. But, in procedural languages, the data is either directly accessable by ALL functions, or one function. There is no logical grouping of functions and data. It is all mixed together.

But, more importantly, those groups can be created dynamically while you program is running (objects). Imagine, you can create a large amount of data, and all the functions that act upon that data, as a single, singularly managable object. It can be created, and destoyed, all at once, with ease.

As an example of this, consider strings. In a procedural language, all the functions that act on strings are left out in the open. You can, essentially, attempt to pass any type of data into a string function, because there's nothing keeping you from doing so:

int a=5, b=2;
bool c=bigger_string(&a,&b); // This shouldn't happen. It's not logical.

But, in a object-oriented language, all the functions that act on strings are stored in the string object itself:

String name("Eric"); // Declare string object, and set initial value
name.ucase(); // Capitalize string

There is no way for that ucase() function to act on any other data except the string stored in that string object. That is how it should be. But, notice how you have to interact with the object itself to affect the object. This is very important. You can tell the object what to do, and it will do it itself. It keeps track of all the data necessary to do its job. It is self-reliant. Because of this, many objects can be declared, and used together, in an unpredictable way, and none will be able to hurt another in any way.

For instance, in a program I recently made, I had a file-outline which contained folders which could contain any number of other folders and files. Each file and folder contained the same basic set of functions. Because of this, each folder could manage any number of files and folders (which, themselves, could maintain files and folders, and so on) transparently, not knowing which was which (because it does not matter to the object's manager). All the files and folders are managed by the objects above them in the hierarchy. The outline itself only manages the root folders. This causes a great deal of automation across the entire outline. Although it sounds complicated, it takes little programming to establish this system. You only have to program each object (three in this case) once. But, they may be used hundreds of times while the program is running. This is essentially impossible in procedural languages.

The most common way of think of this is a factory. You draw (program) the blueprints (classes) for the objects to be used in your program. Then, your program is simply a factory, churning out objects that cause the program to do what it does.

------------------

[ryochiji]

There's nothing OO can do that can't be done in a procedural language. OO is just a logical extension of procedural programming, and makes life easier in many ways.

In a procedural language, if you have an array or linked list of a struct (or records, in Pascal), and have functions for working on those structs, what you have is already pretty darn close to an OO-model. I think if you spend a lot of time coding in a procedural language, you begin to develop an "object oriented" way of thinking simply because it's a logical, cleaner model.

That's also the reason why I'm personally against recommending people to learn an OO language first. I don't think it'll make enough sense, and an object oriented spaghetti code is about as bad as it gets.

[sadie]

Certainly, OO will only start to make real sense once you begin to use it. Even the simple tutorials will seem make it pointless, but when you start moving onto bigger projects it'll start to make sense.

I agree that "There's nothing OO can do that can't be done in a procedural language.", but that statement ignores the point of OO: to make life easier to understand. Humans aren't designed for handling large amounts of detail. In a procedural language, as your project gets bigger you have to keep all these new details in your head.

In an OO language, you hide some of the information within certain classes, and then use those classes without needing to think about it. The hidden information can be forgotten about safely, so you can keep a clear head while programming. This makes managing big projects a lot easier.

If you're going to learn OO, make sure you start with a good language, preferably not C++. It's famous for teaching bad habits. I learnt on Java, and I'd recommend it as a fairly good teaching language.

If you want a procedural language to learn first, go for C. It's the most influential language around today, and will help with Java.

Well, thanks for all of this! I understand a little what the point is all about.

I already know C, and I wanted to get further. Since I was getting OS X soon, I thought ObjC was a good idea, along with C++. But I don't have OS X yet, and you say that C++ should not be started with for OOP. Maybe Java is a better choice. But every language as its advocates/detractors. So I've learned plenty of bad things about Java. But it must not be THAT bad Anyway, I have a book about Java, so I'll switch the C++ one for now!

Thanks!

[danengel]

Learn assembly language! It's the only way to learn REAL programming :-)

just a joke...

[sadie]

What book?

[sadie]

What book?

[starfleetX]

Originally posted by Biron Maiden:
<STRONG>I already know C, and I wanted to get further. Since I was getting OS X soon, I thought ObjC was a good idea, along with C++. But I don't have OS X yet, and you say that C++ should not be started with for OOP. Maybe Java is a better choice. But every language as its advocates/detractors. So I've learned plenty of bad things about Java. But it must not be THAT bad Anyway, I have a book about Java, so I'll switch the C++ one for now!</STRONG>

I've tutored beginner students in Pascal, C++, and Java and I'd strongly recommend you to learn with C++. Just remember that Obj C is an extension of C and that, IIRC, you can use older C and C++ styled code in it as well. I haven't done this myself (I'm trying to keep focused on just Obj C), but I think it's pretty easy to do. The Java bridge, however, is another story altogether from what I've seen.

Well, mr_sonicblue covered about everything else I was thinking of posting about too. Great post SB!

[Angus_D]

Originally posted by starfleetX:
<STRONG>I've tutored beginner students in Pascal, C++, and Java and I'd strongly recommend you to learn with C++. Just remember that Obj C is an extension of C and that, IIRC, you can use older C and C++ styled code in it as well.</STRONG>

No, you can mix and match C and Obj-C but not C++ (yet, that needs the Obj-C++ support in the compiler, which is coming, but not there yet)

[Wixar]

Biron is right. I think the reusability advantages that you get with OO are overstated, and the same is true for encapsulation and data hiding. We use both all the time in C: consider opaque Toolbox data types like aliases, WindowRef's, Handles, etc. Even basic procedural entities like allocated memory use them: that's how the free function can know how much memory to deallocate from just the pointer to the data.

Consider a standard Toolbox function like MoveWindow. The standard (procedural) way you'd call it is like this: MoveWindow(theWindowRef, xCoord, yCoord, inFront). In a OO language, you'd have this instead: theWindowRef-&gt;MoveWindow(xCoord, yCoord, inFront). Not much of a difference, is there?

I don't mean to imply that OO doesn't get you anything. One aspect of OOP that hasn't been brought up yet is polymorphism. Polymorphism essentially means pushing the decision of what code to execute from compile time to runtime. This lets you cut out a whole bunch of if and switch and other types of branches because the runtime environment does them for you, so your methods (err, functions) can be shorter than they would be in a procedural language. Highly dynamic languages like Objective-C get you even more: you can write fewer methods. For example, I have a single method that returns either a string or an attributed string; with C++, I'd have to write two different methods to do the same thing.

Alan Kay, the guy who coined the term "Object Oriented," is said to have regretted his choice of words, because they put the focus on objects instead of on messages, where he felt it belongs. Messages are like polymorphism on steroids: not only is the code to be executed chosen at runtime, but the types of code that can be executed can be quite different. For example, messaging lets you do things like cache function calls and all their parameters and invoke them later, or log them to a file for debugging, or wrap those messages up with their parameters and send them to an object located in another thread or another process or another computer. It's very awkward to do that sort of thing with either a procedural language or a non-dynamic language like C++.

That's enough ranting for now. This debate seems to pop up everywhere.

-Peter

[aleph_null]

MHO...

OOP languages are more programmer-friendly, in general. Granted, some (ie, C++) are higher-maintenance programming partners, if you will, than others (ie, Java). But doing more work for you and being more friendly is a good thing, because when programming environments are more friendly, programmers are less prone to write bugs, and are better able to be productive. This is OO's big win, I believe.

There's nothing computable with C++ or Java that's not computable with C, assembly, or a tape-based Turing Machine. All the layers sitting on top of the CPU's register switches and RAM, from the ISA, through malloc and fopen, which may sit underneath some graphical view hierarchy, which is then used to implement Photoshop's GUI ... all these are convenient abstractions or specializations, designed so that the computer is more usable. Unless it's a Microsoft product, of course.

So OO languages give you more intuitive, useful tools than procedural languages. You could use just the pencil tool to blur a photo, but Photoshop's filters are much faster and easier, and less prone to user-error. Polymorhpism and run-time type information, as mentioned, are great improvements over switch statements and enums. I'll add class hierarchies to the list. With hierarchies you can model real-world problems using intuitive concepts, so your code maps well into the problem domain. Writing and debugging is easier. Hierarchies also allow you to re-use code but also override specific parts to implement behaviors you need. Less code -&gt; fewer bugs.

ramble ramble...

[honeydew]

Well said, aleph_null.

[3.1416]

I've tutored beginner students in Pascal, C++, and Java and I'd strongly recommend you to learn with C++.

Although I don't have much experience teaching others, I'd have to disagree. C++ is a mess: confusing syntax (e.g. "virtual", reference parameters), no memory management, poor introspection and dynamic messaging capabilities. For beginners I would think Java is a much better choice.

Just remember that Obj C is an extension of C and that, IIRC, you can use older C and C++ styled code in it as well.

You currently can't mix ObjC and C++ code in the same source file, but Apple is working on removing this limitation.