I am asking this out of ignorance. I program in simple languages (basic. pascal, javascript), but have often wondered whether I should try and learn C++ or java. Is there anything that OOL can do that I can’t do in basic using arrays etc, even if not so neatly?
I could expound at great length on this, and I’m certain others will, but I think we need to focus on what you are really asking. Which, I think, is - should you learn these languages in the first place?
The answer is - do your existing languages that you program in do everything that you need to do? If so, then don’t be overly concerned about their features and so forth.
Procedure oriented languages get old about the hundredth time you realize that, yet again, you forgot to put in the call to some obscure cursor shape handling function in that new window you tacked on because the users were begging for new features. Had you used a window object, it would have inherited its cursor control automatically.
Objects make it easier to create programs that implement the standard conventions of a complex visual interface.
scm1001
I’m going to go even a step further generalized than Squink’s answer did.
What’s good about Object Oriented languages (My opinion at least 
)…
The whole idea behind the advances in programming languages is the same as advances in anything else… faster, stronger, more reliable.
In the languages you’ve listed that you work in, things get more reliable the more you compartmentalize them. Smaller procedures that perform very definite tasks are a lot easier to debug than one huge program with branches and looks leading you on a wild goose chase every time you try to figure out what’s not working.
OO languages give you one step further on that compartmentalization… but from my perspective, the biggest selling point isn’t in the first program you write in OOL, but really kicks in around the 10th or so. Because you end up creating a whole library of frequently used objects and routines that you know work, you’ve debugged to death and you can depend on.
No more reinventing the wheel. (well, ok, less of it, since most programmers can always think of something they can improve… )
So that’s my answer to your headline… and to your question about is there anything you can do in OOL that you can’t do in non OOL languages… yep, there are, inheritance and polymorphism are wonderful things once you get a real understanding of them
And of course Anthracite hit the nail squarely on the head as to whether or not you should go learn these langages in the first place, so I won’t duplicate that. 
-Doug
In addition to the general OO benefits (inheritance, etc.) Java is really easy to learn, there are lots of resources on the web, and the standard classes and methods that come with java are extensive and useful. You don’t have to write every algorithm from scratch, there’s a lot to build on.
For OO selling points in general, I suggest you get a book on the subject, there are lots of them.
My two cents: object-oriented languages are beneficial because they let you “bundle” the data (attributes) and operations (functions) for whatever you’re modelling/manipulating.
If I’m writing a program to manage an employee database, for instance, I can define an “employee” class which contains all of its attributes and all of the operations that can be performed on that class, and I don’t have to waste time making sure a particular function has all of the related data it needs to perform an operation. You get some similar functionality in non-OO languages with structures, but keeping several different structures associated with the same record is the programmer’s responsibility.
There are lots of other benefits of object-oriented language, but this is one of my favorites.
From a more conceptual standpoint… one benefit is that OOP makes it easier to deal with related data types which need to be handled slightly differently.
Suppose you’re writing a server program, and users can log in either from a network, a serial port, or the console. You’re going to be doing the same operations for each type of user (read text, write text, close the connection), but the way you do them will be different. You’ll also need to store different information for each type - network users need a host address and port number; serial users need a serial port number, baud rate, etc.; console users need no additional information.
In regular Pascal, you’d use something like this:
{ one record for all user types, with a type marker field and
a variant part to hold different user types' data }
type
TLoginType = (ltNetwork, ltSerial, ltConsole);
TUser = record
{ common fields go here }
case LoginType: TLoginType of
ltNetwork: (Host: Longint; Port: Smallint);
ltSerial: (SerialPort: Byte; Baud: Longint);
end;
{ one function to write to a user, which behaves
differently based on the user's type marker }
procedure WriteToUser(const User: TUser; const
Text: string);
begin
case User.LoginType of
ltNetwork: net_send(User.Host, User.Port, Text);
ltSerial: ser_send(User.SerialPort, User.Baud, Text);
ltConsole: Writeln(Text);
end;
end;
{...}
var SomeUser: TUser;
InitializeConsoleUser(SomeUser);
WriteToUser(SomeUser, 'hello');
In Object Pascal, you’d use something like this:
{ base class to represent all users }
type
TUser = class
{ common fields/methods go here }
procedure Write(const Text: string); virtual; abstract;
end;
{ derived classes for each user type }
TNetUser = class(TUser)
Host: Longint; Port: Smallint;
procedure Write(const Text: string); override;
end;
TSerUser = class(TUser)
Port: Byte; Baud: Longint;
end;
TConUser = class(TUser)
end;
{ different implementations of the same method
for each user type }
procedure TNetUser.Write(const Text: string);
begin
net_send(Host, Port, Text);
end;
procedure TSerUser.Write(const Text: string);
begin
ser_send(Port, Baud, Text);
end;
procedure TConUser.Write(const Text: string);
begin
Writeln(Text);
end;
{...}
var SomeUser: TUser;
{ a variable of the base class type can point to
an object of any derived type }
SomeUser := TConsoleUser.Create;
{ a call to a virtual method invokes a method implementation
based on the object's actual class type (TConsoleUser) }
SomeUser.Write('hello');
What are the advantages of the OOP approach?
[ul][li]Each user object only uses as much memory as it needs. The non-OOP code must allocate as much memory for each user as the largest possible type (network user), even for console users who don’t need any of the extra fields.[/li][li]You can easily add new user types without touching any other code, only writing methods that behave differently in your new class than in the base class. For example, maybe you want to divide console users into color consoles and B&W consoles. You can extend TConUser and only override the Write method, since the Read method will be the same.[/li]Or if you write a hash table class for mapping strings to pointers, you can easily turn it into a case-insensitive hash by overriding the hash-function and comparison methods in a new class, without worrying about the others. If you decide to change or optimize some of the base class’s methods later, your changes will automatically propagate to the derived class.
[li]A well-written class can easily be taken out of one project, and used or extended in another.[/li][li]Decent IDEs can automatically remind you of method names, field names, and property names as you begin to write a statement. Without OOP, functions aren’t associated with data types, so at best you’ll be able to get a list of every function in the project, instead of the ones that are appropriate for the type you’re working with.[/li][/ul]
Note my liberal use of the word “easier”. OOP makes some things easier, but everything you can do with OOP can be done without it if you’re willing to write more code (the ‘cfront’ C++ compiler works by translating C++ code into regular C code).
Yikes. 
Could a mod please put some line breaks in those long comments?
The strength of the object-oriented model (for me, at least) is the extensibility; you start off with a language that comprises a range of basic tools to do common tasks, but you can easily create reusable objects to do your own specific functions that essentially become part of the language.
Thanks for the info. I have a lot better grasp of what I am missing. I guess at the small scale level I am programming there is little advantage. Handling I/O, graphics or data files looks to be better, especially if you are doing lots of projects
A class of language that’s cool to play around with is called threaded languages. The most well known one is Forth.
That’s pretty much true. Small stuff you’re never going to re-use really doesn’t benefit from OOD. However it’s really great when you can say do something like replace a socket object with a serial port object and all of a sudden your app works when accessed through a serial port.
Of course try not to go “overboard” with it and write classes simply to write classes. You should think about how one class you’ve written relates to another so you can do things intelligently.(As an example that relates to the previous I was working with a socket and serial port classes in work. Both supported sending messages and callbacks. However there wasn’t any overlap between them so I had to write code to effectively translate stuff like “somebody connected to me”, “I’ve got data”, and “I’m done sending”. It was pretty obvious when I was using them that they should have had the same messages and callbacks so I could just plug one or the other in once a connection was established.)
Amen to that. I once won 128 meg of RAM in contest (back when that was a lot of RAM) by writing in 25 words or less what I would do if I had 128 meg of RAM on my computer. My answer: “I would write a Hello World program using the Microsoft Foundation Classes.” 
Threaded languages? What sets those apart from any other language that supports threading?
IMO, threading is where the benefits of object-oriented programming really stand out. You create a thread class that has the basic functionality that all threads need, and then just inherit to specialize. Instead of writing any sort of external functions to send messages between threads, you either rely on a control class, or use the member functions provided by the class. This makes it downright easy to write well-behaved multithreaded programs.
As a veteran of both OOP and procedural programming, I agree with most of what others have said about OOP enabling easier re-use and cleaner programming. It would be horrible to have to write a Windows application without MFC, for example, like people used to have to do in the old days. Or create a GUI in Java without AWT or Swing. (Some say it’s horrible even with…)
However, I have seen alarming trends among some of my colleagues of overengineering systems horribly just because they can. They are usually people who have just learned OOP, they think it’s really really cool, and end up creating monstrous Heath-Robinsonesque virtual edifices of interlinked and often gratuitous objects. They are desperate to cram inheritance and polymorphism in there somewhere, whether it makes sense or not, because otherwise it must not be object-oriented, right?
I know it’s possible to be Byzantine in almost any programming environment, and we programmers/engineer types often seem to have by our very nature a propensity to overengineer systems, but I have seen a lot more of it in the OO world.
I never saw it myself, but I once heard a horror story from a colleague who said he worked on a military system (naval warfare and command-and-control, IIRC) where every single item was an object – down to the individual letters on the displays. :eek: Just imagine the sheer overhead it took to draw a simple map…
Save that for the horror stories when you’re trying to put the junior programmers to bed, folks.
OOP is a TOOL, let me repeat, IT IS A TOOL.
It is no more then a method of thinking about something, it is all compiled to machine code in the end. If programmers were not limited by their human minds then everybody would program in ASM and all of this foolishness would be through.
But as it is humans ARE limited by their minds and as such OOP can at times prove to be a useful tool to use for thinking about a problem.
But that is it. It is a method of thinking about something, just like set theory or algebra. Some things lend themselves well to set theory, some things lend themselves well to algebra, anything you can do in one you can theoretically do in the other (or at least anything in Algebra you can do in Set theory, I do not know about the other way around).
In that example Algebra is like OOP, you don’t /need/ it, but it sure as hell comes in handy for thinking about the problem and for keeping things organized and efficient.
Just make sure that you do not get too carried away with it, sometimes OOP is not as efficient or as good a method for thinking about a problem as other ideologies are. There are plenty of different thought methods available to the programer to use, learn about more then just procedural and OOP.
I can top you all in terms of Worst Object Oriented Design Ever.
An engineering program, designed to simulate oil refinery processes. The programmers were all sent to a “Koding Kamp” to learn this “True Object Oriented Philosophy”, which was going to save them all.
So they came back, and started working on a Class Heirarchy.
After a short time, the manager came in and asked for a progress report.
“Well, we almost have the Solid Class done…”
What?
Well, it seems that the programmers had started off down this logic trail:
- Everything in the Universe is made of atoms.
- All molecules are made up of groups of atoms.
- Molecules form everything about us, such as solids, liquids, and gases.
- If we can create classes that model the behavior of atoms, we can inherit from those to make a Molecule Class. And then, from the Molecule Class, we can inherit to make a Solid Class. And from a Solid Class, we can inherit to make a Steel Class. And from a Steel Class, well, we can model a pipe - the Pipe Class. And from the Pipe Class, we can inherit to make a 3/4 inch 316 steel pipe that carries ammonia, by creating the 316SteelPipe Class…and, of course, it will carry the Ammonia Class…and using simple, easy-to-understand object oriented tools like this, we can put together the entire oil refinery, and thus model it exactly.
Yes, this is true - I knew several of the programmers. Yes, the project was cancelled, after spending about $700,000.
The scary thing is - I have some PowerPoint slides that show these Classes continuing on up to Site, Infrastructure, Town, City, State…all the way up to, and including, “Planet, Solar System, Galaxy, and Universe” classes.
Their instructor told them that the entire Universe was nothing but an object-oriented heirarchy, and they ate it up (at $5000 a person to go to the “Kamp”).
Programmers who do these sorts of things need deep, intensive, tag-team psychotherapy.
IMO.