IMHO, the only time you should combine steps is when each step should always be presented the same way (for instance, some of my nav menu "cells" have different individual purposes, but they all serve the same "general" purpose, so they're coded and styled the same). Either that, or when it's fairly easy to separate the steps back out again if you need to.
Ahhh ok, this is called generalization in object-oriented programming. If different "cells" (also called classes in C++/Java) perform the same method, that method can be put into a superclass, and these classes would be subclasses of it. They would use that same general "purpose", but may do different things afterwords.
Still with me? Say you have three King's Quest games: KQ3, KQ6 and KQ9. All three of them involve Alexander. So, if you wanted to talk about Alex, you wouldn't say KQ3 Alex, KQ6 Alex and KQ9 Alex, in every sentence because it's so redundant. We know it's the same guy! So, the superclass would be Alexander and KQ3, KQ6 and KQ9 would be the subclasses, which would each inherit him. Now you know why he's the royal
heir.
So if you wanted to talk about Alex in general, you'd just refer to Alexander, but if you wanted to talk specifically about when he was a slave, you'd use KQ3.Alexander.
As for program coding, I too know exactly what everything I write does. But the reasoning behind it is that when you're in industry, you're often working with
other people's code. If they didn't comment theirs properly, it would take you ages to figure out why their program does this and that. What I said before is true too, just because you know the program now, doesn't mean you will remember in 6 months or a year from now.
Oh yeah bushie, I LOVE split and merge. It's done wonders already!
