Can someone explain when would I want to prefer one over the other?

Thanks,
-Chris

Why one or the other?

DI essentially just says (one interpretation) that the agency in charge of
creating objects and tying them together should not be the
(base/domain/business/bean) objects themselves.
Factories can be seen as just accessors and modifiers (getters and setters) on
object in the process of being created.

In fact, just the other day I used a static factory for to create objects for
Spring (java) to inject (because I needed an parameter of type Class<T> which
Spring has a little trouble with).

Thanks,
--Allan

--- On Mon, 1/25/10, chrishand40 <cj.hand@...> wrote:

> From: chrishand40 <cj.hand@...>
> Subject: [leanprogramming] ClassFactories vs dependancy injection
> To: leanprogramming@yahoogroups.com
> Date: Monday, January 25, 2010, 9:44 AM
> Can someone explain when would I want
> to prefer one over the other?
>
> Thanks,
> -Chris

It is a general question.

I was reading around on the issue, and there is a strong push to favor DI over
class factories.  The thing that concerned me is the religiousness of it, as if
DI where the higher evolved form of coding.   Two reasons that I thought were
interesting are: 1) class factories violate the open / close principal, and 2)
Heavy use of class factories results in a lot of class factories in your
project.  Given how they are used, I'm not sure I care about #1, and at least in
the size of the projects I am doing, #2 hasn't been an issue.

As I learned more, I realized I didn't really phrase the question well.  While I
have found dependency injection to be very useful when properly applied, my
larger concern is with the large and complex dependency injection frameworks. 
So far I've only worked on one project that used a framework and while I could
see some advantages - it wasn't done very well (IMO).  There was still a lot of
coupling in that if I wanted to change the source of data to be anything other
than a database it would involve a significant effort.  It also added a learning
curve just trying to understand what instances of which object would be created
when.

So far, the answer I have gathered from the group is that it isn't an either/or
answer – they are different tools for different situations.

I'm going to post my question about DI frameworks on a separate thread.


--- In leanprogramming@yahoogroups.com, Christopher Sage <bigbuffwolf@...>
wrote:
>
> It would also depend upon what your goal is.  Is there anything in
> particular you're trying to solve, or is this just a general question?
>
> -Chris
>
> On Mon, Jan 25, 2010 at 12:14 PM, Scott Bain <slbain@...>wrote:
>
> >
> >
> >  It's an interesting question, Chris.  Thanks for posting it.
> >
> >
> >
> > There are some ways in which this is an either/or question (ways in which
> > DI and factories relate) and some ways in which it is not (where they have
> > different motivations).
> >
> >
> >
> > Some ways they relate…
> >
> > 1.       They both Separate the use of something from its creation, which
> > I think is a good separation of concerns.
> >
> > 2.       They both also help encapsulate variation (if the object being
> > injected/constructed varies, as is usually the case).
> >
> >
> >
> > Some ways they are more different…
> >
> > 1.       Factories help to encapsulate business rules in a single place.
> > If, for instance, you are building a decorator chain of various behaviors,
> > then a factory can impose rules about what chains can be built and which
> > cannot, or which should be built under what circumstances.  If a client
> > object builds the chain to inject it into a service, and the service has
> > more than one client, then the rules are spread out and often redundant.
> >
> > 2.       DI, on the other hand, can be very useful in breaking
> > dependencies for testing (it is easy to inject a mock directly if the
> > dependency is already "inject-able", for example).  If you let a factory
> > "decide" to build a mock, then the factory can get coupled to testing
> > issues.
> >
> >
> >
> > Of course, they can be used together as well.  A Client can use a factory
> > to build a dependency, and then inject what the factory built into the
> > Service.  A test could inject  a mock instead, ignoring the factory.  This
> > can be overkill, of course, but if one needs the benefits of both, one can
> > use them in this way.
> >
> >
> >
> > That's my first bit of thinking, anyway.  Let's see what others say.
> >
> >
> >
> > -Scott-
> >
> >
> >
> > *From:* leanprogramming@yahoogroups.com [mailto:
> > leanprogramming@yahoogroups.com] *On Behalf Of *chrishand40
> > *Sent:* Monday, January 25, 2010 9:44 AM
> > *To:* leanprogramming@yahoogroups.com
> > *Subject:* [leanprogramming] ClassFactories vs dependancy injection
> >
> >
> >
> >
> >
> > Can someone explain when would I want to prefer one over the other?
> >
> > Thanks,
> > -Chris
> >
> >
> >
>

What is the take on these?  When would you say "this project would benefit"?

A project would be taking on a respectible sized dependency just adding a DI
framework (for example MS Unity).  Given the size and complexity - I'm wondering
if it is really worth it?

I don't have much experience using them, so maybe there is a big win that I have
yet to see.

There are many good open source "DI frameworks" / "IOC Containers" (I probably
shouldn't, but I tend to use these two terms interchangeably) .  To name a few
in the .Net space there is Castle Windsor, StructureMap, NinJect, Autofac, and
more that you can see in this post
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
At the risk of starting a flame war, I'll say that IMHO Unity is not one of the
"good" ones... "good" being very subjective.  I've been very happy with both
Castle and StructureMap.  NinJect and Autocac seem very popular although I
haven't used them yet, I plan to check them out.

An IOC container helps me accomplish the following:
1) Test-Driven Development
2) Achieving low coupling in my designs
3) Application Configuration
4) Fine grain control over Object lifecycle
5) Decomposition in design (maybe this is the same as #2)
6) Making boundries explicit and intention revieling

Note: This isn't an exahstive list of the benifist in using an IOC container,
it's just what quickly comes to mind.

I'm sure you can do all of this without a DI framework / IOC container, but the
tool will make all of this a lot easier.

In most situations, when you take on a "dependency just by adding a DI
framework", that dependency donsn't have to leak throuought your application. 
For instance, your entire application can be written without the knowledge of
any specific container or DI Framework accept for your the entry point where the
configuration of your dependencies are enacted (i.e. in Program.Main() or
Global.Application_Start()).  In most situations, by simply using constructor
injection, I'm able to keep the dependency on a container completely out of an
application except for the entry point.  If there are situations where you have
to access a container deep within your application to act as a "service broker",
then you can do so by providing your own static abastration over whatever
container you're using.  This (rare for me) situation makes for more friction
durring TDD, but it's realativly painless.

I think 95% percent of the applications I write utilize a DI Framework / IOC
Container unless it's a very simple utility application that consists of a very
small amouont of classes (i.e. less than five) that I did not design using TDD.

Greg

--- In leanprogramming@yahoogroups.com, "chrishand40" <cj.hand@...> wrote:
>
> What is the take on these?  When would you say "this project would benefit"?
>
> A project would be taking on a respectible sized dependency just adding a DI
framework (for example MS Unity).  Given the size and complexity - I'm wondering
if it is really worth it?
>
> I don't have much experience using them, so maybe there is a big win that I
have yet to see.
>

Hello,

On Mon, Feb 1, 2010 at 09:20, chrishand40 <cj.hand@...> wrote:
>
> It is a general question.
>
> I was reading around on the issue, and there is a strong push to favor DI over
class factories.  The thing that concerned me is the religiousness of it, as if
DI where the higher evolved form of coding.   Two reasons that I thought were
interesting are: 1) class factories violate the open / close principal, and 2)
Heavy use of class factories results in a lot of class factories in your
project.  Given how they are used, I'm not sure I care about #1, and at least in
the size of the projects I am doing, #2 hasn't been an issue.
>
> As I learned more, I realized I didn't really phrase the question well.  While
I have found dependency injection to be very useful when properly applied, my
larger concern is with the large and complex dependency injection frameworks.
 So far I've only worked on one project that used a framework and while I could
see some advantages - it wasn't done very well (IMO).  There was still a lot of
coupling in that if I wanted to change the source of data to be anything other
than a database it would involve a significant effort.  It also added a learning
curve just trying to understand what instances of which object would be created
when.
>
> So far, the answer I have gathered from the group is that it isn't an
either/or answer – they are different tools for different situations.

I don't have a clear opinion either way, but I read this the other
day, and it seems to touch on a couple of your concerns:
http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

- Kim

Very nice post Greg.

I would just put a word in for Unity, it actually does a nice job and I am
comfortable with the folks behind it knowing what they are talking about (Chris
Tavares last I heard).

The speed comparisons may be saying it's a bit of a dog but I haven't seen
anything that makes it a no go. I started with Spring and messed a little bit
with Windsor first and moved to Unity to get less hassle when deploying to
production (Microsoft and all). I have been very happy with the help
documentation as well.

Eric

--- In leanprogramming@yahoogroups.com, "gregbanister" <gregbanister@...> wrote:
>
>
> There are many good open source "DI frameworks" / "IOC Containers" (I probably
shouldn't, but I tend to use these two terms interchangeably) .  To name a few
in the .Net space there is Castle Windsor, StructureMap, NinJect, Autofac, and
more that you can see in this post
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
> At the risk of starting a flame war, I'll say that IMHO Unity is not one of
the "good" ones... "good" being very subjective.  I've been very happy with both
Castle and StructureMap.  NinJect and Autocac seem very popular although I
haven't used them yet, I plan to check them out.
>
> An IOC container helps me accomplish the following:
> 1) Test-Driven Development
> 2) Achieving low coupling in my designs
> 3) Application Configuration
> 4) Fine grain control over Object lifecycle
> 5) Decomposition in design (maybe this is the same as #2)
> 6) Making boundries explicit and intention revieling
>
> Note: This isn't an exahstive list of the benifist in using an IOC container,
it's just what quickly comes to mind.
>
> I'm sure you can do all of this without a DI framework / IOC container, but
the tool will make all of this a lot easier.
>
> In most situations, when you take on a "dependency just by adding a DI
framework", that dependency donsn't have to leak throuought your application. 
For instance, your entire application can be written without the knowledge of
any specific container or DI Framework accept for your the entry point where the
configuration of your dependencies are enacted (i.e. in Program.Main() or
Global.Application_Start()).  In most situations, by simply using constructor
injection, I'm able to keep the dependency on a container completely out of an
application except for the entry point.  If there are situations where you have
to access a container deep within your application to act as a "service broker",
then you can do so by providing your own static abastration over whatever
container you're using.  This (rare for me) situation makes for more friction
durring TDD, but it's realativly painless.
>
> I think 95% percent of the applications I write utilize a DI Framework / IOC
Container unless it's a very simple utility application that consists of a very
small amouont of classes (i.e. less than five) that I did not design using TDD.
>
> Greg
>
> --- In leanprogramming@yahoogroups.com, "chrishand40" <cj.hand@> wrote:
> >
> > What is the take on these?  When would you say "this project would benefit"?
> >
> > A project would be taking on a respectible sized dependency just adding a DI
framework (for example MS Unity).  Given the size and complexity - I'm wondering
if it is really worth it?
> >
> > I don't have much experience using them, so maybe there is a big win that I
have yet to see.
> >
>

Most TDD practitioners I've spoken with claim that teams that reach a matutity
with TDD enjoy an increase in productivity.  I have no trouble believing this,
but I wonder if there are any actual numbers on this?

Anyone have a credible study for me?  Most of the ones I've found online focus
on defect reduction and code quality.

Hi Scott,

George Dinwiddie has a good set of refs at
http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

Hope that helps,
- Kim

On Sat, Mar 13, 2010 at 22:16, Scott <slbain@...> wrote:
> Most TDD practitioners I've spoken with claim that teams that reach a matutity
with TDD enjoy an increase in productivity.  I have no trouble believing this,
but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me?  Most of the ones I've found online focus
on defect reduction and code quality.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

TDD ... now with 40% more productivity!

(Oh, and the short answer is no, I don't know of any report I would respect that
says TDD is more productive that some other approach)

Your question made me wonder, what is "productivity"?  From Wikipedia,
"Productivity is a measure of output from a production process, per unit of
input."  To me this means that for you to have a credible study, the study would
have to measure the ins and outs the same way you do.

I've done a lot of personal experimentation.  If you apply TDD to a very short
term project (a day or two), then it ALWAYS takes longer than someone that just
"bangs out the code".

For me, the value of TDD came in when that short term project starts to take on
a life of its own – when the customer comes back and wants new or different
functionality.  Again, through personal experimentation I found that TDD forced
a style of coding that made shifting requirements much simpler to adapt to.

I also find that the longer I work on a project, the more I see patterns emerge
from the code.  When I do TDD, it is more practical to factor out these patterns
because I have tests that verify the expectations of the code are still being
met.  In code that TDD has not been practiced, I find there is a lot of
repetitive code that people are afraid to touch because no-one knows what it is
being used for.

So after thinking through this, if "productivity" were measured by the amount of
code written to meet the requirements of a customer – then it seems the easiest
way to prove it would be to run through use-case scenarios while monitoring code
coverage.  My hypothesis would be that as the number of requirements increase:
1) when using TDD, you would see less code required to fulfill the needs of the
requirements and 2) when using TDD, there would be a smaller amount of "dead"
code when running through the user scenarios.

I know I didn't answer the question, but thanks for asking it - I did enjoy
thinking through what the answer might look like.  I hope it makes sense.



--- In leanprogramming@yahoogroups.com, "Scott" <slbain@...> wrote:
>
> Most TDD practitioners I've spoken with claim that teams that reach a matutity
with TDD enjoy an increase in productivity.  I have no trouble believing this,
but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me?  Most of the ones I've found online focus
on defect reduction and code quality.
>

Personal experience:  I created a set of webapi's that provided a set of
functionality.  I was then asked to create a simple tool that used the webapis
for a user to pull some data down based on a simple input.  In less than 10
lines of code I created a tool that met the provided requirements.  I could have
done TDD, but I would have done more effort and not gained anything for it.


--- In leanprogramming@yahoogroups.com, "Max Guernsey, III" <max@...> wrote:
>
> See, I disagree with the "ALWAYS takes longer than someone that just 'bangs
> out the code'" statement. or at least I've had different experiences.
>
>
>
> The code can be "done" in a shorter time without TDD so long as your
> definition of "done" doesn't have anything to do with real doneness.  I've
> never seen a project of any reasonable length (more than
> Console.WriteLine("{0} + {1} = {2}", 1, 2, 3);) that can be actually
> completed more quickly by "banging it out" than by using TDD.
>
>
>
> Max Guernsey, III
>
>
>
>  <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
>  <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
> Sent: Sunday, March 14, 2010 2:54 PM
> To: leanprogramming@yahoogroups.com
> Subject: [leanprogramming] Re: TDD Metrics
>
>
>
>
>
> TDD ... now with 40% more productivity!
>
> (Oh, and the short answer is no, I don't know of any report I would respect
> that says TDD is more productive that some other approach)
>
> Your question made me wonder, what is "productivity"? From Wikipedia,
> "Productivity is a measure of output from a production process, per unit of
> input." To me this means that for you to have a credible study, the study
> would have to measure the ins and outs the same way you do.
>
> I've done a lot of personal experimentation. If you apply TDD to a very
> short term project (a day or two), then it ALWAYS takes longer than someone
> that just "bangs out the code".
>
> For me, the value of TDD came in when that short term project starts to take
> on a life of its own - when the customer comes back and wants new or
> different functionality. Again, through personal experimentation I found
> that TDD forced a style of coding that made shifting requirements much
> simpler to adapt to.
>
> I also find that the longer I work on a project, the more I see patterns
> emerge from the code. When I do TDD, it is more practical to factor out
> these patterns because I have tests that verify the expectations of the code
> are still being met. In code that TDD has not been practiced, I find there
> is a lot of repetitive code that people are afraid to touch because no-one
> knows what it is being used for.
>
> So after thinking through this, if "productivity" were measured by the
> amount of code written to meet the requirements of a customer - then it
> seems the easiest way to prove it would be to run through use-case scenarios
> while monitoring code coverage. My hypothesis would be that as the number of
> requirements increase: 1) when using TDD, you would see less code required
> to fulfill the needs of the requirements and 2) when using TDD, there would
> be a smaller amount of "dead" code when running through the user scenarios.
>
> I know I didn't answer the question, but thanks for asking it - I did enjoy
> thinking through what the answer might look like. I hope it makes sense.
>
> --- In leanprogramming@yahoogroups.com
> <mailto:leanprogramming%40yahoogroups.com> , "Scott" <slbain@> wrote:
> >
> > Most TDD practitioners I've spoken with claim that teams that reach a
> matutity with TDD enjoy an increase in productivity. I have no trouble
> believing this, but I wonder if there are any actual numbers on this?
> >
> > Anyone have a credible study for me? Most of the ones I've found online
> focus on defect reduction and code quality.
> >
>
>
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>

I thought about this ...

If you have two teams, one doing TDD and one that isn't.  The way they estimate
could make one appear to have a higher velocity then the other.  If one team
were more suited to the work, that team might show a higher velocity.  It is too
smushy of a metric to be used as anything other than what it was meant for.

The more I think about it, the more I don't like thinking about TDD as a process
to increase productivity in terms of time.  While I do believe it is true -
especially in larger projects, I think it is like trying to prove the state of
Schrödinger's cat.




--- In leanprogramming@yahoogroups.com, "Max Guernsey, III" <max@...> wrote:
>
> I just don't get how you can show the increase in productivity without
> measuring velocity and, as soon as that measurement comes into play, I think
> it opens up the argument for "debate."  I'll be interested in hearing how
> referring to these studies serves you is, I guess, what I'm really saying.
>
>
>
> Max Guernsey, III
>
>
>
>  <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
>  <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott Bain
> Sent: Sunday, March 14, 2010 11:07 AM
> To: leanprogramming@yahoogroups.com
> Subject: RE: [leanprogramming] TDD Metrics
>
>
>
>
>
> I understand what you're saying, Max, and insofar as we are talking
> "velocity", I think you are right.
>
>
>
> I think what I should have asked is:  are there any credible studies that
> show an increase in team productivity when TDD is used?  Velocity can be, as
> you point out, a rather misleading measurement.  One can move very quickly
> while doing the wrong thing, and producing waste, for instance.
>
>
>
> -S-
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III
> Sent: Sunday, March 14, 2010 12:32 AM
> To: leanprogramming@yahoogroups.com
> Subject: RE: [leanprogramming] TDD Metrics
>
>
>
>
>
> I think that such a study would be difficult to do in the current political
> climate as it could be impugned simply by not accepting the metrics used to
> prove the point.
>
>
>
> If someone still believes there is such a thing as "code complete and ready
> for testing," then they are looking at the world through a lens that will
> make TDD "slow them down."  If they understand that only done is done, then
> they will be in a place where they can accept cycle time on whole units of
> value as the one true measure of capacity and, therefore, can accept that
> TDD improves their efficiency.
>
>
>
> Max Guernsey, III
>
>
>
>  <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
>  <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
> Sent: Saturday, March 13, 2010 1:16 PM
> To: leanprogramming@yahoogroups.com
> Subject: [leanprogramming] TDD Metrics
>
>
>
>
>
> Most TDD practitioners I've spoken with claim that teams that reach a
> matutity with TDD enjoy an increase in productivity. I have no trouble
> believing this, but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me? Most of the ones I've found online
> focus on defect reduction and code quality.
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>
>
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>

On Sun, Mar 14, 2010 at 11:45 PM, Max Guernsey, III <max@...> wrote:
> I’ve actually been in that exact scenario.  The team with the terrible
practices “proved” that our processes were wasteful by “delivering” a bunch of
garbage quickly.  If you guys are reading, you know who you are.  They kept
their project on life support until management rendered it’s judgment and
canceled Agility at that department.  When it hit the fan, the problems were
seen as “normal.”

a moment of silence for that playing out ever over across the globe...

Yep.  Sad but seemingly commonplace.

They don't actually burn us at the stake anymore but things haven't changed
much in the last five-hundred years.

Max Guernsey, III

Transition Testing: Cornerstone of Database Agility
Goad Testing: Deepening our Understanding of Automated Tests
http://www.dataconstructor.com

-----Original Message-----
From: leanprogramming@yahoogroups.com
[mailto:leanprogramming@yahoogroups.com] On Behalf Of Raoul Duke
Sent: Monday, March 15, 2010 11:30 AM
To: leanprogramming@yahoogroups.com
Subject: Re: [leanprogramming] Re: TDD Metrics

On Sun, Mar 14, 2010 at 11:45 PM, Max Guernsey, III <max@...> wrote:
> I’ve actually been in that exact scenario.  The team with the terrible
practices “proved” that our processes were wasteful by “delivering” a bunch
of garbage quickly.  If you guys are reading, you know who you are.  They
kept their project on life support until management rendered it’s judgment
and canceled Agility at that department.  When it hit the fan, the problems
were seen as “normal.”

a moment of silence for that playing out ever over across the globe...


------------------------------------

Yahoo! Groups Links



Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
07:34:00

I just wanted to say thanks to everyone who responded to my TDD Metrics
question.  Very interesting and useful responses. :)

One thing I've been tasked to do is create a recorded edicational series
designed to help procedural programmers make the transition to objects.  Some
organizations have devs who are still focues on procedural technique, and want
to find ways to get them to "switch over" to the OO mindset, but can run into
resistence.

So, this is the first of six recordings designed not only to clarify the
difference between procedural approach and OO, but also to create some
motivation for, say, a very seasoned and talented Cobol programmer to be willing
to make a significant change to the way he or she works:

http://www.netobjectives.com/files/WhyHowObjects/SessionOnePartOne/SessionOnePar\
tOne.html

Note, most of the people in this group are *not* the target audience here, but
might have some thoughts on whether my approach is going to do what I hope.

Any opinions would be greatly appreciated.

On Tue, Apr 20, 2010 at 1:04 PM, Scott <slbain@...> wrote:
>
http://www.netobjectives.com/files/WhyHowObjects/SessionOnePartOne/SessionOnePar\
tOne.html

i'm not the target audience, so my reaction might not count, but...

teaching something is hard. each audience member probably learns in a
different way. for myself, i like to have more of a light theoretical
explanation, something along the lines of the Expression or
Extensibility Problem cf.
http://lambda-the-ultimate.org/node/3600#comment-51050

listening to WhyHowObjects S1P1, it is too hand-wavey loosey goosey
for me. having said that, if i imagine some really crochety grizzled
stuck in the mud coboalistaz, i can see how the presentation could be
a good hook. :-)

sincerely.