Re: Interface without Inheritance
???? Tiib wrote:
On Thursday, 21 February 2013 21:55:11 UTC+2, Rui Maciel wrote:
You've claimed that with templates "nothing of there is as simple to use
as virtual functions", which is quite an emphatic assertion on the
alleged difficulty of using templates.
Can you somehow be more specific in your complaint. "nothing is as simple"
means that "everything is more complex". That was exactly what I meant.
Ages of practice of helping newcomers to gain skill with one or other
are shown that it is so.
<snip/>
If people like you keep reiterating this nonsense of mindlessly telling
newbies to stay away from the templates bogeyman because they are supposed
to be "way more complex" than anything else, even when this assertion flies
in the face of reality, then this nonsense turns into a self-fulfilling
prophecy. Before you know it, that newbie will also be mindlessly
reiterating this nonsense because he says so, because others like him say
so, and because "ages of practice" tells him that the templates bogeyman is
far too complex to be understood by mere mortals.
Do you believe that the example I've
provided is harder to use than an equivalent one you can come up based on
inheritance?
My main() did look really desolate and simple so I think that usage
indeed was easier. Both 'virtual' and 'override' were added to ProductA
and ProductB members just to document indent and may be removed by
language rules. So there remains just declaration of required interface
that is great to have.
You didn't answered the question. Do you actually believe the template
example is harder to use or to understand?
The gang of four book on design patterns refers to the strategy pattern
also
as the policy pattern. The wikipedia article as well. But in this
context, as we are discussing the generic programming implementation,
it's more appropriate to call it by its name, the policy pattern, due to
the chapter on policy-based design that Andrei Alexandrescu wrote in his
??Modern C++ design: generic programming and design patterns applied"
book.
Ok, some sort of contradicting terminology.
You can always get in contact with the team behind the gang of four book and
alexandrescu to tell them they are wrong. But nitpicking about the name of
a design pattern has absolutely nothing to do with this topic.
The example was supposed to be concise and to avoid implementing any
algorithm. If you believe it's relevant to the discussion, rename
"Product(A|B)" to, for example, "ConcreteStrategy(HTML|LaTeX)", tweak the
member functions to output the appropriate preamble, header and document
bodies, rename "ProductOverviewPolicy" to "DocumentOutputPolicy", and
tweak its output() member function as appropriate.
Names impress me not.
It appears otherwise, because you've wasted time complaining about it.
As for what it did achieve ... then it is easier with interface,
(IMHO but YMMV):
<snip/>
Easier where?
Every single bit of it. You just snipped it. :D
The code is available in the server. Snipping redundant content doesn't
hide it from the world.
You had to clutter the source code with an extra class
declaration, you were forced to sprinkle pure virtual functions around,
and
there are override directives everywhere. How did you make that example
any simpler by adding all that unnecessary cruft?
Lets see your complaints.
1) "extra class" is *the* interface specification. In your example
interface was nowhere specified. So why it was easier?
2) "pure virtual" means that if you want to have the interface you must
override it. '=0' is oh so hard to type?
3) "override" means that it implements or overrides base class
implementation. That results with compile time error if interface
is tiniest bit different in derived class. Try edit IOverView:
'virtual std::string name() const {return "";}'
It is making everything very safe and novice-friendly. 8 characters.
4) I also had redundant 'virtual' in overrides, why you did not complain,
another 7 characters? It just feels more readable and safe, both
'override' and 'virtual' may be removed from overrides by language
rules.
You are spending too much time and effort trying to explain your inheritance
example. What does this say about its simplicity? And instead of avoiding
the question, just stop waltzing around the issue and simply answer the
question: is the template example any harder to understand than the
inheritance one?
The generic programming solution achieves the exact same objective, and
is far cleaner, easier to read, and straight-forward.
Food for thought.
Shrug. I still do not understand your objective. If it was to have:
ProductOveviewPolicy<ProductB> overview_b;
overview_b.output(B);
... instead of:
output(B);
... then that feels not simpler to me.
So, is the template example harder to understand, or does the inheritance
example only starts to become as simple as the template one once you remove
any reference to the need of declaring extra classes, adding extra virtual
function definitions and sprinkling overriding directives? You know, the
stuff that is required to make it work.
I feel that you just want to argue. There is nothing to argue, I said
what I meant and even your own example feels
<snip/>
I've asked you a simple question: if you could come up with a policy pattern
which was in any way simpler to read and more concise than the template
policy one. Since then you've posted a relatively convoluted example, and
wasted a hundred lines or so waltzing around while nitpicking about
irrelevant stuff and avoiding to give a straight answer. If you weren't
avoiding the question by arguing irrelevant points then you wouldn't be
complaining about it. So, do you find the template example harder to
understand? Yes or no? Or will you keep waltzing away, arguing moot points?
Rui Maciel