 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
David Turner Guest
|
Posted: Wed Feb 18, 2004 11:00 pm Post subject: Taxonomy of class patterns |
|
|
C++ classes are often implemented according to a well-known pattern, for
example, "abstract base class". I want to produce a kind of taxonomy of
these patterns. Here are some of the common archetypes I've encountered:
--Interfaces--
Example: streambuf.
Typically an ABC; often the actual object is obtained from a factory object.
Almost never templated.
--Types--
Example: complex.
Typically implements arithmetic operators (+, -, /, *). Occasionally
templated.
--Accessors--
Example: auto_ptr, iterator, fstream
Usually involved in RAII or invariant guarantees. Can be further subdivided
into guards, iterators, proxies. Often templated.
--Behaviours--
Example: can't think of a good one.
Classes whose sole purpose is to be inherited from, or aggregated into
another class. Usually provide some canonical behaviour for an interface.
Often templated (curiously recurring falls into this category).
--Objects--
Example: _stringstreambuf
Classes that implement one or more interfaces. Usually not part of any
public API, and preferably implemented in an anonymous namespace. Almost
never templated.
Do you have any more? Is my naming scheme bad? Has this all been done
before? Please let me know.
Regards
David Turner
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Jonathan Turkanis Guest
|
Posted: Thu Feb 19, 2004 6:21 pm Post subject: Re: Taxonomy of class patterns |
|
|
"David Turner" <david (AT) firepro (DOT) co.za> wrote
| Quote: | C++ classes are often implemented according to a well-known pattern,
for
example, "abstract base class". I want to produce a kind of
taxonomy of
these patterns. Here are some of the common archetypes I've
encountered: |
A professor of mine used to say that there are really only about 100
basic patterns for mathematical proofs, and joked about compiling a
list. I wish he had.
I like the idea of an implementation-oriented taxonomy of class
patterns, as a complement to GoF design patterns. I don't care for
your classifications, though. E.g., any taxonomy that puts auto_ptr,
iterator, and fstream together without some serious explanation is
suspicious.
Jonathan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Benjamin Golinvaux Guest
|
Posted: Fri Feb 20, 2004 1:21 pm Post subject: Re: Taxonomy of class patterns |
|
|
Is "--Behaviours--" what some people usually call "mixins" ? I use
this word when adding some functionality such as deriving from
"MReferenceCounting" or "MArchivable"
| Quote: | --Behaviours--
Example: can't think of a good one.
Classes whose sole purpose is to be inherited from, or aggregated into
another class. Usually provide some canonical behaviour for an interface.
Often templated (curiously recurring falls into this category).
|
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
David Turner Guest
|
Posted: Fri Feb 20, 2004 3:11 pm Post subject: Re: Taxonomy of class patterns |
|
|
Hi
| Quote: | I like the idea of an implementation-oriented taxonomy of class
patterns, as a complement to GoF design patterns. I don't care for
your classifications, though. E.g., any taxonomy that puts auto_ptr,
iterator, and fstream together without some serious explanation is
suspicious.
|
Well, that's part of why I posted my list . The rationale for putting
those three together is that all three abstract access to a particular
resource in a safe fashion. That's why I called them "accessors". As I
pointed out, you can then do a further subdivision: auto_ptr is a guard,
iterators are a category unto themselves, and fstream is what I would call a
proxy (proxy to a "real" object, in this case a file).
How would you classify them?
Regards
David Turner
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
David Turner Guest
|
Posted: Fri Feb 20, 2004 9:07 pm Post subject: Re: Taxonomy of class patterns |
|
|
"Benjamin Golinvaux" <benjamin.golinvaux (AT) euresys (DOT) com> wrote
| Quote: | Is "--Behaviours--" what some people usually call "mixins" ? I use
this word when adding some functionality such as deriving from
"MReferenceCounting" or "MArchivable"
|
Yes. Just so. I called them "behaviours" because I thought "mix-in", while
evocative, is more a description of what they *do* than of what they *are*
. But the terminology really doesn't bother me. Call it what you like.
Regards
David Turner
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Jonathan Turkanis Guest
|
Posted: Sat Feb 21, 2004 10:58 am Post subject: Re: Taxonomy of class patterns |
|
|
"David Turner" <david (AT) firepro (DOT) co.za> wrote
| Quote: | Hi
I like the idea of an implementation-oriented taxonomy of class
patterns, as a complement to GoF design patterns. I don't care for
your classifications, though. E.g., any taxonomy that puts
auto_ptr,
iterator, and fstream together without some serious explanation is
suspicious.
Well, that's part of why I posted my list . The rationale for
putting
those three together is that all three abstract access to a
particular
resource in a safe fashion. That's why I called them "accessors".
As I
pointed out, you can then do a further subdivision: auto_ptr is a
guard,
iterators are a category unto themselves, and fstream is what I
would call a
proxy (proxy to a "real" object, in this case a file).
|
I think these classifications are too general to be interesting. For
high-level patterns describing the roles played by various classes,
the GoF patterns (plus the many additional 'GoF-style' patterns) do a
good job.
I'd be interested in a more nuts-and-bolts taxonomy in terms of C++
implementation. That's why it's not intersting to me to talk about the
'iterator' pattern, for instance, because iterators can be implemented
in so many different ways.
Jonathan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|