When do you use OOP?

[benmartin101]

Is OOP always applicable to every programming? When should you apply OOP?

[Vbstr]

Useful in games, or complex apps. Personally I have no use for OOP, is more complexity than I like.

[Nightwalker83]

No, it is only used sometimes particularly when you need structure in your code. If you were creating a VB6 program for example using OOP is not the best way to go about things since it uses the C.O.M (Component Object Model) whereas .NET uses Object Oriented Programing (OOP). That being said I think C++ uses an older model rather than .NET? According to some sites I found on google.

[moti barski]

when your code is very massive (about over 800 lines)

[Shaggy Hiker]

I think .NET is more pure than C++, but I think the .NET model might be older, technically. It shares some similarities to SmallTalk, which was a pre-C++ pure OO.

As for whether it is applicable to every program, that's a hard question to answer. If you have ever used a UserType (or whatever they were called) in VB6, you have used some aspect of OO, since that is effectively the same thing as a class, which is the foundation of OO. If you have ever used a form, you have used some aspect that could be OO, because forms and controls on forms make more sense as objects than pretty nearly anything else. Modules in VB6 can be used to emulate OO concepts, as well, though they don't do so naturally, so you have to use a bit of discipline to use them that way.

That last point may be the key one, too. OO can cause more problems than it fixes if used poorly. Some projects go too far with OO, making huge class heirarchies that become so heavy that maintaining the heirarchy is as difficult, and as essential, as maintaining the program itself. There have been some books written about OO horror stories surrounding designs like that. Personally, I don't like to ever go more than one level with inheritance. There is a base class, and at most one other set of classes that derive from that base class. I've never found a need to go beyond one level of inheritance, though if you look at any OO language, such as C++, any .NET, or SmallTalk, you'd find class libraries where there are several levels of inheritance. Still, even sticking with no more than one level of inheritance, you get all of the features and benefits of OO design. That doesn't mean that all of the features of OO are used in every program. Most of my programs don't use runtime polymorphism, for example, but there are times when it is highly useful, in which cases I use it. Still, even in those programs that don't use that feature, I still get the encapsulation of data with methods that is the core principle of OO. You can do that, to some extent, in VB6, as well (modules). The only thing that OO really does is formalize adherence to those principles and extend the concept to allow for inheritance. Every other feature of OO that I can think of at the moment is in some way a derivative of that formalized adherence to the encapsulation of data with code into objects. Even inheritance is a conceptual derivative from that core, since, once you start talking about an object, you get talking about types, and inheritance is a means to turn our fairly fuzzy language that we use to describe things, into code constructs. For example, we might talk about a fish as being an object. That's great, it has data such as weight, number of fins, and so forth, and it has methods such as Swim, Eat, and others. However, then we get talking about different types of fish like salmon and bass, so inheritance is just about allowing that a salmon is a fish, and a bass is a fish. We can now talk about salmon and we can talk about fish. So inheritance is just encapsulating the way we use nouns. Those nouns, themselves, though, can be found in pretty nearly every language. In languages like VB6, you can have the same concepts, but unless you specifically put the variables and the methods for fish in a single module, they could be scattered all through the program.

So OO is just a means of organizing, and adding some features that arise from that organization. You could do that organizing in any language. If you do no organizing, that's not so good. Whether you use OO-like organizing is up to you in VB6, and enforced in .NET or SmallTalk. In C++, the organization is only semi-enforced, as you can have true global variables outside of any object.

[Max Peck]

I won't try to repeat your "mouthful" there Shaggy ...

Suffice it to say that OO is really just another way of organizing your code and data. I, at one time, said "I have no use for OO" until I realized how powerful OO can be. At the same time, however, you can paint yourself into a corner if you try to overuse it. To me it's like any technology - if its use makes life simpler then use it, otherwise don't. I have also learned (by trial-and-error) that there's no way you can know how it all works. The best thing you can do (IMHO) is to get some exposure to it through study but pick and choose the pieces that solve your particular problems. No way to keep it all in your head.

Having learned how it works (generally) I have found that I can take old legacy sections of code and vastly simplify them. I maintain an extremely complex rules engine for our company and have found that I have been able to conceptualize things using objects where such conceptualization took massive amounts of code in the past. OO is a concept that rocks when you're trying to chop a complex problem down to size but, as you stated, it can often make life more complex if used inappropriately. There is a lot of code in our system (in VB6) that was attempted in an OO fashion when standard procedure-based coding would have been far more efficient.

Back in the 70's we used code libraries and "subroutines" to "encapsulate" things. Now, OO provides a more "elegant" way to do this by allowing you to create "objects" with "behaviors" and the ability to group and replicate them. It's not really new, it's just another way of packaging what we've always done in a form that allows us to abstract away the details of implementation. It's like anything else: you build tools that make the tools that make the tools that make the tools.

-Max

[Shaggy Hiker]

I won't try to repeat your "mouthful" there Shaggy ...


-Max

Heck, neither will I. Got on a roll there.

[benmartin101]

Thanks for the input, guys. It's been helpful.

By the way, what's the different between C.O.M. and OOP?

[Shaggy Hiker]

The two aren't very similar. COM had to do with accessing Windows resources. It was always, to some extent, external to your program, whereas OOP is a design philosophy that can be implemented down to nearly the smallest granularity of a program. COM makes for an interesting read, but it is too unlike OOP to even begin to compare the two. Kind of like comparing an apple to a basketball: One is round, the other is round-ish, and beyond that the comparison just gets silly.

[FunkyDexter]

Aaarrrgghh. Personally I think the phrase OOP should be banned and anyone caught using it should be shot into the sun.

Why? Because P stands for "programming" and, for most of us, programming tends to mean implementation (it shouldn't, but it does). OO is nothing to do with implementation. It's a design methodology. We should talk about OOD not OOP.

Too many devs forget this and think that, by arranging their code into classes instead of modules they're doing "Object Orientation". They're not. And if you ever find youself talking about whether a particular language is object orientated or not, you've almost certainly fallen into this trap. It is possible to do Object Orientation in ANY language - it's just trickier in some, like VB6, because they don't support some of the OO tools (like inheritence, constructors etc) out of the box. More accurately they don't enforce them. It was always perfectly possible to implement inheritance in VB6 using pass-through methods. You could achieve the equivalent of parametised constructors by simply writing a "Set_me_up" method which you always called after you instanciated an object. None of this was enforced and you had to be careful as a developer, but it was perfectly possible to fully implement an object orientated design.

That's another way of saying what Shaggy and Max are already saying but I just wanted to make clear it's about organising your ideas, not your code.

[Shaggy Hiker]

VB6 also didn't really encapulate code and methods that work on the code. You could simulate that with care, but you had to enforce that simulation yourself. All variables in VB6 were global, in effect.

However, my objection to the whole OO (whether D or P) is that the idea has been co-opted into other realms. An Object Oriented interface is one that deals with visual objects. That has nothing to do with OO design. So I guess the phrase practically means whatever you want it to mean, by this time. It has passed out of the realm of proprietary meaning and into the public domain where it can be stretched and molded to fit whatever is desired.

[FunkyDexter]

VB6 also didn't really encapulate code and methods that work on the code

Not sure what you mean there. Do you actually mean state rather than code? If so then I'd disagree, you could declare a var as private to a class. Or are you refering to pre VB6 when it was all in modules? Or (and this is far more likely) am I just missing the point?

So I guess the phrase practically means whatever you want it to mean, by this time.

You're 100% right there but that's also the problem. That's why I feel the urge to kneecap anyone who miss-uses the term. You mentioned that huge inheritance trees can become problematic but I think that's subtely wrong. Poorly designed trees are problematic, and a being overly big is often a sign of a tree that's badly designed. But the whole VB framework is basically one heeeuuoooge inheritance tree rooted at Object... and it works just fine because it was well designed.

It's when people get hold of OO tools and decide to use them at the implementation stage without realising they're there to support decisions made at the design stage that the problems occur.

Come to think of it, it's just a symptom of a larger problem which is probably responsible for 90% of the garbage code out there. Programmers who hear about a new tool or concept and just start using it without bothering to understand why first. The overly-keen pin-head is a far more dangerous beastie than the plodding dinosaur IMO.