|
Re: The Price Of Two
|
Posted: Jan 5, 2005 5:53 PM
|
|
> > I agree. Those are all important, but in this case I > > think that the programmers could've avoided a bit of > > trouble if they picked their abstractions more > carefully. > > One thing that has become more apparent to me as I > practice object-oriented programming more is that it is > important to pick the right abstractions. Rarely are the > types built in to a language good abstractions for a > business problem domain. However, I have never learned to > pick the right abstraction in advance very well, so I do a > lot of refactoring. But who was it that said, "you're a > lot smarter than me, so we'll try it your way."?
I should've said constructs above rather than abstractions. Sorry.
Here's the thing.. I assume all abstractions are going to change. Sometimes I'm surprised and they don't, but on balance many do. Knowing that, there's a bit of a payoff in avoiding overly specific constructs.
Sure, it is easy to use a std::pair in C++, but you have to watch it. If you use it in too many places, the price gets higher when you want to add the third item. std::pair doesn't handle third items very well. But, a class like this:
class Whatever { string user; Subscription sub; };
It scales beautifully. It handles a third item well. All you have to do is add it. This isn't to say that pair doesn't have valid uses, but it's great to avoid putting up roadblocks unless we have a very good reason.
|
|