Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Becoming a better programmer (Re: Learning OOP)

by dragonchild (Archbishop)
on Jun 26, 2003 at 12:14 UTC ( #269208=note: print w/replies, xml ) Need Help??

in reply to Learning OOP

The Principles of OO:
  1. When you abstract out an operation, try and keep similar operations together. Likewise for data.
  2. Similarity depends solely on how easy it is for the developer to grok it. Everyone thinks differently.
  3. 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:

  1. 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.
  2. 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.)
  3. 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.)
  4. Find, purchase, and read a good book on designing tests. This is a lot harder than it looks.
  5. 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.
  6. 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.
  7. 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.

  • Comment on Becoming a better programmer (Re: Learning OOP)

Replies are listed 'Best First'.
Re: Becoming a better programmer (Re: Learning OOP)
by BrowserUk (Pope) on Jun 26, 2003 at 12:24 UTC


    I wish someone had given me those 7 Easy:) Steps when I was starting out. It sure would have saved a lot of blind alleys.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://269208]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (9)
As of 2018-05-24 13:05 GMT
Find Nodes?
    Voting Booth?