[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?
- [lmi] Inversion of control [Was: Another large census error with group quotes], Greg Chicares, 2018/09/07
- Re: [lmi] Inversion of control, Vadim Zeitlin, 2018/09/08
- Re: [lmi] Inversion of control,
Greg Chicares <=
- Re: [lmi] Inversion of control, Vadim Zeitlin, 2018/09/08
- Re: [lmi] Inversion of control, Greg Chicares, 2018/09/12
- Re: [lmi] Inversion of control, Vadim Zeitlin, 2018/09/17
- Re: [lmi] Inversion of control, Greg Chicares, 2018/09/17
- Re: [lmi] Inversion of control, Vadim Zeitlin, 2018/09/17
- Re: [lmi] Inversion of control, Greg Chicares, 2018/09/17
- Re: [lmi] Inversion of control, Vadim Zeitlin, 2018/09/18
- Re: [lmi] Inversion of control, Greg Chicares, 2018/09/18
- Re: [lmi] Inversion of control, Vadim Zeitlin, 2018/09/18
- [lmi] Header pagination PR (was: Inversion of control), Vadim Zeitlin, 2018/09/18