OOP Programming 3

[IronRocket]

Just wondering if it's just me. I recently took a .net class and got a "B" in it. I learned some OOP in it and I felt I hit a brick wall. For some reason I think I have a mental block in where I can't understand OOP that well.

I've read it over and over again...if I keep my mind from drifting...I still don't understand the concepts. Just wondering if anyone has had the same problem of learning this stuff or if I'm plain stupid.

 

[lespaul]

Join the club!!!! However, don't give up...I'm FINALLY starting to GET IT! I've been programming in Delphi for about 5 years and never really took advantage of some of the OOP techniques that I could have. I found this site specific to OOP in Delphi that REALLY helped me (I wish I had found it a LONG time ago!). But if you don't know Delphi it probably won't help you quite as much.

However, one of the reasons that I have been trying to learn more about OOP is because we are converting to a Java shop and I'd like to implement the class structure and the OOP correctly. Here's another Java OOP site that I found that helped me overcome some of my mental blocks on OOP in general:

http://java.sun.com/docs/books/tutorial/java/javaOO/classes.html

I've also done some lurking in Forum678 and there are some threads there that helped. One of the most helpful examples for OOP (about TBug, TInsect and TSpider) was given to me in thread102-1428280 (it's way at the bottom past the horrible coding issue).



Leslie

In an open world there's no need for windows and gates

http://www.ubuntu.com

 

[CajunCenturion]

OOP can be difficult to get your arms around, especially if you're originally a procedure oriented programmer. You're not alone. It's a different paradigm, but as Leslie says, don't give up because one day, all the pieces will drop into place.



--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[IronRocket]

Thank you very much! I went through some of the threads, and I am seeing that I'm not the only one that is struggling with it. I thought I was stuck on stupid. Thanks again.

 

[DonQuichote]

When I was young, I got a tape recorder. It came with a large (A1 format) electrical scheme. This scheme contained the entire design of the machine: engine control, amplification, tone control (2 times, because it was a stereo machine), etc.

If you open a modern video recorder, you will see something entirely different. There are large components (subassemblies), like a preamplifier module, an engine control module, etc. that are clicked together with plugs.

History went the same for programming. We started with languages like GW-Basic, which were one "recipe" containing everything. But we now have object-oriented languages that allow us to do things in modules (called classes).

Mind you, there is absolutely nothing you can do with object orientation that you cannot do otherwise. You could build a video recorder in just one scheme as well.

So why do we do things in a modular fashion?
[ul]
[li]Because it's less work. This sounds really strange. Designing every component with plugs is extra work. However, if it is done correctly, you can reuse such a component. If you designed a preamplifier module for a CD player, you can use the same component in an MP3 player, a computer, a video recorder, your navigation system, etc. Also, a well-difined plug allows you to outsource such a component or use a ready-made one. The same thing applies to, say, a Database class.[/li]
[li]Because it is testable. If the only signals that a component receives come in trough the plug and come out through it, you can feed that component a known signal and check for the known output. It is quite normal for bought electronic components to be tested before they are built in. However, "unit testing" in software development is still a rare phenomenon. Strange.
By the way, this will only work if there are no hardwired connections between modules and everything really goes through plugs. The "Law of Demeter" guides you to design your classes well in an object-oriented application.[/li]
[li]Modular components have little impact on the rest of the structure. This comes from the fact that a plug usually defines an abstract function. A sound plug only tells you that a device produces or consumes a sound signal. It does not tell you how it is generated. The same plug is found on a CD player, a cassette player, etc. Your wall power socket does not care what you connect to it as well, as long as it behaves correctly. This means that a plug is recongizable, and that components have a responsibility. Google for "Design by Contract" if you want to know more on this.[/li]
[li]Modules are much easier to maintain. Due to their limited implact on the rest of the design, their clickable nature, and their coverager of only a part of the functionality, they can eaily be repaired or replaced. What's more, you don't need to know the insides of a component. The plug tells you enough.[/li]
[li]The responsibility allows a component to do its own optimization. A clock card in your PC might have its own battery, for example. Or a Database class may only open a connection when one is needed.[/li]
[/ul]

Now wait. Do objects have plugs then? Certainly. They are called the interface of the object. The interface consists of all accessible methods and properties (including the constructor). To be recognizable, you should therefore always used meaningful names for methods.
(Do not confuse this with the interface keyword in a lot of languages, which defines a restriction on the interface of an object: the interface should have at least these methods)

Off course, there is a lot more to tell, but this is probably complicated enough already. I hope it clarifies some things.

 

[macleod1021]

There's a Head First book out there (can't remember the exact name atm) that had a pretty good way of explaining things. It looks like it's a huge book but there's a lot of pictures and diagrams to help reinforce the subject matter.

I agree with everyone else...don't give up. Once it clicked for me, I couldn't believe the differences in my code.

 

[LNBruno]

Two (thin) books which really helped me by David A. Taylor:

1) Object-Oriented Technology: A Manager's Guide
2) Business Engineering with Object Technology



< M!ke >
[small]Holidays cause stress. Crazy people crack under stress. Consider yourself warned.[/small]

 

[xwb]

Try writing a simple game. It is your game: no constraints, no deadline and you can make as many mistakes and have as many rewrites as you like.

I picked a game from the Commodore PET called seige. One defender, a castle wall, a missle and several attackers. The defender throws missiles at the attackers. If it hits, the attacker falls and takes down any other attackers in the way. Work out the objects, commonalities, how to draw them, how they move. Stick them in a nice merry loop and away you go. I've done the same program in C, Pascal, C++, VB, PL/M and Fortran while trying out techniques and learning languages. What's good is that you get to play the game at the end of the day. Something completely mindless like tetris but it is fun because you wrote it.

Yes - you can do OOP with a non OO language. Languages without structs like BASIC are a bit more difficult.

 

[gbaughma]

90% of what I program is OOP.

"Oop! Why didn't that work! OOP! Forgot to define the variable... OOP! I just cut a chunk out of the wrong routine....."





Just my 2¢
-Cole's Law: Shredded cabbage

--Greg

http://parallel.tzo.com

 

[CajunCenturion]

==> 90% of what I program is OOP.
Is that an example of inheritance?

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[xwb]

When does it change from OOP to OMG?

 

[lespaul]

when you extend the class....

 

[wlemery]

Yeah, what they said. Don't give up on it, it isn't easy, and you're not alone in this. When I was learning OOP I felt dumber than a box of rocks. It seemed to me everyone understood this concept except me. Then after I got over the hump, so to speak, I realized that I wasn't alone at all.

The real strength of OOP is subclasses and inheritance. I think it's worth mentioning that Micro$oft misused these terms to describe Visual Basic 6 as an object oriented language, and it isn't - you can't subclass in VB6.

If you know C, get a copy of C++, write your own base class of any kind and subclass it about four levels deep. Play around with it a little and you'll catch on.

 

[lionelhill]

There's another barrier to OOP that sits in the heads of some of us.

If you date back to the era when a really fast processor went at 2Mhz instead of 1Mhz, performance really mattered.

Most OOP explanations usually start defining some simple object like a point in graphics. They define a few methods for tasks such as moving the point around the screen. Then they define a square as four points. At this point the 1Mhz-processor-programmer starts getting mild doubts because s/he is busy wondering why we've used 8 numbers (4 sets of coordinates) to define something that only needed 3 numbers (the position of the square and how big it is). We're aware that memory isn't so important nowadays as it was when we had 512 bytes (yes, that was how much I had when I first wrote a program), but we can see where this is going...

Now the OOP book gets very excited, by telling us that square.move will work just like point.move and we don't need any new code to move the square.

This is where the 1Mhz-programmer gets really upset, because s/he is painfully aware that we're now making 4 calls to change 8 numbers, whereas we only needed 1 call to change 2 numbers. We have quite probably quadrupled the time taken to carry out the task (possibly not quite so bad bearing in mind caching issues of modern processors etc.). The worst of it is that in the high level code, we haven't even got the faintest hint of what's going on behind the scenes, so we aren't being warned that our code is inefficient. This feels wrong, all wrong...

If anyone out there can come up with a simple teaching example of OOP and inheritance that isn't blatantly and automatically less efficient than a simple procedural equivalent, I'd be very grateful, and I'm sure I'm not alone.

Obviously programmers' time is important, but so is users', and high-performance programming is still quite valuable when the task is large and the machine is old.

 

[chrissie1]

The right tool for the right job comes to mind. So lionelhill I think you are trying the wrong tool.

OOP comes to it's own in multi-programmer environments were code maintainability and readability is more important then getting the last millisecond out of it. If you work with a group of programmers on the same product then interfaces are a godsent and getting someone up to speed will be faster to.

But for the rest it is a senseless discussion like the one between Java and .Net. And who cares anyway, just get the job done. If they want OOP then better for me, if not then I'm out.

And I hate web-development, talk about hacking to get things done (like: it works on IE10,11 and 13 but not 11a or 12 sorry).

Christiaan Baes
Belgium

My Blog

 

[Glenn9999]

If anyone out there can come up with a simple teaching example of OOP and inheritance that isn't blatantly and automatically less efficient than a simple procedural equivalent, I'd be very grateful, and I'm sure I'm not alone.

That is the major issue, among many. While I understand the concept of OOP, the problem (as I stated in another thread made at this same time) really is to demonstrate any value in OOP over the procedural methods.

In addition to the adding of code/complexity, the question comes of knowledge - OOP makes it so easy to create black-boxes of which the user of said black-box knows nothing of it, and is clueless as to its function. Add to that, that many of the black-boxes are poorly made, hard to use (thinking the Delphi VCL here) and have to be rewritten. Additionally, the code bloat is phenominal (thinking EXE size, which reflects upon code executed) - all it takes is comparing a Delphi VCL program with a Delphi Win API program to see this difference. In fact, I've taken to compressing most of the Delphi VCL execs anymore because they are so big.

Of course, we are in the days of the Microsoft development methodology. As long as it works, it's fine. If it's slow, you can always upgrade the memory and the CPU. If the code bloat is too much, upgrade the hard drive. And if it borks the system, well you can always reboot.

How business readily and cheerfully accepts this out of software development is still a mystery to me.

 

[chrissie1]

In addition to the adding of code/complexity, the question comes of knowledge - OOP makes it so easy to create black-boxes of which the user of said black-box knows nothing of it, and is clueless as to its function.

Sorry but if you say this then you clearly didn't understand the concept of OOP.

Christiaan Baes
Belgium

My Blog

 

[Glenn9999]

Sorry but if you say this then you clearly didn't understand the concept of OOP.

I believe this has descended to the level of holy war now and has gone far beyond any professional level. Windows vs. Linux, IE vs. Firefox. Now this.

 

[CajunCenturion]

OOP comes to it's own in multi-programmer environments were code maintainability and readability is more important then getting the last millisecond out of it. If you work with a group of programmers on the same product then interfaces are a godsent and getting someone up to speed will be faster to.

These tried and true development methodologies and standards were developed along with good software engineering practices in the sixties and seventies - long before OOP came into being.

And thank you, but I do clearly understand the concept of OOP. I understand well to know that not only is it not the panacea that many make it out to be, but why that is the case. For example, let's look at encapsulation and polymorphism. On the one hand, OOP enthusiasts touts the value of encapsulation, shielding the inner-workings of the object, thus saving the programmer the need to be concerned with inner behavior details. On the other hand, others extol the benefits of polymorphism, providing flexible object foundations that programmers can inherit and customize to desired behaviors. So right off the bat you have a trade-off decision to make about the opposing attributes of encapsulation and polymorphism. Should you focus on small, stable, and encapsulated objects, or large, open, and flexible objects? Probably you're somewhere in between, getting the best of both worlds, but at the same time, you're getting the worst of both as well.

Any experienced software developer should be able to tell you that the cost of modifying a program is nothing compared to the cost of modifying the database. Similarly, the cost of modifying a program is considerably less than modifying your object foundation.

There are some real advantages to OOP, but there are also drawbacks. Sometimes the best data structure for an application is an array, sometimes a stack, sometimes a queue or deque, and sometimes a tree. And yes, sometimes an object is best. I think wise programmers know when to use objects, and when not to.

--------------
Good Luck
To get the most from your Tek-Tips experience, please read
FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[chrissie1]

Like I said.

But for the rest it is a senseless discussion like the one between Java and .Net. And who cares anyway, just get the job done. If they want OOP then better for me, if not then I'm out.

Christiaan Baes
Belgium

My Blog