• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 199
  • Last Modified:

I stink with OOP... any input will help!

Hey guys!

it's me again...

I started out as a Pascal programmer back in high-school (this is what i'm blaming my condition on =) and ever since then I find myself writing programs in a very procedural manner, this is not what I like. Okay, I understand the OOP concepts (data hiding, encapsulation, polymorphism)... you guys know the jargon. Well, I have read a few books and they all say pretty much the same thing, as an example:

class tiger is a subclass of feline which is a subclass of animals    or
class square is a subclass of twoDimensionalShapes which is a subclass of Shape

Okay, thats fine and dandy, but what about real programs. Example:

I just wrote a program for the company I work for that automatically detects and deletes log files in X directory. This program has a richtextbox that displays information on how many log files were found, how many were deleted...etc This program has the ability to delete any type of file in any directory (point it to \TEMP directory and have it delete all the .tmp files if you want) This program also communicates with the registry so it can save some values (the last directory that it pointed to...etc)

When I first started this program I had objects in mind... but once I really started getting the code down I was ... oops... going back to the old familiar procedural ways! I found it hard to make really well written objects that could be used in other future programs that I might write. Can anyone help this newbie out!? For some reason I just don't grasp it quite yet... But after all the books i've browsed through I sure can make one hell of an animal hierarchy!

I understand how OOP works, I just have a hard time puting it to good use
1 Solution

practice, practice, practice!

It sounds like a trite answer, but it really is the only way to learn OOP effectively.

For practicing try writing programs that adhere to the following rules:

1) no function will accept more than 3 parameters
2) no function will contain more than 10 lines of code
3) no class will logically exist on more than one tier

Okay, these rules are a bit arbitrary and no real program could possibly adhere to these rules.  Eventually you'll have to break them.  HOWEVER, if you program with these rules/goals in mind you will learn to see objects more readily.

The first two rules are pretty self explanitory, the third is a little more abiguous.  Let me explain...

In a program you generally have at least three layers/tiers.
1) The Presentation layer - This is the GUI, what the users interact with.  This is where the user entered values are validated.

2) The Business Layer - This does all the real thinking and logic checking.  It parses the data and prepares it for display or for execution.

3) The Data Layer - Sometimes also referred to as the execution layer.  This is what actually does something.  You get the data or submit the data to a database here.  No parsing or validation should be done on this layer.

As I said before, with very robust programs you end up violating some of these rules (sorta).  The functions get more than 3 parameters and they have more than 10 lines of code.  But really, a function should only have 10 lines of code that "does something" all other code should really just be validation, looping, or error handling.  As for the seperation of tiers, this is just about set in stone, but you can hae hybrid helper tiers that do cross multiple layers, but they will almost exclusively communicate with a Display/presentation tier class and a Business Tier class.  As kind of a mediator if you will.
well... languages like C# (or Delphi) pretty much FORCE you to use "OOP", because to start, "every" program now has (at least) one class inside

so, you already have the "object", which is the main program, you may or may not need to add more objects (classes) inside, depending on the difficulty

you already know the concept of objects and inheritance etc, so this shouldn't be hard for you, you just need to think in the same way you define tiger<-feline<-animal

in this case, probably all you need is to think of the properties:

TheDirectory should be a property

the methods:
the "procedure" that goes and deletes the files from that directory should be a method

now, what happens if you want your program to be able to delete any number of directories, well, then you create your class inside your main class, lets call it:

public class DirDeleter
- string TheDirectory can be a property of this new class
- void DelFiles() can be a method

done!, you have your class, you can create any number of instances of that class and simply assign the directory initially, then later just call the DelFiles method
you can create an array of that new class and just iterate through it to initialize and later to run

as TAD says... practice... just practice...
later you can add methods to read/write the configuration to disk inside your class, and the code that calls it doesn't change, that's what encapsulation does, you modify a class, and internally it changes, but the code that calls it remains the same

now, if you want to use that class in another program, just put it in a different Name Space, and you can have the exact same functionality throughout different programs just by using that Name Space and class
In my opinion, I wouldn't worry too much about hierarchies and inheritance. Of the three generally accepted features of an OO language (encapsulation, polymorphism and inheritance), I believe inheritance is by far the weakest. In fact, inheritance can break encapsulation (since subclasses have access to superclasses' protected implementation details). Encapsulation is where you want to concern yourself; just getting the right classes. Think of classes being the nouns in your program (i.e. Registry, Directory etc.) and methods on these classes being verbs (delete, load, close etc.). This should help you structure your program.

It does take time. Looking at other well-constructed object models helps too. Try the Microsoft Word object model; it helps you understand the granularity to which you should decompose classes.

Hope that helps.
Poetic, I have spent the last year mentoring a young coder like yourself... they knew the concepts of OO but had not applied them.  He is now very grounded in OO and you can see a great difference in his coding.  One of the main concepts that I had to keep reminding him of is that an Object knows about itself and what it can do.  For instance, does everyone in your office know how much you weigh?  Your favorite food or color?  I would bet not, so how would they find this information out?  They would ask you.  This is basically the same for an object, an object lets call it Poetic would have fields (in the C# vernacular) of weight, food and color.  This Poetic object would have corresponding properties of Weight, Food, Color.  Other objects would not know Poetic's weight, food or color without asking by using the properties.  So when you are developing your objects ask yourself is this information about this object or another?

Inheritance in my opinion is a very powerful concept of OO.  In OO there are basically two types of relations, which are "is a" and "has a".  For instance "a 3000 GT VR4 is a car", however "a trunk is a car" does not work but "a car has a trunk" does.  For inheritance there are basically two cases where inheritance can be used effectively.  One is where the classes are of the same basic type and the other is where the classes have common functionality.  Where the classes are of the same basic type you can inherit from a parent class or abstract class ( a class that is not to be directly instantiated ).  If the classes simply have common functionality but are not of the same type then the type of inheritance that should be used is via an interface, which is basically a group of method signatures that deal with a common piece of functionality.  For instance you might create an IFly interface that is a method signature of fly(),  The reason you would do this is if you are writing an application where you have to account for both Birds, Jets, Helicopters and Baloons.  All of the objects just stated fly but use a different means of flight, however for the puropose of your application you may want to store them in a common storage that you can iterate through and just call fly on the object and it will know what to do without having to first casting it to the proper object... Once I have the hierarchy inplace, I use a bubble up approach.  The bubble up approach is that when I come across a function in a class that other classes may use I maove the function up to the proper parent class thereby getting the benifit of code reuse.

There is a lot more and what _TAD_ said is true you need to practice.  So to recap: 1) An object knows about itself and what it can do.  2) Determine the relation between objects using "is a" and "has a" and if it does not fall into one of these catagories it is simply a uses relation.

Hope this helps...
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now