Many object oriented programmers start off by thinking what object they are going to use, what the object is going to be called, what the object is going to look like.
Get out of that mode of thinking. Get the implementation started using a small program with some procedures and functions in it. Think about what you are going to get done, not what object you are going to start.
For example, if you are going to be implementing a tool that writes text to a config file, forget about what object you are going to use. Start thinking about what code you are going to write that checks the config file to see if it exists. Think about what code you are going to write to open the config file and modify its contents. The important grunt work needs to be done, regardless. The object just organizes the code.
If your code happens to run, then you can worry about what object you are going to make. You don't even know if your code is going to work, or whether it is going to need workarounds or not. So write the code. If the code can then later be organized neatly into an object, then do so later.
When prototyping peices of a large application, I tend to make small mini programs that I can compile separately, which each implement a peice of the large program. If the small program turns out to work, then I can think about how I'm going to take that peice of code that worked in the small program, and incorporate it into the real large program or object. This always makes my applications more robust - because many small programs essentially make up a big program. Likewise, an object is just a placeholder for a bunch of procedures, functions, and variables.
Don't think of an object as some special magical thing. When broken down into little peices, an object is nothing more than a form of organization.
Most likely, you will have to write methods for your object - which means that you'd be better off testing your methods individually (procedures and functions) before implementing some gigantic complicated object. How does one test certain methods of an object, without having to construct the whole object first? Make a small source file that doesn't use any darn objects - just stick with small, simple programs that use procedures, functions, and variables.
Now some people may be so familiar with object orientation that they start implementing their objects from scratch - designing the object as they go along. But how can one easily take peices of that object and place it into a small test program. Usually, you have so many object reliances that you'd have to test the entire object, not just peices of it. Because an object ties a bunch of things together, it is hard to test certain peices of the object. It is hard to detach code from an object without breaking the object.
When I want to test some code out that checks whether the string 'boo' is in a huge hunk of text, I open up a brand new program and write a small program that does one thing: checks whether or not 'boo' is in a hunk of text. Many object oriented programmers will do it differently. They will start thinking about what object their boocheck() method is going to be in, or whether the boocheck() method is going to be in an object of it's own, a BooObject. All this doesn't matter!
I call the above symptom "premature object orientation". Not to be confused with "premature optimization", although similar in that they are both premature, and maybe even immature.
It doesn't matter how organized John is if he can't fix the damn sink. Grunt work, is more important than organization. Organization helps getting grunt work done, but it doesn't determine whether or not the grunt work can be done.
First, you must get the damn code working in simplest form - then once it is working, you can work on organizing that code.
Note: This advice isn't coming from a procedural zealot. I learned object orientation on my first day of real programming, not procedural and functional programming. I don't come from strong biased procedural background. The above tactics mentioned in the article are what I use to build programs step by step.
If a piece of code doesn't work good in small program, that same piece of code isn't going to work good in a bigger program or a big object. Someone who is a procedural zealot would recommend using procedural code and nothing more - in the above article, I state that it is perfectly fine to organize code into objects. Objects aren't code that gets X and Y activities done, they are just organization structures that can be used to hold the code that gets X and Y done.
|
