lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Inversion of control


From: Greg Chicares
Subject: Re: [lmi] Inversion of control
Date: Sat, 8 Sep 2018 15:19:41 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2018-09-08 13:09, Vadim Zeitlin wrote:
> On Fri, 7 Sep 2018 23:49:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-08-21 12:24, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  I know we've already discussed this in the past, but I still have an
> GC> > impression that you underestimate the benefit of centralising all the 
> logic
> GC> > in a single place with the "template method" approach. Yes, it does 
> require
> GC> > you to use either OO, with derived classes for each use of the base 
> class,
> GC> > or lambdas (preferable nowadays), but IMO it's absolutely not such a 
> huge
> GC> > disadvantage as you seem to believe. While the advantage is real, as we
> GC> > keep seeing again and again, with bugs due to the differences in the 
> "same
> GC> > logic" implemented in different places.
> GC> 
> GC> No matter how many times I try to read that GoF stuff, I can't understand 
> it.
[...]
> I.e. it's really just a dictionary

Oh. I thought it was a cookbook. I made a quahog-and-quinoa quiche with
quatre-épices and concluded that it wasn't a very good cookbook.

> and, as such, there is nothing to
> understand: just some new words to learn, that's all.

(Like that "Bourgeois gentilhomme" quote that I won't repeat again.)

> GC> But I hope that if we start with something that I certainly do
> GC> understand and feel sure you will too--i.e., commit f27b89f1--then
> GC> you'll be able to show me how intruding this control structure into
> GC> page_with_tabular_report::render() (as I hope we can do) would
> GC> constitute this kind of "design pattern".
> 
>  There is a purely mechanical translation of this code into a version using
> this pattern: for every n, replace the code marked with Fn with a function
> call. This function may be a virtual function of some class, in which case
> paginate() function itself naturally becomes a member function of this
> class (OO style) or a callback, passed as an argument to the existing
> function, which remains just a free function in this case (functional
> style).
> 
>  I'm not sure what, if anything, would you like me to do

Right now, I'm just asking you to tell me whether I'm on the right
track. C++ member-function pointers can be unwieldy, so my first
thought would be to use this as a mixin class: make the paginate()
demonstration a member function that calls some new virtuals, then

 class page_with_tabular_report
     :public numbered_page
     ,protected using_illustration_table
+    ,private paginator

and reimplement that class's render() function. And I guess I'll
want a default ctor for class paginator, and an init() function
that I can call from render(). Or does another approach seem
clearly better?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]