The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
getting my head around OOP
krush
Registered User regular
Registered User regular
being that I'm pretty old-school when it comes to programming, I've never done any OOP. I've done C, Pascal, and old-school Basic, but never got into OOP. I'm trying to pick it up right now to learn Java, but getting my head around the need for OOP is stumping me.
Anyone got any insight on how to get my head around the whole concept of OOP? I'm firmly a structured programming guy and just can't seem to "get it".
Anyone got any insight on how to get my head around the whole concept of OOP? I'm firmly a structured programming guy and just can't seem to "get it".
krush on
0
Posts
When I first started doing OOP, I actually found classes almost easier to think of as a struct from C, except it can have functions in it.
Looking at the world as base objects.
Cat, dog, giraffe > Mammel
Car, truck, suv > Vehicle
The rest of it comes after you understand that concept. For instance, polymorphism is the expression of a cat,dog,giraffe as a mammel. So encapsulation and and inheritance play a big part as to what's exposed and how you access it.
Vehicle->Go() would be a function you might have. So if you do something like Vehicle = new Car(); and using the Go() method, you could access all common objects the same way (and organize them for that matter) and call their appropriate methods. So calling Go() would call, Car->Go();
Hopefully that made it a bit more clear for you.
First would be a Class. OP, what is your understanding about a class?
Each class is basically it's own little space, with it's own unique variables and values, and each object you make will be separate from those same objects. So you define everything in a class, and you form new objects based on the classes (practically like you already do defining any other variable).
Each new object's variables are independent of each other (be just like having separate little programs).
So:
ClassA objA = new ClassA();
ClassA objB = new ClassB();
You still treat these like a procedural program, nothing is changing in that regard, you still access them like you would other variables/pointers too. Just think of them as little compartments of code, I guess.
not much of anything other than what was posted a bit earlier.
Doberman, poodle, german shepard belong to a class of objects called "dog".
What I don't quite get is how this relates to programming.
I haven't dusted dusted off my old C skills in years... almost a decade really, so I'm guessing I'm just a bit rusty in this way of thinking.
Those are all expressible as dogs, and all inherit from dog. In terms of programming, all dogs need to have the same functions/variables (and can have more) and putting a doberman or poodle into a variable of type dog (as opposed to like int or string, same concept) can use those base functions.
That responsibility could be very low level (this class represents data, e.g. a stock - symbol, last price, close price, etc), or very high (the order manager places and tracks changes to stock orders), but it should have a clear purpose.
Another thing to remember is to separate data objects from things that operate on the data. Putting the logic for how to place a stock order on your stock class might sound like a good idea, but it is much better suited on an object whose responsibility it is to place and manage orders. Limit the methods on data classes to only operating on the encapsulated data. That way you can reuse these data objects in other projects or even other parts of your application.
This might be elementary also, but in general, if an object depends on another object, your options are to either create it in your class, or pass it in as a parameter to the constructor or a method. If you pass it in instead of creating it, it isn't your responsibility to free up the memory when you are done with it (especially since someone else might be using it also). If you create the object in your class, then it is your responsibility to free the memory when you are done with it.
I hope that wasn't too complicated.
I guess it just seems like simple stuff is made more complex by OOP.
For example, if you're writing a simple game, before you might have had a struct player with an int for points, char[] for name, int current_level, and so on. Then you would have maybe player.h and player.c which define functions such as setPlayername() and incrementPlayerPoints() or whatnot.
Now, you have a class called Player, probably in a file called Player.cpp or Player.java or whatever. It has the properties of int points, string name, int current_level, and so on. The same things as were in your struct. It also has several methods (or functions), which mirror the stuff that was defined by player.c and player.h before.
Of course, based on what you've said about your C experience, maybe comparing to the old C way of doing things isn't so helpful?
The easiest way to get it might be to write a simple program where you have to create your own stand alone class in something that really enforces OO like Java.
Understanding the four pillars is the hardest part, and the hardest part is usually because school or books give you this huge unnecessary description and example.
It's probably easier to just force everything you've learned about programming out of your mind and try to start OOP with a clean slate. As you said, you're rusty enough with the structured programming way of thinking, so by trying to make comparisons or judgements you're just hurting your ability to learn.
But complex stuff is made much less complex with OOP.
OOP is for taking hundreds of bits of code that do simple stuff and combining them into a huge program that doesn't melt your brain when you try to understand it, and doesn't break in bizarre ways that are a nightmare to debug every time its changed. You aren't going to see the benefits until you start going beyond examples and actually write some stuff with it.
Let's start with a class called LivingThing. Each LivingThing is capable of accomplishing 7 things important to their continued survival: Movement, Respiration, Sensitivity (sight, smell, taste, etc), Growth, Reproduction. Excretion and Nutrition. For each task it has a separate method, named more or less the same, but because each creature does things in different ways to other creatures, you'd need hundreds of thousands of different variations of LivingThing to cover all of them. Instead the class LivingThing would contain 7 variables which are references to objects of another class (MovementType, RespirationType, etc) and each of the 7 methods would just refer to those objects to figure out how to do them.
Just like so
MovementType *_movementRef; void LivingThing::Movement () { _movementRef->Move (); }Yes, there'd probably be other things going on involving positions and returned data that it would do something with, but we can skip all that for this example.
Sticking with Movement you'd have a Base class called MovementType which would contain an empty method Move as a placeholder. This is so that all the classes which are descended from MovementType (Inheritence) must detail how this method works. Let's say there's 3 different types of movement that all living things can do. MovementWalk, MovementSwim and MovementFly. Each of these would inherit all the variables and methods held by MovementType (in this case just 1 empty method) and must detail their own Move method.
The NutritionType class would work similarly with the method Consume with several other classes descended from it named along the lines of NutritionVegetarian, NutrtitionCarnivore and NutritionOmnivore, each one adding some actual code into their Consume class.
The key point here is that the original LivingCreature class only contains references to the base classes such as MovementType and NutritionType, which means it can point to any object of that type, or any type that inherits it. This way you have a whole bunch of LivingCreature objects which act radically different without having to rewrite a bunch of code. You can even add in other methods to change these object references so that a LivingCreature which used to hold a reference to MovementWalk could change it to a reference to MovementFly without having to recreate the original object.
Hoping that helps.
and that's kinda what I've figured I would need to do, except that the old way of thinking keeps coming back into play with every thing I read.
now imagine Rex and Killer are two dogs, you would say they are children of the parent class dog. If the dog class allows barking, our two children will also be able to bark. Lets say you need to make them also pee. Instead of adding a pee method to each dog class, just add it to the parent.
Tada. OOP.
know what... that made a lot of sense.
So then, if I want Rex to be able to wag his tail, but not Killer, I add the tail wagging method to Rex only... Right?
In simple terms, think of a database table called 'Products'. Each row of the table would be a Product object, and it would contain information about that product as members (such as Price, Name, etc). The product object might also have a method LoadData(), that takes the raw database information and puts it into the member variables. You could have a ProductController object, which deals with adding, removing, or updating products in your table. That object would have methods for things like SaveNewProduct(), DeleteProduct(), or UpdateProduct(), and instead of passing all the data as parameters, you simply pass the complex object to the controller. In this way, you create abstractions and benefit from other objects. A product could have 10 pieces of data or 1000 - but as long as you can group it together as a 'thing', it simplifies the visualization. A lot of your initial programming will be utilizing objects created by the framework. You don't have to know how the work, only that they do if you pass them specific data or call them in specific ways.
Now, the benefit of this is that you can take advantage of polymorhpism (overloading methods) and inheritance to easily create new relationships between your data and provide new functionality easily to your objects, and by definition, your programs. And because you can abstract away functionality, taking advantage of object relationships means maintaining your programs is easier.
OO Analysis and Design with Applications (3rd ed), Booch et. al.
Particularly the first section. The first chapter will explain why OO is necessary for larger projects, while the old-school method of structured programming that you are familiar with traditionally breaks down around 100,000 lines of code. The second chapter will give you the fundamentals of OOP (which is what you're trying to get in this thread). The third chapter will then expand on the building blocks described in the second chapter. The fourth touches on some different ways of breaking down a complex problem intelligently into the building blocks from Chapters 2 and 3.
The remainder of the book deals with the lower-level details of implementing an OO design (both in representation through graphical models and actually getting a group of people to function in an OO world). But for starters you really need to get a grasp on the stuff in Chapters 1-4. I promise you that unless someone types out all the info from Chapter 2 at the least in here, you haven't gotten the whole picture yet.
I want to be absolutely clear that I'm not disagreeing with anyone in this thread, just that gaining an understanding of this requires more than a patchwork of advice from different people.
PSN: TheScrublet
That actually happens quite a bit.
People use OOP about three times as often as they need to, in my experience.
Hm. I've actually found that OOP tends to make things easier on the programmer, but can result it things that are poorly optimized.
GT: Tanky the Tank
Black: 1377 6749 7425
It also makes it really easy for bad programmers to write a whole bunch of code that works perfectly well together, but any time you need to add anything on is a horrible disaster.
Well. No, not actually.
In this example Rex and Killer would not actually be children but just variables. Like if you'd say int b is a variable b of type integer. With the dog example, you'd have: Dog rex, which would be the variable rex of type dog.
And you'd want "Wag()" as a method in the dog class itself. But if you only wanted rex to wag his tail, you'd only call it on rex.
Defining rex as a child would be the wrong way to do it in OOP. Parents and children are synonymous with inheritance. A child class inherits from the parent class. In my previous post, the children class would be the poodle and doberman because those are an extended type of dog. Doing so for each variable type will get really confusing, really fast, and is ultimately the wrong way to do it. Rex and Killer are most definitely "dogs" though, so you can define them as such.
Edit:
For instance, the dog class could look like this:
class Dog { public Dog() { //create the object, base constructor } public void Walk() { //dog walks here } public void Wag() { //dog wags tail here } public void Bark() { //dog barks here } }You want to define methods that dogs do. So that way if you need to change something you change it in the class and all variables get updated to use those new methods. If you don't want rex to bark, don't call his bark method. Each method will act independently on the variables to the class, so each variable you define as dog has it's own separate wag,walk,bark methods and internal variables that all those methods work on.
Read http://ruby-doc.org/docs/ProgrammingRuby/ or http://www.codeguru.com/java/tij/ - they're both incredibly well written guides to OO languages that are designed for people just like you.
I'd advise the ruby path - dropping the type safety really makes the power of what you can do with OO apparent, but not sure whether jumping straight there is the best approach.
Play with me on Steam
The reason good concepts are founded on them is because you can see the logic behind using a dog class. And how inheritance can play a key role in defining, say, a poodle.
This stuff becomes much, much, less clear when you start talking about buttons. Or the good ol' tried and true polygon / area / perimiter example that I've seen in every OOP course I've taken.
My own dog example, since all the cool kids are doing it (in C#):
public abstract class Dog { protected name; public Dog(string name) { this.name = name; } public abstract void bite(); public abstract void bark(); public abstract void pee(); } public class Doberman : Dog { public Doberman(string name) : base(name) {} public override void bite() { Console.Write("{1} bites your fucking arm off!", this.name); } public override void bark() { Console.Write("{1} barks - it's a feral, frightening sound!", this.name); } public override void pee() { Console.Write("{1} pees - the stream punctures a hole in the very earth!", this.name); } } public class ToyPoodle : Dog { public ToyPoodle(string name) : base(name) {} public override void bite() { Console.Write("{1} tries to bite you, but grows frightened and pees.", this.name); this.pee(); } public override void bark() { Console.Write("{1} attempts to bark, but cowers in the corner instead.", this.name); } public override void pee() { Console.Write("{1} lets forth a pathetic trickle.", this.name); } }8-)
It certainly can make things easier. The problem is that people tend to only think of using OOP to solve any given problem, when it's certainly not always the best solution.
Example: people at work freak out when I write module-level functions in python, because they only do OOP. My boss made me put them all as methods in a useless container class.
But writing functions outside classes is dangerous. If it wasn't dangerous Java would let you do it, but Java doesn't and Java knows everything.
Dangerous!
Handy flowchart:
Do you hate yourself?
Yes
CPP
|
|
|
No
|
|
Ruby=Python>Java
hahahahaha....
ok, ok... But I'm hearing increasing amounts of C# being talked about around the watercoolers, is that any good???
This is the revised flowchart.
I recommend C#. C# is like Java, but without all the dumb. And if you're not targeting multiplatform, it's a better solution.
I like C#, but I haven't played with either Ruby or Python yet, so I can't compare them.
C# is nice in that you don't really have to worry about the minutia of memory allocation/deallocation (although you can use pointers if you want), and a lot of the pass-by-reference/value stuff is handled behind the scenes (you still need to keep track of what a value type vs. reference type actually means).
It's nice not having to write a copy-constructor all the time.
I'm normally a Linux guy. I write Perl all day for my job. I like C#. Guys like me don't ever admit to liking anything MS. That tells you how awesome C# is.