object oriented programming

Dave

Joined Nov 17, 2003
6,969
Its a programming technique which implements objects that interact with each other. Each object has parameters and data associated with it that is basis for the object interactions. The Wikipedia article will give you a better and deeper explanation than I, or anyone at this forum, can give you. Is there anything in particular that you wish to know or understand about OOP?

Your thread title is a touch vague so I have taken the liberty to modified it.

Dave
 

kender

Joined Jan 17, 2007
264
One sour answer is that it's programming for people who can't handle abstraction.
comments

1. OOP helps only when there are multiple (more than 2) programmers working very close (in terms of functionality) to each other. OOP is simply a way of preventing them from steping onto each-other. This also applies (although to less extent) to a single programmer, who is reusing code over extended period of time. As a side effect, it's easier to sell, license and support OOP code.
OOP has multiple flavors. The strongest flavor (and the most common flavor today) is OOP built into and enforced by the programming language. But there are milder flavors, when OOP is just a coding style.

2. If we start increasing the amount of code, at some point any normal person will loose the grasp of abstraction. An interesting observation is that a group of programmers often loses grasp of abstraction quicker than an individual programmer.
 

beenthere

Joined Apr 20, 2004
15,819
Well, there really isn't anything in the box but numbers. Granted, an object with defined characteristics is easier to manage than an array and many offset and pointer tables, but it's still just numbers.
 

Dave

Joined Nov 17, 2003
6,969
One point to drop in here, and please feel free to read into this as much as you want; discussing the subject of OOP with a one of the gaffers at work who has a lot of experience in programming software on large projects, he commented that in software systems where security is of paramount importance many of the large businesses specify that they do not want programmers utilising OO concepts as part of the software architecture. Many software-savy businesses see OO languages as too immature to allow for full security across such systems.

I thought it was an interesting comment to make, but am not sure about the accuracy of such an idea due to the fast development of OOPs in recent years.

Dave
 

rjKing

Joined Mar 17, 2007
2
One point to drop in here, and please feel free to read into this as much as you want; discussing the subject of OOP with a one of the gaffers at work who has a lot of experience in programming software on large projects, he commented that in software systems where security is of paramount importance many of the large businesses specify that they do not want programmers utilising OO concepts as part of the software architecture. Many software-savy businesses see OO languages as too immature to allow for full security across such systems.

I thought it was an interesting comment to make, but am not sure about the accuracy of such an idea due to the fast development of OOPs in recent years.

Dave
I've made heavy use of C++ and C# in the last 12 years.. using OO techniques to design entire large high performance systems, and the statement about security being at all related to OO is a bit strange to me. OO is simply a way to ease maintainability and protect portions of your system from change. Nothing in these two languages prevents or obscures issues around performance, security, etc (even though I've heard such statements from many many folks).

Now I can't speak to truly high level languages that isolate a programmer from the machine, so if that is how the statement was meant, your friend may have a point. But OO techniques are mainly about isolating code from change that doesn't need to change.

As a for instance.. some processes have very typical steps that do not change.. parsing and executing a SQL is typically done the same way on all databases.. but the specific details around calling a specific database's low level calls to do this will be different for different vendors.. to an OO programmer, this suggests an object that implements the general steps and collects the standard information, and a set of objects that implements the low level details for each database (what you would think of as drivers or specific API implementations).

Now, when we need a new database driver, we implement another of those driver objects, our general object and the other drivers don't change.. and we've protected a good portion of our system from maintenance problems due to unnecessary code changes (which is the real point).

In no way does OO get in the way of your real needs (unless you misunderstand why its there.. and god knows many misunderstand it).. it just makes doing certain things one heck of a lot easier. I used to use structured programming techniques and function pointers to achieve the same affect years back.. now I can let the compilers do that work for me.. and worry about the real problems rather than having to stand on my hands and do flips in the pursuit of maintainability.

And since no one knows me from adam...

Started programming in 1973 (high school.. in the garage with my Dad who is an EE).. very low level.
First professional programming job in 1983. Done embedded systems, control systems for industrials, mainframe development, high performance DB processing systems. OO for the last 12 years, structured programming design techniques before that.

Richard
 
Top