Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #37010 > unrolled thread

Concrete classes considered harmful

Back to article view | Back to comp.lang.c++

Contents

  Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-11 04:04 +0100
    Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-11 15:09 +1200
      Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-11 17:49 +0100
        Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-11 18:10 +0100
          Re: Concrete classes considered harmful Martin Shobe <martin.shobe@yahoo.com> - 2015-07-11 13:33 -0500
        Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-12 09:17 +1200
          Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 01:51 +0100
            Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-12 13:20 +1200
              Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 02:32 +0100
                Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-12 15:48 +1200
                  Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 13:46 +0100
                Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-12 16:14 +1200
                  Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-13 17:46 +0000
                    Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-14 08:52 +1200
                      Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-13 22:01 +0000
              Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-13 17:28 +0000
                Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-14 08:47 +1200
                  Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-13 22:02 +0000
                    Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-14 10:35 +1200
                      Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-14 04:52 +0000
                        Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-14 19:31 +1200
                          Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-15 16:57 +0000
                            Re: Concrete classes considered harmful Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:49 +1200
                              Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-16 15:53 +0000
                            Re: Concrete classes considered harmful Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-08 13:20 +0000
                              Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-10-12 20:48 +0000
        Re: Concrete classes considered harmful Juha Nieminen <nospam@thanks.invalid> - 2015-07-12 11:32 +0000
          Re: Concrete classes considered harmful Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2015-07-12 13:46 +0100
            Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 13:54 +0100
              Re: Concrete classes considered harmful Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2015-07-12 14:21 +0100
                Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 14:40 +0100
                  Re: Concrete classes considered harmful Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2015-07-12 14:59 +0100
      Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-13 17:08 +0000
        Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-13 19:59 +0100
        Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-13 20:06 +0100
    Re: Concrete classes considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2015-07-11 05:11 +0200
      Re: Concrete classes considered harmful legalize+jeeves@mail.xmission.com (Richard) - 2015-07-13 17:10 +0000
    Re: Concrete classes considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2015-07-11 06:07 +0200
      Re: Concrete classes considered harmful woodbrian77@gmail.com - 2015-07-11 14:12 -0700
    Re: Concrete classes considered harmful Paavo Helde <myfirstname@osa.pri.ee> - 2015-07-11 02:06 -0500
      Re: Concrete classes considered harmful JiiPee <no@notvalid.com> - 2015-07-11 08:28 +0100
      Re: Concrete classes considered harmful Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 15:48 +0800
    Re: Concrete classes considered harmful Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2015-07-12 00:16 +0100
      Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 01:52 +0100
    Re: Concrete classes considered harmful David Harmon <source@netcom.com> - 2015-07-12 06:58 -0700
      Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 15:45 +0100
    Re: Concrete classes considered harmful Mr Flibble <flibble@i42.co.uk> - 2015-07-12 16:30 +0100
      Re: Concrete classes considered harmful woodbrian77@gmail.com - 2015-07-12 11:23 -0700
        Re: Concrete classes considered harmful "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2015-07-12 21:37 +0200
          Re: Concrete classes considered harmful woodbrian77@gmail.com - 2015-07-12 14:34 -0700
        Re: Concrete classes considered harmful Luca Risolia <luca.risolia@linux-projects.org> - 2015-07-13 00:38 +0200

Page 1 of 3  [1] 2 3  Next page →

#37010 — Concrete classes considered harmful

Dependencies on concrete classes are considered harmful and should be 
replaced with dependencies on abstractions.  A class should not new its 
member objects for example but rather should use a factory passed into 
its constructor.

SOLID priniciples can be at odds with performance though as far as C++ 
is concerned as certain optimizations cannot be peformed if all function 
calls are via abstract interfaces (virtual functions).  Any thoughts on 
how to square this circle?

/Flibble

[toc] | [next] | [standalone]

#37011

Mr Flibble wrote:
> Dependencies on concrete classes are considered harmful and should be
> replaced with dependencies on abstractions.

By whom?

> A class should not new its
> member objects for example but rather should use a factory passed into
> its constructor.

Why?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37020

On 11/07/2015 04:09, Ian Collins wrote:
> Mr Flibble wrote:
>> Dependencies on concrete classes are considered harmful and should be
>> replaced with dependencies on abstractions.
>
> By whom?

Go learn the SOLID principles; anyone who does not know and/or follow 
SOLID is not a very good engineer IMO.

>
>> A class should not new its
>> member objects for example but rather should use a factory passed into
>> its constructor.
>
> Why?

Good luck unit testing a class that has lots of dependencies on concretions.

/Flibble

[toc] | [prev] | [next] | [standalone]

#37022

On 11/07/2015 17:55, Stefan Ram wrote:
> Mr Flibble <flibble@i42.co.uk> writes:
>> On 11/07/2015 04:09, Ian Collins wrote:
>>> Mr Flibble wrote:
>>>> Dependencies on concrete classes are considered harmful and should be
>>>> replaced with dependencies on abstractions.
>>> By whom?
>> Go learn the SOLID principles; anyone who does not know and/or follow
>> SOLID is not a very good engineer IMO.
>
>    I still remember reading Robert C. Martin ("Uncle Bob"), who
>    invented SOLID, in »comp.object«. That group »comp.object«
>    would possibly be a fine place for your topic, but today it
>    is deserted.
>
>    Usually the Java crowd, especially the Java EE crowd, pays
>    more attention to such general OO topics than the C++ crowd.
>    C++ is more multi-paradigm and is often using generic
>    programming instead of OO.

Yes C++ is multi-paradigm and yes you should be using generic 
programming just as often as OOP, however OOP is no less important than 
any other C++ paradigm. *When* performing OOP with C++, SOLID should be 
followed. My post was intended to solicit opinions on if/when we should 
ignore SOLID principles for the sake of performance.  Should 90% of your 
OO code follow SOLID as only 10% of your code is critical path as far as 
performance is concerned?

/Flibble

[toc] | [prev] | [next] | [standalone]

#37023

On 7/11/2015 12:10 PM, Mr Flibble wrote:
> On 11/07/2015 17:55, Stefan Ram wrote:
>> Mr Flibble <flibble@i42.co.uk> writes:
>>> On 11/07/2015 04:09, Ian Collins wrote:
>>>> Mr Flibble wrote:
>>>>> Dependencies on concrete classes are considered harmful and should be
>>>>> replaced with dependencies on abstractions.
>>>> By whom?
>>> Go learn the SOLID principles; anyone who does not know and/or follow
>>> SOLID is not a very good engineer IMO.
>>
>>    I still remember reading Robert C. Martin ("Uncle Bob"), who
>>    invented SOLID, in »comp.object«. That group »comp.object«
>>    would possibly be a fine place for your topic, but today it
>>    is deserted.
>>
>>    Usually the Java crowd, especially the Java EE crowd, pays
>>    more attention to such general OO topics than the C++ crowd.
>>    C++ is more multi-paradigm and is often using generic
>>    programming instead of OO.
>
> Yes C++ is multi-paradigm and yes you should be using generic
> programming just as often as OOP, however OOP is no less important than
> any other C++ paradigm. *When* performing OOP with C++, SOLID should be
> followed. My post was intended to solicit opinions on if/when we should
> ignore SOLID principles for the sake of performance.  Should 90% of your
> OO code follow SOLID as only 10% of your code is critical path as far as
> performance is concerned?

I would expect that you'd see much more than 90% if 10% of your code was 
performance critical and you used SOLID everywhere performance concerns 
didn't indicate otherwise.

But to answer your original question, you'd cease using SOLID to gain 
performance only when your measurements indicate that you can gain the 
performance you need to meet your projects requirements.

Whether or not you should be using SOLID is another can of worms.

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#37025

Mr Flibble wrote:
> On 11/07/2015 04:09, Ian Collins wrote:
>> Mr Flibble wrote:
>>> Dependencies on concrete classes are considered harmful and should be
>>> replaced with dependencies on abstractions.
>>
>> By whom?
>
> Go learn the SOLID principles; anyone who does not know and/or follow
> SOLID is not a very good engineer IMO.

Well I certainly know about them and consider them guidelines, not hard 
and fast rules.  If you follow any set of guidelines as if they were 
gospel, you'll end up like the religious zealots who pop up here from 
time to time.

Oh by the way, I also use int in my code, so I guess by your standards 
I'm already not a very good engineer.

>>> A class should not new its
>>> member objects for example but rather should use a factory passed into
>>> its constructor.
>>
>> Why?
>
> Good luck unit testing a class that has lots of dependencies on concretions.

I've been unit testing everything I write for over a decade now and I've 
yet to encounter problems with non-abstract base classes.  Go and and 
learn about mock objects.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37027

On 11/07/2015 22:17, Ian Collins wrote:
> Mr Flibble wrote:
>> On 11/07/2015 04:09, Ian Collins wrote:
>>> Mr Flibble wrote:
>>>> Dependencies on concrete classes are considered harmful and should be
>>>> replaced with dependencies on abstractions.
>>>
>>> By whom?
>>
>> Go learn the SOLID principles; anyone who does not know and/or follow
>> SOLID is not a very good engineer IMO.
>
> Well I certainly know about them and consider them guidelines, not hard
> and fast rules.  If you follow any set of guidelines as if they were
> gospel, you'll end up like the religious zealots who pop up here from
> time to time.
>
> Oh by the way, I also use int in my code, so I guess by your standards
> I'm already not a very good engineer.

If you lazily use 'int' all over your code without actually thinking if 
it is appropriate then that does indeed make you a not very good 
engineer.  Perhaps you should be using Java rather than C++.

>
>>>> A class should not new its
>>>> member objects for example but rather should use a factory passed into
>>>> its constructor.
>>>
>>> Why?
>>
>> Good luck unit testing a class that has lots of dependencies on
>> concretions.
>
> I've been unit testing everything I write for over a decade now and I've
> yet to encounter problems with non-abstract base classes.  Go and and
> learn about mock objects.

It is virtually impossible to unit test a class that has dependencies on 
lots of other concrete classes that themselves require unit testing.  I 
know all about mock objects thanks and that is the point: it is easy to 
make a class being unit tested use a mock object if that mock object 
complies to an abstract interface and is created by a mock object factory.

/Flibble

[toc] | [prev] | [next] | [standalone]

#37029

Mr Flibble wrote:
> On 11/07/2015 22:17, Ian Collins wrote:
>> Mr Flibble wrote:
>>> On 11/07/2015 04:09, Ian Collins wrote:
>>>> Mr Flibble wrote:
>>>>> Dependencies on concrete classes are considered harmful and should be
>>>>> replaced with dependencies on abstractions.
>>>>
>>>> By whom?
>>>
>>> Go learn the SOLID principles; anyone who does not know and/or follow
>>> SOLID is not a very good engineer IMO.
>>
>> Well I certainly know about them and consider them guidelines, not hard
>> and fast rules.  If you follow any set of guidelines as if they were
>> gospel, you'll end up like the religious zealots who pop up here from
>> time to time.
>>
>> Oh by the way, I also use int in my code, so I guess by your standards
>> I'm already not a very good engineer.
>
> If you lazily use 'int' all over your code....

Which I don't.

>>>>> A class should not new its
>>>>> member objects for example but rather should use a factory passed into
>>>>> its constructor.
>>>>
>>>> Why?
>>>
>>> Good luck unit testing a class that has lots of dependencies on
>>> concretions.
>>
>> I've been unit testing everything I write for over a decade now and I've
>> yet to encounter problems with non-abstract base classes.  Go and and
>> learn about mock objects.
>
> It is virtually impossible to unit test a class that has dependencies on
> lots of other concrete classes that themselves require unit testing.

The code bases I work on have a mix of abstract and concrete classes. 
All are TDD projects, so there is effectively 100% test coverage.  How 
would you define "lots of other concrete classes"? most of ours depend 
on very few others.  Having too many dependencies is more of a design 
issue than having dependencies on concrete classes.

> I
> know all about mock objects thanks and that is the point: it is easy to
> make a class being unit tested use a mock object if that mock object
> complies to an abstract interface and is created by a mock object factory.

Unless the the class has non-trivial inline member functions, whether it 
is abstract or not has little bearing on mocking.  In this instance, 
using the Pimpl idiom is just as effective as abstract base classes.

Given the three options of abstract, concrete without non-trivial inline 
member functions or Pimpl classes all are equally simple to mock.

I have nothing against using abstract base classes, but in the small 
embedded world where much of my code is used the cost is often (rightly 
or wrongly) considered to high a price to pay.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37030

On 12/07/2015 02:20, Ian Collins wrote:
> Mr Flibble wrote:
>> On 11/07/2015 22:17, Ian Collins wrote:
>>> Mr Flibble wrote:
>>>> On 11/07/2015 04:09, Ian Collins wrote:
>>>>> Mr Flibble wrote:
>>>>>> Dependencies on concrete classes are considered harmful and should be
>>>>>> replaced with dependencies on abstractions.
>>>>>
>>>>> By whom?
>>>>
>>>> Go learn the SOLID principles; anyone who does not know and/or follow
>>>> SOLID is not a very good engineer IMO.
>>>
>>> Well I certainly know about them and consider them guidelines, not hard
>>> and fast rules.  If you follow any set of guidelines as if they were
>>> gospel, you'll end up like the religious zealots who pop up here from
>>> time to time.
>>>
>>> Oh by the way, I also use int in my code, so I guess by your standards
>>> I'm already not a very good engineer.
>>
>> If you lazily use 'int' all over your code....
>
> Which I don't.
>
>>>>>> A class should not new its
>>>>>> member objects for example but rather should use a factory passed
>>>>>> into
>>>>>> its constructor.
>>>>>
>>>>> Why?
>>>>
>>>> Good luck unit testing a class that has lots of dependencies on
>>>> concretions.
>>>
>>> I've been unit testing everything I write for over a decade now and I've
>>> yet to encounter problems with non-abstract base classes.  Go and and
>>> learn about mock objects.
>>
>> It is virtually impossible to unit test a class that has dependencies on
>> lots of other concrete classes that themselves require unit testing.
>
> The code bases I work on have a mix of abstract and concrete classes.
> All are TDD projects, so there is effectively 100% test coverage.  How
> would you define "lots of other concrete classes"? most of ours depend
> on very few others.  Having too many dependencies is more of a design
> issue than having dependencies on concrete classes.

You are obviously doing it wrong (TM).  Unit testing and TDD are not 
synonyms and TDD itself is actually considered harmful: you can *not* 
design software to a high standard by designing things downwards from 
tests.  A good design involves first defining an architecture along with 
abstractions (interfaces) and object interactions all of which should be 
driven by system requirements and not by passing brain-dead isolated tests.

/Flibble

[toc] | [prev] | [next] | [standalone]

#37031

Mr Flibble wrote:
> On 12/07/2015 02:20, Ian Collins wrote:
>>
>> The code bases I work on have a mix of abstract and concrete classes.
>> All are TDD projects, so there is effectively 100% test coverage.  How
>> would you define "lots of other concrete classes"? most of ours depend
>> on very few others.  Having too many dependencies is more of a design
>> issue than having dependencies on concrete classes.
>
> You are obviously doing it wrong (TM).

My clients and bank manager would argue otherwise.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37037

On 12/07/2015 04:48, Ian Collins wrote:
> Mr Flibble wrote:
>> On 12/07/2015 02:20, Ian Collins wrote:
>>>
>>> The code bases I work on have a mix of abstract and concrete classes.
>>> All are TDD projects, so there is effectively 100% test coverage.  How
>>> would you define "lots of other concrete classes"? most of ours depend
>>> on very few others.  Having too many dependencies is more of a design
>>> issue than having dependencies on concrete classes.
>>
>> You are obviously doing it wrong (TM).
>
> My clients and bank manager would argue otherwise.

Clients are oblivious to whether or not you have solved their problem 
the correct way; if it all barely hangs together and just meets their 
requirements they are usually happy even if the actual implementation is 
shite.

Egregious have-a-go cowboy developers can often make money out of poor 
quality work; doesn't make it right.

/Flibble

[toc] | [prev] | [next] | [standalone]

#37032

Mr Flibble wrote:
>
> You are obviously doing it wrong (TM).  Unit testing and TDD are not
> synonyms and TDD itself is actually considered harmful:

So is crossing the road..  It appears that you consider everything you 
don't do (whether you understand it or not) to be harmful.

> you can *not*
> design software to a high standard by designing things downwards from
> tests.  A good design involves first defining an architecture along with
> abstractions (interfaces) and object interactions all of which should be
> driven by system requirements and not by passing brain-dead isolated tests.

I agree.  No one who uses TDD writes brain-dead isolated tests.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37059

[Please do not mail me a copy of your followup]

Ian Collins <ian-news@hotmail.com> spake the secret code
<d0e7trFmf76U3@mid.individual.net> thusly:

>I agree.  No one who uses TDD writes brain-dead isolated tests.

I'm not sure what it means for a test to be "brain-dead isolated".

However, there are plenty of times when I've started with tests and
gotten to a good design without designing up-front any interfaces or
abstractions explicitly.  Did I have an idea of where I wanted to go
in my head?  Sure, but I didn't write it down as a "design document".
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#37067

Richard wrote:
>
> Ian Collins <ian-news@hotmail.com> spake the secret code
> <d0e7trFmf76U3@mid.individual.net> thusly:
>
>> I agree.  No one who uses TDD writes brain-dead isolated tests.
>
> I'm not sure what it means for a test to be "brain-dead isolated".
>
> However, there are plenty of times when I've started with tests and
> gotten to a good design without designing up-front any interfaces or
> abstractions explicitly.  Did I have an idea of where I wanted to go
> in my head?  Sure, but I didn't write it down as a "design document".

I've been down the same path many times, especially what doing XP for 
one..  In bigger projects some minimal up-front interface design is 
necessary.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37069

[Please do not mail me a copy of your followup]

Ian Collins <ian-news@hotmail.com> spake the secret code
<d0imnuFflldU4@mid.individual.net> thusly:

>Richard wrote:
>>
>> Ian Collins <ian-news@hotmail.com> spake the secret code
>> <d0e7trFmf76U3@mid.individual.net> thusly:
>>
>>> I agree.  No one who uses TDD writes brain-dead isolated tests.
>>
>> I'm not sure what it means for a test to be "brain-dead isolated".
>>
>> However, there are plenty of times when I've started with tests and
>> gotten to a good design without designing up-front any interfaces or
>> abstractions explicitly.  Did I have an idea of where I wanted to go
>> in my head?  Sure, but I didn't write it down as a "design document".
>
>I've been down the same path many times, especially what doing XP for 
>one..  In bigger projects some minimal up-front interface design is 
>necessary.

I agree.  The larger the system you're designing, the more up-front
work it requires.  However I would say that most of the time when I
was required to produce "design documents" it was largely busy work
that could have been avoided by simply pair programming on the work.
YMMV, of course.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#37058

[Please do not mail me a copy of your followup]

Ian Collins <ian-news@hotmail.com> spake the secret code
<d0dtm9FegarU8@mid.individual.net> thusly:

>Given the three options of abstract, concrete without non-trivial inline 
>member functions or Pimpl classes all are equally simple to mock.

I'm guessing you're using a lot of link-time mocking?
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#37066

Richard wrote:
> Ian Collins <ian-news@hotmail.com> spake the secret code
> <d0dtm9FegarU8@mid.individual.net> thusly:
>
>> Given the three options of abstract, concrete without non-trivial inline
>> member functions or Pimpl classes all are equally simple to mock.
>
> I'm guessing you're using a lot of link-time mocking?

Yes.  A lot of my work is low level system code and down there I'll be 
mocking mainly C libraries.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37070

[Please do not mail me a copy of your followup]

Ian Collins <ian-news@hotmail.com> spake the secret code
<d0imfgFflldU3@mid.individual.net> thusly:

>Richard wrote:
>> Ian Collins <ian-news@hotmail.com> spake the secret code
>> <d0dtm9FegarU8@mid.individual.net> thusly:
>>
>>> Given the three options of abstract, concrete without non-trivial inline
>>> member functions or Pimpl classes all are equally simple to mock.
>>
>> I'm guessing you're using a lot of link-time mocking?
>
>Yes.  A lot of my work is low level system code and down there I'll be 
>mocking mainly C libraries.

OK, given that confirmation, have you looked at cgreen?  It's a unit
test framework built specifically around link-time mocking and the use
of C.  All my TDD work has been in C++ where I could use static or
dynamic polymorphism for mocking out collaborators, so I haven't used
link-time mocking.  However, I can see it's usefulness.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#37071

Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-news@hotmail.com> spake the secret code
> <d0imfgFflldU3@mid.individual.net> thusly:
>
>> Richard wrote:
>>> Ian Collins <ian-news@hotmail.com> spake the secret code
>>> <d0dtm9FegarU8@mid.individual.net> thusly:
>>>
>>>> Given the three options of abstract, concrete without non-trivial inline
>>>> member functions or Pimpl classes all are equally simple to mock.
>>>
>>> I'm guessing you're using a lot of link-time mocking?
>>
>> Yes.  A lot of my work is low level system code and down there I'll be
>> mocking mainly C libraries.
>
> OK, given that confirmation, have you looked at cgreen?  It's a unit
> test framework built specifically around link-time mocking and the use
> of C.

No, I haven't.  I use my own mocking framework that is unit test 
framework neutral (it's been used with CppUnut, CxxTest and Google 
Test).  I prefer to keep the two coupled so I can use my framework with 
whatever unit test setup a client uses.

> All my TDD work has been in C++ where I could use static or
> dynamic polymorphism for mocking out collaborators, so I haven't used
> link-time mocking.  However, I can see it's usefulness.

It's pretty much the only option when you are working with system (or 
object only third party) libraries.

My approach has been to apply the same techniques to pure C++ code and 
mixed C and C++.  This leads to an unconventional approach to pure C++ 
code where it is the individual class member functions that are mocked, 
rather than class instances.  While this may appear odd, I've found most 
test cases revolve around checking passed parameter values and responses 
to returned values.  In these cases, being able to use the code 
generated by the framework rather than having to write mock objects 
saves a lot of work.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37073

[Please do not mail me a copy of your followup]

Ian Collins <ian-news@hotmail.com> spake the secret code
<d0isptFflldU5@mid.individual.net> thusly:

>Richard wrote:
>> All my TDD work has been in C++ where I could use static or
>> dynamic polymorphism for mocking out collaborators, so I haven't used
>> link-time mocking.  However, I can see it's usefulness.
>
>It's pretty much the only option when you are working with system (or 
>object only third party) libraries.

As they say: any problem in computer science can be solved with
another level of indirection :-).  I've done TDD with system-level
APIs provided as free functions by creating a domain-specific wrapper
around them.  I've done it with both static polymorphism and dynamic
polymorphism.  Link-time mocking is another alternative, of course.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web