First let me comment that there is a bit of a bait and switch here. Not long ago you were suggesting using objects to allow polymorphism on tag recognition. I pointed out why that wasn't a good place to put an abstraction layer. Now you're suggesting using objects to hide the overall engine. That's a change in design.
Secondly it seems to me that you're having trouble recognizing abstraction that doesn't come with an OO bow tie on top. The style of programming used in that example offers equivalent if not greater opportunities for abstraction than OO does. Admittedly you abstract in different ways in different places. You have more flexibility in how to abstract at a cost of not providing a standardized framework for others to recognize. But under-abstraction is not a problem with that style.
What flexibility would you hope to gain in this specific situation by wrapping the interface with an object? Make that clear and I'll show you how to do the same thing without objects. Please trust me when I say that I am not taking this position out of any ignorance of how useful OO can be. Quite the reverse in fact. I believe I can quite honestly say that I understand OO much better than most programmers and I understand a number of other programming techniques as well. Therefore I am in a better position than most to decide when OO is the right abstraction technique to look for.
For more on the general limitations of OO as an abstraction pattern, The world is not object oriented may be of interest. But, lest I sound entirely negative about OO, I should hasten to add that there are cases when I think it is appropriate and useful. One important example being when you have a series of different decisions that need to dispatch in a coordinated fashion. In which case you can do the dispatches by making method calls on objects.
For the record I am not alone in my views. The ever quotable Paul Graham has even stronger views. They were quite quotably stated in his essay The Hundred Year Language:
I don't predict the demise of object-oriented programming, by the way. Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations. Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.Now it is easy to dismiss Paul as a gadfly, or to assume that he doesn't know much about programming. But before doing so I really, really, really recommend reading his On Lisp cover to cover with comprehension. Once you see how he tackles a variety of problems using different techniques, you may take more seriously his contention that OO's toolkit is not the only, and is often not the best, way to approach problems. (Incidentally in one example he implements an admittedly basic OO system in 8 lines of code. He then shows how to add features to it.) While you are at it you may wish to read Structure and Interpretation of Computer Programs for a related but somewhat different set of approaches to abstraction. (That book is intentionally more introductory.) If reading Lisp is a block for you, Higher-Order Perl covers related ideas in Perl.
Those are, of course, all oriented towards a functional style. But there are perfectly good abstraction techniques for straight imperative code. The classic Code Complete 2 has as good an explanation of the basic ones as anything else does. Be warned that it is a weighty tome, but in my opinion virtually everything in that book is something that every competent programmer should know inside out and backwards. Even if you know 80% of what is in that book, the remaining 20% makes the purchase and reading worthwhile IMO.
In reply to Re^9: replace conditionals with polymorphism
by tilly
in thread replace conditionals with polymorphism
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |