Hey all,
So my question is this I have been programming in Perl for about a year now, I have some knowledge in R, I have played with php, and think I want to learn Ruby. However, I think that before I do that I should learn how to use Object orientated Programming (OOP). I have never been formally introduced to it and I cannot find any really good tutorial on the web. I have the 'Camel' (O'Reilly) and I got a little lost. So I was wondering if someone could tell me some of the basics and what they use OOP for on a daily basis.
Cheers,

I was in a similar situation and it was only by *using* an OO language (Python in my case) that I finally grasped what OO is about. I have had a look at Ruby and that is even more OO so I'd suggest you "just" learn Ruby and OO will open up to you eventually.

As far is what it is used for every day, I use it for most things (jsp, applets, databases...), how much detail do you want?

For me it is much easier to think of things as objects. I use Java and Python for most of my programming. Only when I need to get at low level things, or when I need less security, (or for OpenGL) do I use C. And as I learn how to bind C with Python I use regular C even less.

I find that with object oriented programming I am able to reuse a lot of my code from project to project, and my code is able to interact well together. (I am not as experienced with non-OO languages as I would like so I do not know how easy it is to do in those languages).

I would agree the best way to learn is to dive in. If you have no clue about what the jargon means just look at wikipedia for some basics, and that should be enough to get you going (especially if you have a Ruby book)

http://en.wikipedia.org/wiki/Object-...ed_programming

Technically speaking, you've opened up a real can of worms, PB0711. But that's alright; I'd be more than happy to throw my two cents in. The problem is, almost every single language has a slightly different twist on what it means to be "object-oriented".

Smalltalk is a relatively early object-oriented language that devotees considered ahead of its time. That language treats everything as an object including literal numbers and strings. Methods are actually messages which are sent to the object they're called upon. This includes arithmetic: the code "1 + 2" actually sends the "+" message to the object created by the literal "1" and passes the object created by the literal "2" as a parameter. Ruby, for the most part, follows this approach; it also includes some other pieces of Smalltalk-like syntax such as execution blocks.

C++ is somewhat different in how it treats the phrase "object-oriented". Objects are more like encapsulated code blocks with unique namespaces. Rather than receiving a message to take action, invoking a method on an object in C++ is really just calling that function for the correct namespace. The runtime environment then sets a special variable that indicates which data the function can operate on. Also, not everything in C++ is an object; integers floats and chars are still just a collection of bits with no object identity.

Python, Perl, Java, and CLOS all represent slightly different permutations of the object-oriented philosophy. I think the best way to learn about the overall idea of OOP is to just pick a place and start learning. I'd recommend starting with Ruby, as the philosophy it uses makes the most sense to me. Then as you start to grasp the ideas of objects, the class hierarchy, messages, mixins, etc. try to begin learning other languages. Since you already know one in depth, picking up others will be easier. As you compare and contrast the way different languages treat object-orientation you'll understand more about the global concepts underlying all object-oriented programming, and about why languages' implementations of OOP vary the way they do.

I always recommend to my students that you should "look for the big picture first." In other words, try initially to avoid the minefields of peculiar jargon and look instead for the essential simple idea that ought to be lurking somewhere in plain sight.

In the case of "object oriented programming," that idea is simply a "thing."

You know already, intuitively, what "a thing" is. It's something that you can look at, pick up, and use without knowing everything that there possibly is to know about it. If you encounter several similar "things," say, sitting on the kitchen table, then you know that you can expect all of them to look and behave in more-or-less the same way, such that you can naturally focus on what makes one of them different ... if you need to and want to ... or, you can ignore the subtle differences completely and just approach them in terms of whatever characteristics they all have in common. It's your choice, and that is what we now want to capture and to be able to employ in a programming environment.

Since anything in "the programming world" is necessarily a thin abstraction of the richness of real life, here's what we've done...

We define the notion of "an object" as being: "a chunk of data, and the ability to view and manipulate that data, neatly packaged together." We don't have C-style functions (defined "over here") manipulating structs and records (defined "over there") .. thus two separate things defined in two separate places. Instead, we have one thing, "an object," which consists of programming and data, together.

We have one way to say what we want to occur, even when there are considerable differences in how different things occur. We have created a situation in which we can elect to focus on "what, not how." The intrinsic design of our OOP language permits us to safely focus on just one aspect at a time ("what" when we are using it, "how" when we are writing it), at the exclusion of the other. (If you think about it a little, that's extremely difficult to do in an unadorned language like "C.")

What does an object "look" like? Well, it has buttons ("methods") and lights ("properties"). You can push the buttons, and when you do, "things happen." Maybe a thermonuclear explosion happens somewhere, but probably not. More likely, the lights change. You can see what it does, but you do not have to know anything about how it works. You can write code that interacts successfully with it, and with anything "similar to" it, (a) without ever understanding "how" it works, and (b) without ever creating code that is functionally-dependent on how it works.

So... you grab a copy of a "Super Gee-Whiz Object v1.0" from the Internet and you use it in your program. Then the vendor sells you "version 2.0" of that object. It's been completely redesigned inside, so it works much faster, but its "buttons" and "lights" are exactly the same. So... you can "just drop it in." No other changes are needed anywhere in your program. That's cool. You don't care how it's different... you only care about what it does... and, with OOP, you don't have to care about "how." (Likewise, the vendor was able to completely-redesign the "how," without changing the "what," and therefore to know with certainty that it'll still work... in a program they'll never see.)

Ahhh... the object is almost perfect, except for just one small detail: you need to redefine the square red button. Not anything else about the "Super Gee-Whiz Version (Who-Cares?)," just the behavior of the red, square button. With OOP you have the means to do that, by defining a subclass of the Super Gee-Whiz which is identical in every way to what a Super Gee-Whiz is (or ever will be in the future) except for "just one small detail." If you want the button to "play the national anthem of Albania three times, then do 'whatever the red square button normally does, whatever that is now or one day might be'," you can do that.

All of this is helping to build well-defined, formalized boundaries between sections of code .. "ours" and "theirs." And it helps considerably in building robust, maintainable code.

WOW...... ......

First, sorry for opening the 'Can'. I didn't know that I was. Second, the good thing is now I can start to see how I have opened up the 'Can'. Third, smalltalk sounds pretty cool but I haven't heard of it before so... I'll go with Ruby, since you said it impliments some of that.
A big thanks to 'sundialsvcs' for explanation of OOP your explanation has set things a bit clearer for me.
One more thing, and I'm sorry to do this (another can I guess) 'What Ruby book would you recommend?'. O'Reilly?

Cheers once again

I have read good things about this one. An earlier version is available online here.

That is the book from which I learnt Ruby; it's very well-written. Additionally, it's useful both as a tutorial text and as a class reference.

It's not unlikely that you've not heard of Smalltalk. Nowadays it's fairly unknown to the general programming community. The most official language website I know of is http://www.smalltalk.org/ - there's a listing of implementations on there too, some of which are open source.

As an aside: sundialsvcs' explanation of the general idea of OOP is fantastic. Sorry if mine was confusing; I guess I'm more of a bottom-up learner than a top-down learner.

while still waiting for an answer ...

i might just as well swim here lightly ...

i think probably what he was trying to say was looking at things "top-down" with a "bottom-up" mentality ... but who knows ... probably we would at some points settling with variants types instead ...


.

OO has been around in many flavours for forty years (perhaps more). It's not a silver bullet but it is a way to look at modeling a solution in code. One of the really nice things about the OO view is (as others have pointed out in this thread) thinking of data not just as data, but also in terms of the operations you can perform on that data. It actually goes quite a bit further than that as there is the idea of having sort of a standard view of data and the things you can do with it and which is used as sort of a "parent" and then you can define "children" which "inherit" certain aspects of their parents while changing others. I won't go into any detail as this is a long explanation and I'm not the most qualified. But there's an excellent (very informative and enjoyable) basic tutorial here:

http://sepwww.stanford.edu/sep/josman/oop/

P.S. Avoid Java at all costs!

I'm not very fluent in any of the modern OO languages. Even so, we've been employing some of the basics (especially encapsulation) to a remarkable degree even in assembler for many years. (I'm not sure that OO can lay claim to some of these design principles although they are certainly part of the OO view today) While some things like polymorphism are relatively impossible to achieve in HLLs which weren't designed with OO in mind you can do usually do a very nice job with a hybrid approach.

We've also achieved a remarkably high level of reuse from assembler up through HLLs through proper design- I don't think this is nearly as dependent on OOP as it is dependent on a compiler and underlying language which provides for modularity in coding and granular packaging of functional units. Interfacing is pretty standard as long as things are written as black boxes that perform a very specific job; this is just good practice and unrelated to OOP.

I think it makes sense to have all the tools you can in your tool box so that you can choose the right solution for the job. OO is not always the best approach. But knowing about other ways of creating solutions is always a good thing.

Yeah, you bring up a very important point... Object-Oriented is not so much a characteristic of a language as it is of program design. Of modeling ... which, also, is something that you do primarily in-your-head not with this-week's-language.

A lot of programming "design" is done bottom-up, "at the keyboard," "on the fly." And that's usually where you get into trouble. What snags you most is how the various modules that you have written interact, and in the number of separate places in the overall source-code which have become functionally dependent upon one another. You do something "over here" that is functionally dependent upon what you're doing "over there," and soon you have a network of dependencies so fragile that it just keeps breaking.

I don't mean to reveal my age here but ... "there's always one more silver-bullet." Always one more college professor on the consulting circuit telling senior-management how this will magically solve all the world's problems." One more company telling them that if they'll just license thus-and-such tool for every one of their developers, Life Will Be Beautiful All The Time. And somehow, they always think of some "sexy" new name for it .. Ruby, Stiletto, Onyx .. and coin a syntax that's just a little bit different from anything that's ever been used before. One more meaning for those poor, overworked punctuation-marks at the top of the keyboard.

What you'll realize, though, is that the only true "silver bullet" is discipline which comes from experience. You write a lot of code, but more importantly you maintain a lot of somebody-else's code. You watch brand-new pristine software architectures get spattered with changes that have to get done because the business is moving. You listen to another group of programmers telling you that you simply must scrap everything and start over. You tell them, "No."

In my advanced-programming classes I always asked students to submit their work on electronic media, later to upload it. And what I'd do is to sanitize it, or maybe dirty it up, or maybe cut it in half and "lose" part of it. And I'd hand these out to the next class, with stories like "Joe Schmoe got schmooshed by a cappucino truck. By next Friday, finish his program and modify it to do the following..." Usually, the class was all but deserted on Friday. By Monday, though, (yeah, I accepted it despite the dire threats... I'm not that cruel) we'd talk. "What was it about this program that made it easy to maintain? Or hard? What was the most difficult thing about getting this job done? What could the original programmer have done to help you out?" And, amidst that sea of dazed, sleep-deprived faces, you started seeing lights come on. Several students admitted that this was the very first time they had seen, let alone been asked to maintain, someone else's code. But that is really what it's all about.

Welcome to the world of "Legacy Systems." In the real world, it is entirely possible that throughout your entire career you will never write a new program from scratch...

I realise the point you are making, which is definitely valid and very important, but in the interest of discussion, and at the risk of getting away from the OP's intent, and finally with all respect, this process of designing "at the keyboard" is in my opinion very important in early development. The capability to rapidly prototype a set of functionality, facilitated and assisted by dynamic languages like Lisp or Ruby, can be absolutely essential during early design to get a feel of how the program or component will work. Writing code in this way, with little formal planning, can also help you quickly solve the problems at hand and decide the best approaches for reaching the solution. After you have a feeling of how it will work on the inside, you know what interfaces will be necessary or feasible. If the external interface is given to you in advance, you can figure out what sort of "glue" you can write to apply that interface to the internals you've just prototyped.

I don't think there's anything particularly troublesome about programming on the fly unless you think you can write all of your code that way. Ideally, design and production should proceed hand-in-hand: plan a little, code a little, plan a little more, code a little more. If you write the complete internal specification without writing any actual source code, you have no idea if you can program it, or if it will even work. If you write all the source code without any specification then your code will more than likely have almost no consistency or organization. If the external interface is provided, write some wrapping code to cleanly apply it to what you've created. I'd wager that most programmers have jobs because they know how to solve hard problems that others don't. As a professional programmer you have a focus and an expertise. Don't just write your internals to blindly match the interface you were given: solve the problem the way you understand and find best and use your own internal interface to match what the outside world expects.

Those are my theories, anyway. But I'm also only 21 years old and don't have much time in the biz yet. Great discussion so far, by the way.

Lots of good discussion going on here!

This can certainly happen when people don't do things cleanly. This can happen even with so-called OOP, but the key is

That's exactly right. The only problem is that while it only comes with experience, it sometimes doesn't come at all.

I'm not sure that I agree with all this. Certainly, the value of prototyping is clearly established. But let me explain how and what I prototype and you'll see where my thoughts diverge from what was written here. The first thing about the types of things I work on is that typically they haven't been done before. Unlike applications, where the challenges are largely organizational, in systems software you're typically reverse-engineering something (I did not say that- did I say that?) or trying to do something that hasn't been done by anyone else. Competition is very fierce for high performance and new technology and we don't compete on price points or features. We either have to do something that's so difficult that no one else can do it, or we have to do something important, significantly faster than anyone else can do it.

The way I've worked for many years is either alone, or with small teams (3 to 5 developers). Either way, the first part is to understand exactly what it is we have to build. (I'm addressing pure development or major enhancements here, as opposed to the service aspect (which I'm also heavily involved in) just to keep focus.) If I'm alone, I turn things over in my head until I'm certain I understand what has to be done from a 50,000 ft view. If I'm working with a group, we sit in a war room for a few hours a day brainstorming aloud and drawing functional pieces until everybody has a very clear understanding on what it is and we avoid discussing implementation at this point. We make a point not to get caught up in the "how" but instead focus on the "what." This is key in doing things in an orderly-fashion.

(If the moderators go wild because of unintentional thread-jacking or off-topic posting I vote we start another thread as the whole process of software design and service is something I'm very interested in.)

After we have clear agreement on what has to be done, we start breaking up things into functional pieces. You could certainly argue that by taking this view we've already diverged from the object model, and I would agree that we almost always diverge from the object model at the macro level, and instead implement it at the micro level- and this is part of doing encapsulation properly. You don't need to know anything about my control blocks or implementation- you just need to use my services and interfaces. That way, we don't build dependencies that lead to the structural failures that sundialsvcs alluded to.

I notice for my own part that I tend to model things almost entirely from my own hybrid view of the world. I think in terms of high-level function and then I create a data model that dictates the implementation more or less. It's maybe a weird kind of reverse OO

When we agree on which pieces have to be written, we start parting out the work in terms of subsystems. Most of the stuff I've been involved with has been large systems from 1/2 to 10 million lines of code so we usually think in terms of subsystems or client/server components.

Within the subsystem, the designer/developer normally has complete freedom to implement whatever he wants. What's important at this point is that interfaces between all the subsystems or component pieces are defined clearly and cleanly so that there aren't any surprises. This is an ongoing process and communication is the key. Here is where the prototyping starts. I suppose that for applications where UI is a primary consideration and concern it makes sense to prototype the UI and then build support afterwards. We do things the other way around since UI is low on the list of priorities. (That doesn't mean that we don't care about UI or that we do it poorly, instead, we have specialist teams that wrap the corporate look and feel over what we give them in terms of function, and our design and implementation makes it easy to implement UI because of the way we encapsulate server function.)

Our prototyping is the way we do proof of concept and research, and it can take a long time. At the end of this period we want core services and "engine code," we can't afford to prototype in one language or system and then rewrite anything- that's expensive at best and error-prone and wasteful at worst. We need a clean, production-ready piece of code that will be the basis for whatever subcomponent we need to deliver. While prototyping we stub out non-essential features and certain recovery operations. When we go forward, we complete these functional items. In this way, nothing is wasted. I should mention that in my view it's not simply prudent but absolutely essential that the prototype be bullet-proof. I write test drivers and trace the code at every stage of development and I know exactly what it is going to do because I watched it run. I can't afford to take it on faith that any part of it is going to work until I see it work. By the time my prototype is done, there's a lot invested in it. If I protyped in one language or system and then did a rewrite I'd lose all of that investment- and so we don't work that way.

Agreed. And this is why the way we prototype is important- it gives us an understanding that what we want and how we want to do it are reasonable- and then we're ready to continue immediately.

There is a lot of truth in this, but there are also a lot of contingencies.

It is certain that a very skilled person, or a very skilled and communicative group can work this way and be productive; but it falls apart on very large projects and/or with more than a few developers. It's very clear to me that the state of program design methodology is completely out-of-hand and is an institutional business like greeting cards are to holidays. But some degree of rigor is required. The things that are the most important to get consensus on are the topology and interfaces. You can have a loose-knit group succeed if you do that correctly. If not, a colossal failure is sure to ensue.

For a 21 year old, you sure have your head screwed-on straight!

Yes, this is a big problem in the modern corporate software world. In the old days, we ruled the whole organization. You'll get what we give you- when we give it to you. Nowadays any MBA who they plug in as CTO thinks he knows everything. You have the wrong people making technical policy and it's a big problem.

I recently witnessed such a corporate death-march which began with a one-year documentation cycle and a mandate that not one line of code be written until after the plan was signed-off. It was the biggest failure I've ever had the displeasure to be involved with and the specification (that was supposed to have been hardened) was modified continually through the three year development cycle and to my knowledge, not one piece of code was ever in compliance.

Sadly this is most often true; but it's true whether or not there's a reasonable spec or controls. The truth is that most people employed as programmers shouldn't be allowed behind a keyboard. I haven't seen peoples' output vary depending on the degree of rigor. I've worked in places with no standards and no rules (counter-intuitively, the best quality product I ever worked on was done in this fashion) and I've worked in places with "design processes," standards, and review teams; and the developer is still the key piece in all this. Not one person ever did a better job with controls in place, and not one person ever did worse without them. At least, that's been my experience.

How I wish this statement had a flicker of truth in it

Adding my tuppence. I'd suggest you start off with picking up a text (book or online document) on abstractions in general. Once you've grasped the ideas behind "abstract data types" then "basic OO" will make a bit more sense.

I believe that after that it's easier to grok other OO concepts such as polymorphism and "code re-use through inheritance", etc.

Having been watching this thread since it started I just wanted to add my view...

First the OO approach

There is a lot of terminology around OO, I think that the approach to take so as not to get too confused is as follows:

• Understand the basic terms, not necessarily in detail but be aware that there is such a thing as a message, and polymorphism isn't something out of Harry Potter.
• Learn how to create a class in your language of choice, initially just use it to hold your data
• Now extend that class to hold functions (methods)
• Now play around with access to your data, make it private so it can only be seen or modified via functions
• Now read about encapsulation
• Next extend a class so that you have a parent and child class, see how the child has all of the parent's data and methods as well as its own
• Look at the protected access specifier (if that's what it is called in your chosen language - a means of restricting the data to just the class and any subclass)
• Add data and methods to the subclass
• Now read about inheritance - for that is what you have been doing
• You may want to look at how abstract classes are used in your language of choice. These are just structural additions to the class hierarchy but can be very useful.
• Multiple inheritance is just an extension to the inheritance tree allowing a subclass to have interaction with more than one superclass, this is very much language specific and how it is implement you will need to read about but it is just an extension of inheritance
• Polymorphism is a great word, just as the concept is but it is a little difficult to initially grasp, write some code that implements it and see how it can help to make your code cleaner

That's not all of the terminology but it is (I belive) the main features. Again the order is a personal preference but I have found that it works quite well.
Next OO design
How do you design a program in OO...Well this is just as difficult as the question which OO language? But my approach tends to be as follows:

• I start with the big picture, what is the program to do?
• Then I tend to dive into the class hierarchy, what classes will I require, how do they relate to each other and can I start to build a class hierarchy
• I then work on the class hierarchy especially focusing on abstract classes
• Then I look at the classes in more detail and get it clear in my mind the variables and functions that I require
• At this point I then start thinking about the code and how will I code and test each class

This works quite well for me (it's certainly not without its faults and it really only works on small to medium sized projects).