Some excellent OO programming tips (and discussion)

Some classy advice from munificent on a proggit thread:

• Do not copy and paste. Move code around, but don't duplicate it. Disabling Ctrl-C on IDEs would improve the world's programming better than anything I can think of.
• Decouple decouple decouple. Of all of the things you can do to improve code, reducing coupling will, by far, have the greatest impact at making your life better.
• Don't store what you can calculate. The fewer member variables, the better. Avoid storing any redundant data unless you want to fix synchronization bugs forever.
• Make classes immutable when possible. It's easiest to use something you can't break.
• Don't get too excited about inheritance. If you aren't using polymorphism, you probably don't need to use inheritance.
• Use all of the features of your language. Delegates (function pointers), static (i.e. non-member) functions, etc. are just as useful with OOP as within straight procedural.
• If you have a hard time naming a class, it's poorly defined. That being said, don't let lack of a name stop you, you can always find and replace later. Likewise, rename classes if their purpose changes over time.
• Never call anything "FooManager". Objects are supposed to manage themselves. Get rid of the manager and put the code in Foo.
• Don't be afraid to make little classes. Making a class just to bundle a couple of function args is perfectly fine. A few months later you'll find you've all sorts of other usefulness to it.
• Refactor constantly. Coding without refactoring is gardening without weeding and pruning. You can't just keep packing new plants into your yard.

There is some good further discussion and qualifications in the sub-comments.

Alan Kay's Reading List

Alan "Smalltalk" Kay gives a list of books for people interested in the ideas and philosophies that influenced Squeak. It looks like a good list for anyone interested in software invention.

I have read a smattering of the books and some other works by authors on the list, and they were generally outstanding. I will try to sample the remainder (over time).

A witty remark

The other day I was standing in my bedroom, and went to take a step, only to find that I could not. My son, Jake, aged 4 1/2, was lying full length and prone on the floor with arms extended and both hands securely clamped around my left ankle. Andi looked on. This had happened before.

Jake ordered me to drag him along the floor: "Walk!", came the command from below.

"I refuse to walk anywhere while there's a manacle attached to my leg", I replied.

"That's not a manacle; that's a boy-acle!", said my beloved.

Laws of Logins

Privacy issues aside, when it comes to logins, I want convenience.

When using a web-page that provides a service, I want it to:

1. Allow me to try or taste the service without entering a username and password (or I won't it use it).
2. Never supply username and password if the service is once only (or I won't use it).
   
3. Allow me to login and use a nice administrative interface if it is a site that allows me to create content. For this, I not only accept having to supply login details; I want to be able to login.
   

Of course having to remember multiple logins for multiple sites (point 3) is a PITA. Can OpenID help with this?

Order-dependence of design decisions

When the proggit community was asked for their best piece of Best piece of insight for computer programming/software engineering? some excellent responses were elicited, including this one from hamsterboy:

The quality of the design of a piece of software depends on the order in which you make the design decisions. 5 years from now, the earliest decisions will have the most far-reaching consequences, and will be the most difficult to re-think.

This can be taken incorrectly as an indictment of incremental approaches or, more acutely, as justification for periodic re-design.

Recently I have been working on a port /re-design of a 2.5 year-old product and it has been an absolute pleasure to be able to take advantage of the insights learned the first time round.

Where did the red hair come from?

Here's a picture of my kids, both of whom are gingies:

Ella (left) and Jake

Since neither I nor Andi (Mum) is a red-head we are incessantly asked "Where did the red hair come from?"

Popular answers include:

• Postman Pat
• Alien abduction
  
• They are freaky mutants
  

Incidentally, none of their grand- or great-grand-parents were red-heads, but they have a few carrot-headed cousins.

Apparently the genetics of red-hair is not simple. In particular, it is not just a case of a recessive gene hiding away for a few generations.

Andi and I are not planning any further children. I have suggested that we try for a non-redhead, but the danger of a third gingy has proven to scary.

Jake's 10 Commandments

As part of this year's Shavuot celebrations at my son's kindergarten every child devised his or her own version of the 10 commandments. This is what Jake came up with:

Jake's 10 Commandments

1. No jumping on other people.
2. After eating at kindergarten please have a drink to wash down the food that is stuck in your teeth.
3. No poo-ing in your undies.
4. I will not bend my glasses.
5. My sister cannot slap me.
6. I will not take the mattress off my bed and throw it on the floor.
7. Do not slam the door on somebody's fingers.
8. No touching the stove when it is on.
9. No screaming.
10. No tipping water out of the bath.