lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Inversion of control


From: Vadim Zeitlin
Subject: Re: [lmi] Inversion of control
Date: Sat, 8 Sep 2018 15:09:29 +0200

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.

 Maybe you're just trying to understand something that is not there in the
first place? IMO the GoF was originally useful not because it contained any
original ideas (unlike, say, "Modern C++ Design"), but just because it
defined the terms for what many people had been using for a long time.
I.e. it's really just a dictionary and, as such, there is nothing to
understand: just some new words to learn, that's all.

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, but I could
demonstrate either or both of these transformations on this example, if
you'd like -- please let me know.

 Thanks.
VZ


reply via email to

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