in reply to
The Principles of OO:
- When you abstract out an operation, try and keep similar operations together. Likewise for data.
- Similarity depends solely on how easy it is for the developer to grok it. Everyone thinks differently.
- Once you have a bunch of specialized objects, you ask them to do stuff for you. (If you're really nice, they'll actually do it.)
That's it. It has nothing to do with a language and everything to do with a philosophy. OO theory is over 40 years old. OOP can be done in C, Fortran, and x86 assembler.
Confused? Think about it this way - why were the first OO languages designed? It was because someone wanted to express an idea more easily than he could in the languages he had at hand. The idea predates the language.
A better plan, imho, would be to understand the paradigms of programming - imperative, object, functional, and logical. Once you understand those (and how Perl allows you to do any/all of them as you choose, with appropriate modules), then you will be fine.
Now, if you want to make yourself a better programmer, try this:
- Purchase and read Code Complete, by Steve McConnell. And, I mean read every single word. It'll take the average intelligent reader about 3 months. This is the seminal work on generalized programming how-to knowledge.
- Borrow and read The Mythical Man-month. This will give you a true understanding of project management. (Why should you care? Anything that isn't a one-off is a project, whether you know it or not.)
- Find, purchase, and read a good book on problem analysis. (This will, most likely, be in the mathematics section, not the programming section.) I apologize for not having any titles at my fingertips. (Why should you care? Every single thing you write is a solution to a problem. If you don't know how to solve problems, you can't design good code.)
- Find, purchase, and read a good book on designing tests. This is a lot harder than it looks.
- Ask a million questions on Perlmonks. Even better is to answer a million questions, especially when you answer them wrong. PM is one of the few places where you will be corrected gently, if it seems that you're actually trying.
- Learn LISP. (I'm at this step, myself.) The lambda calculus is arguably the most important foundation of program development. Not knowing it is like being a architect without an understanding of the tensile strength of various materials.
- Finally is to avoid buzzwords. Who cares if your program is(n't) OO? The primary and most important feature of a program is correct execution.
We are the carpenters and bricklayers of the Information Age.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.