Oop 101?

[Mark Farrar]

Can anyone recommend a good book or site that gives a solid introduction to OOP? I am not a computer scientist: rather, I am an engineer who also programs. Procedural has served me well for years yet I try to have an open mind about other ways of coding.

The problem is that every time I ask someone who understands OOP to give me the fundamentals, they start drawing clouds and arrows ... then talk about the "person" class and the "Fred" and "Tom" objects.

I'm looking for something a little more grounded. Something that explains OOP and it's use in practical programming etc.

I have to say, so far ... I really don't see the advantages, but ... that is why I need a good book or reference!

thanks...
M

btw...PB 9.0 looks great even if you ignore the OO parts ... all kinds of new toys ... will get my copy soon!

[Joe Byrne]

I have to say, so far ... I really don't see the advantages

Join the club

but ... that is why I need a good book or reference!

Good luck. thousands of books out there, not a one that really says anything beyond that which you've heard already.

Have you heard the one about the class vehicle, with an object car, which is inherited from a great grandfather named unknown?

Actually, I finally realized it's all smoke and mirrors.... a marketing ploy (not by PB, but the industry in general) to say "See, we can still create things as overly complicated and useless as 'C'.

[jcfuller]

Mark,
Did you read the sections in the help file? I thought Bob did as good a job as any other text I've read on Classes , Objects and oop theory in general.

James

[Barry Marks]

I think people explaining OOP draw clouds because OOP is a cloudy topic. It doesn't seem to be something you can just simply explain.

I'm not an OOP programmer either. I've taken a course in C++ but I never really used it much beyond the course. I'm happy with procedural programming. I find OOP confusing.

I have the impression that the value of OOP is that it makes it easier for large groups to work on large projects and probably also that it makes it easier for good programmers to build tools for mediocre programmers to use, making average programmers more productive. That's not a bad thing.

I suspect that a good, well organized procedural programmer who has built himself a collection of tools and libraries that work the way he likes to work can be as or more productive than anyone using OOP.

I wonder if maybe another value of OOP is that it encourages programs with more options and more complexity for the user. I tend to think in terms of simple tools and I avoid using the large, complex, do-everything for everybody every way type programs in my own use whenever I can. But that kind of program seems to be what most people want and I wonder if OOP isn't a better way to build that kind of program.

Barry

[Joe Byrne]

But that kind of program seems to be what most people want and I wonder if OOP isn't a better way to build that kind of program

You might have something there, to a point. However, I highly doubt people want a program to do a million things. I think its more plausible that development companies want/need to keep adding things to justify upgrade sales. I've seen hundreds of great programs become useless with all the added "features". Its not just bloat, but the problem they once solved so well becomes secondary to the application itself over time.

From all I've seen, the real advantage for OOP in PB will be its ability to use existing libraries that previously have been out of reach, or required substantial work-arounds to use. I agree with you though, that well designed procedural code appears to me to be just as "good" as OOP, at least for my purposes.

I suppose if I had a big investment in OCX libraries, or if I wanted to create a shared library "the new way", I'd be more interested in OOP. But I have been with PB since the Turbobasic days, never wasted a penny on VB, and have accumulated all the reusable code I think I'll ever need. So for me, and lots of others like me, I'm very relieved to see that Bob has no intention of depreciating the traditional procedural style of PB. For those that want OOP, they have it; for those of us who don't care for it, we're not stuck either. Best of both worlds I suppose

[jcfuller]

For me it was encapsulation that sold me on oop. I've been jumping through hoops for years to avoid using GLOBALs. Way back in the olden days when dimensioning variables was not my bag and procedures were not invented yet I spent weeks trying to track down a bug where I had used a zero in a var name instead of an "O". Soon after I discovered a procedural basic for the atari and was hooked. No more gosub's and I could force var dimensioning.
Simple inheritance is a real time saver too ,but you can go overboard, as some of my previous and future demos will show

James

[John Strasser]

Fwiw, (albeit in the C++ world)

Robert LaFore (any of his books) will do you well.

I learned C from his C book and then when C++ started I bought his book on that too (this goes back to 1988 thru 1992).

That will teach you OOP.

The way I started (since I knew C) was to do everything in a procedural way, BUT - everytime I needed a struct (TYPE in PB) I used a class instead. Just so that I could take advantage of constructors and destructors.

Eventually I added more and more in (I like to read the book before I start to get an idea *what* is possible) until one day I woke up and found that I was writing in full blown OOP mode. Remember, this was before "event driven" stuff was even started.

Now, I wonder what I should buy myself as a birthday present next month...hmm...

JS

[Cliff Nichols]

I am not a computer scientist: rather, I am an engineer who also programs.

Mark, I too am an engineer that happens to program
Electro-Mechanical, but programming seems to fall naturally between the 2 realms, so I can see most points if talking to a Electrical Engineer, or a Mechanical Engineer (I can even see some "Worthless points" from a Civil Engineer (Don't let my Dad hear me say that )

I'm looking for something a little more grounded. Something that explains OOP and it's use in practical programming etc.

I have to say, so far ... I really don't see the advantages, but ... that is why I need a good book or reference!

Books and examples I have seen back in my VB days, all used the same "USELESS" examples of "I have a class named 'Dog' I have several types of dogs, I inherit this class to build a new class of 'Hairless Dog' and etc.....all TOTALLY WORTHLESS TO ME type of thing.

Not that they are not good examples in their own right, but they have nothing to do with anything I work with, so I can not see the significance.

Its like speaking languages, until the 2 people, or concepts understand enough basics of the other.....the whole thing is gobbledy ****

I will save most of you the pain, but in case Mark has anything to do with serial ports I will give a gist of an example.

Lets say I write code to talk to 1 serial port

1. Later I need that same module to talk to multiple ports (all the code is the same, just a different port)
2. I could either go through the same INC file, and remodify it to talk to a different port, or multiple copies of the same INC file, and rename all functions and the INC to a similar name with a number or something to distinguish it from the other copies
3. If I go that route, how do I keep Handles, variables, and any other information separate from another copy of the same code? (Brings into play the concepts of Threading, Globals, and other concepts too big to mess with right now)
4. If I look at objects as being 1 Class (same code), and use that code as a different object (aka Port1 = Instance of Object, and Port2 = Another Instance of the Object), then problem solved, and each plays in its own lil sandbox of sorts.

NOW I have a better understanding of OOP (although minimal), but because it speaks to my own knowledge of an application, and nothing to do with Dogs, Cats, Dinosaurs, Types of soap they use, nor Apples from Oranges

[Brad D Byrne]

I have always been very anti-oop!, before I found PowerBASIC I struggled thru MFC & Java, I hated the way MS encapsulated the base Object, it forced us to use a rectangular system and there was no way around it, (and I was very interested in using a triangular system for graphics) anyway having first learned fortran, we were taught to build all of our data structures in such a way that we provided inheritance, and many of the ideas of oop, we could easily do all of these things with procedural code (we thought)

well, now is many years later, and the biggest thing is communication accross-platform/s and throughout the web, even as I hate to say it, oop is the way it is going, and honestly the hardware is going that direction also, as far as I can tell, we will see computers that have special sub-processors (much like the 8087's) whose sole purpose is to process certain objects, we will also likely see the quantum technology also specialize on certain structures, no?

anyway, I am extremely happy to see someone like Bob and team who can mix low-level (asm) and high-level in the same system...hehe, (not sure if that communicated) got to many people talking to me!!! later

[Mark Farrar]

Books and examples I have seen back in my VB days, all used the same "USELESS" examples of "I have a class named 'Dog' I have several types of dogs, I inherit this class to build a new class of 'Hairless Dog' and etc.....all TOTALLY WORTHLESS TO ME type of thing.

NOW I have a better understanding of OOP (although minimal), but because it speaks to my own knowledge of an application, and nothing to do with Dogs, Cats, Dinosaurs, Types of soap they use, nor Apples from Oranges

Yes ... exactly!!!! this stuff drives me nuts

However ... thank you for the com port example ... that makes a bit more sense.

The problem with the way people explain OOP is that either it's so elementary (class dog, object Beagle) that I just thing yea ... ok ... and ...now say something that I can use .... you could be talking about any hierarchical structure ... this says nothing about a coding methodology!

or .... they begin a lofty cloud drawing session with harp music playing and I really wonder if they understand it themselves or are just waxing on about what the were told my some other faux sage OOP jedi master!

anyway ... thanks all ... I did see the book recommendations and I will take a closer look at the PB help file. I'm not sure that for the type of code I develop OOP will mean much, but I will look into it.

I just can't help but think that if something is so revolutionary that it is the solution to world hunger, then it should be a lot easier for an expert to present a fundamental case for practical (use than most seem capable of). I have literally asked 15 different OOP types to explain this they have all either told me the same Fisher Price tale or just rolled their eyes and said you don't need it.

Thanks again Cliff ... at least the com port example puts it all into some context...but ... I think I could design proceedure based code with the same flexiblity so I am back to why?

[Barry Marks]

at least the com port example puts it all into some context...but ... I think I could design proceedure based code with the same flexiblity so I am back to why?

I don't think OOP lets you do anything you couldn't already do. It's a new way to do the same old stuff, and, in some environments, probably a better way.

It was the same with procedural programming. I began programming on a mainframe with 5 job slots (it could run 5 programs at once) and 80k RAM. It was far slower than the computers we have today and even though it could theoretically run 5 programs at once it was rare that we could run 3 programs without bogging it down. But we needed to get as much as possible done in the 8 hours that we had on the machine each night. That meant spaghetti code.

I was taught to write self modifying code, etc, to save every cycle and every byte possible. Readability wasn't a consideration and it didn't matter if it took twice as long to write the program. It had to be fast and small or it was useless. After being trained in that environment I thought procedural programmers were a bunch of sissies.

Of course the world changed and I had to learn procedural programming. It took a long time for me to understand why other than that the boss said to learn it. But I did learn it and now I'd hate to go back. I'm not even sure I could go back.

At the same time, I'm glad I retired before I really had to learn OOP. I may play with it in PB a little but I doubt I'll go very far with it. Not that I think OOP is bad. It's just not for me.

Barry

[Richard Angell]

It not all about OOP that you create yourself. Being able to access existing COM applications that support direct interfaces is really useful as well. For example, I'm working with some TrueVision tutorials for their 6.5 engine, hobby project for the moment. Using the syntax for direct interfacing makes the code a whole bunch easier to write and read. Side by side the coding in 8.0 was longer source than in 9.0. The results of coding with the previous 6.3 engine ran => compiled C++ examples, but for the 6.5 version we have yet to see a compiled C version since they have not updated the tutorials yet.

My son had done the conversion of some of the first 3 TV C++ tutorials to PBWin 8.0, compiled and sent the exe's to another game developer ... sorta opened his eyes!

My point is that it's not all about writing your own classes and servers, but it's also about the extended ease of using direct access code where supported. Here's a snip from a 9.0 conversion that helps illustrate ... no variant variables being used by the coder directly, no OBJECT call/let/get syntax either ... just lines of code that look similar to what we are used to using:

WHILE Msg.Message <> %WM_QUIT
        IF PeekMessage(Msg,%NULL,0,0,%PM_REMOVE) THEN
            TranslateMessage Msg
            DispatchMessage Msg
        ELSE
            'render
            y_rot_val = y_rot_val + 0.1
            y_rot = y_rot_val

            IF (y_rot_val + 1) = 361 THEN y_rot_val = 0

            oTVMesh.SetRotation(x_rot,y_rot,y_rot)
            oTVEngine.Clear(0)
            oTVScene.RenderAllMeshes(0)
            oTVEngine.RenderToScreen()
            'input

            Result = oTVInEngine.IsKeyPressed(%TV_KEY_ESCAPE)
            IF NOT Result = %False THEN  PostQuitMessage(0)

        END IF
    WEND

[Mark Farrar]

a must read - this is an eye opening article

I good read ... lots of perspective:

http://www.devx.com/opinion/Article/26776/0/page/1

"OOP is to writing a program what going through airport security is to flying"

[Barry Marks]

I good read ... lots of perspective:

http://www.devx.com/opinion/Article/26776/0/page/1

"OOP is to writing a program what going through airport security is to flying"

An interesting article and one that describes my own feelings pretty well. However, I don't trust these feelings of mine all that much. It's real tempting to sneer at something that I don't want to learn and don't need to learn and say it's useless. But what about all the people who learned OOP and use it and swear by it; many of whom are good programmers whose opinions I respect.

I think he overlooks one of the important aspects of OOP: that it provides a systematic way for more expert programmers to create tools for more mediocre programmers to use, resulting in lower costs for large projects.

I think his point about books giving examples in procedural code instead of OOP is off the mark. They have other good reasons for that. They want to reach as wide an audience as possible and procedural code will be clear to both OOP and non-OOP programmers, where OOP examples will mostly be clear to OOP programmers. Also, the examples are usually small blocks of code that would only be obfuscated by putting them into an OOP wrapper, even to an OOP programmer. OOP uses procedures (calling them methods) so procedures are familiar to both kinds of programmers.

From the article: "True, OOP includes features to help deal with this problem, but why does OOP generate problems it must then deal with later?"

What solution doesn't come with it's own set of problems? Loops have loop overhead. We work to minimize it but it's there if we use loops and not if unroll them; a common technique of game programmers of the past trying to get the most out of hardware. Anybody want to stop using loops to get rid of their overhead?

When readable code became important we made a lot of sacrifices to it, both in speed and program size. Anybody want to stop considering readablity? Nearly every solution to a problem introduces new problems that have to be dealt with.

"Programmers describe it as little Ashley's first birthday party: the computer starts counting from zero, so to the machine it's her zeroth birthday party."

This is wrong. Ashley's zeroth birthday party, according to the computer and probably to most humans, would be the day of her birth.

I wish he was right and that OOP was going to fall to the wayside, but I kind of doubt it. It's more likely that he, and I, just don't know it well enough to see it's benefits.

Barry

[Joe Byrne]

I wish he was right and that OOP was going to fall to the wayside, but I kind of doubt it. It's more likely that he, and I, just don't know it well enough to see it's benefits.

As long as my compiler of choice doesn't force the use of OOP, I really don't care one way or the other. However, your comment only proves his primary assumption. After 10 years, nobody seems to understand OOP well enough to see its benefits!

I completely agree with this article, but as has been said before, "its a tool, like any other. If you like it, use it, if you don't, then don't."

[Cliff Nichols]

I agree....If forced to use a technology, that's one thing, but to let technology be optional...that's another!!!!

I even agree with the writer's comment of

To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same programmers to inherit, modify, and reuse this code that they cannot see—they see what goes in and what comes out, but they must remain ignorant of what’s going on inside

What I disagree with is its not just oop...but anything that you can not see the original code. (Be it OOP, DLL, or ActiveX, or any other name)

When there is a bug, it often does not show its ugly head until long after the moment occurred, and if it is in a section that you can not see (much less debug), makes it all that much harder to find the cause.

The one thing I like of PB (well 2 things)
1.) OOP is optional
2.) Usually when we post code, we show alllllll the code and not just tell someone to rely on some DLL or something else that the next user can not see the original code

[Brad D Byrne]

>>>>>>"....After 10 years, nobody seems to understand OOP well enough to see its benefits!...."

hmmmm, I think the benefits are well understood it's all about providing a standardization, let's think about procedural code or even assembly,with them there are limitless ways to approach different problems, some code for speed, some for simplicity, etc, but mostly every program is a little different, this makes for big maintenance problems for large corporations who want to update code written by employees who are no longer around.

further, procedural code, because of it's diversity, makes for a nightmare when trying to adapt to different platforms, but let's say we define a standard way to build a data-structure which comprises of both data and methods, and we get all the different platforms (OS's), browsers etc, to support the processing of these structures (objects), now we can easily have cross-platform coding.

now granted these types of objects will carry more overhead & process slower than procedural code, yet today most think that the added portability out ways the speed differances.

next, given a solid standardization, the hardware can be designed to hard-code & optimize for processing around these bottle-necks. Personally I dislike oop as is because it limits our controll of the hardware, how-ever it is the future way and likely for good reason!

Sure Happy though that there is a PowerBASIC that exists that allows us to do it all !!!!

[jcfuller]

>>>>>>"....After 10 years, nobody seems to understand OOP well enough to see its benefits!...."

hmmmm, I think the benefits are well understood it's all about providing a standardization, let's think about procedural code or even assembly,with them there are limitless ways to approach different problems, some code for speed, some for simplicity, etc, but mostly every program is a little different, this makes for big maintenance problems for large corporations who want to update code written by employees who are no longer around.

further, procedural code, because of it's diversity, makes for a nightmare when trying to adapt to different platforms, but let's say we define a standard way to build a data-structure which comprises of both data and methods, and we get all the different platforms (OS's), browsers etc, to support the processing of these structures (objects), now we can easily have cross-platform coding.

now granted these types of objects will carry more overhead & process slower than procedural code, yet today most think that the added portability out ways the speed differances.

next, given a solid standardization, the hardware can be designed to hard-code & optimize for processing around these bottle-necks. Personally I dislike oop as is because it limits our controll of the hardware, how-ever it is the future way and likely for good reason!

Sure Happy though that there is a PowerBASIC that exists that allows us to do it all !!!!

I am not too familiar with eiffel but for large corporate projects it does seem the way to go.

http://www.eiffel.com/

James

[Michael Mattias]

>After 10 years, nobody seems to understand OOP well enough to see its benefits

Benefits (as well as drawbacks) are subjective.

[Mark Farrar]

back to the root question

back to my original post...

I am open to new ideas ... I want to understand OOP for myself to see any advantage that it might bring to my personal efforts.

My problem is that for all the books, web sites, and experts out there, there seems to be a consistent lack of ability to explain what it really is!

yes ... its a methodology yes ... I hear the advantages etc

yes ... I get the basic generalized encapsulated viewpoint (class dog, objects collie and beagle) ... but

With the exception of the one individuals example of the serial port code, I find a complete lack of meaningful examples or even notional examples.

I ask again. For something so prolific and advanced, why can non of the experts explain what it is beyond the basic (and somewhat useless) metaphors?

I am not really finding fault with OOP ... I don't know enough about it to find fault! My issue is that I can't get anyone to really tell me what it is!!!

It seems to sound like this: I have invented a new coding ideology ... I call it Tralfaz ... it is better than anything else out there. I can't explain it to you, but it's better than what you use. You should use it too. Then you will join me in being one that understands it but can't explain it either. The we can both tell others that what we know is better ... but again ... let's not explain it since it is so much better that it can't be explained!"

omg ... we are talking about a code scheme ... this should not be that hard. For god's sake ... If I can read a book by Steven Hawkins and understand string theory, M theory, particle physics, and quantum mechanics, then why can't I find something to explain OOP?

ugh....

I will keep trying ...