design patterns in C++

[Anonymous]

I am looking for design patterns implemented in C++ for the following
purposes:

1). Study and learn from the code
2). Avoid reinventing the wheel

Searches on google are annoyingly turning up Java and C# examples - EVEN
when I specify C++ in search. I *could* 'port' from either language to
C++, but it defeats the purpose i stated earlier.

Any one care to offer a link/resource etc?

 

[Victor Bazarov]

I am looking for design patterns implemented in C++ for the following
purposes:

1). Study and learn from the code
2). Avoid reinventing the wheel

Searches on google are annoyingly turning up Java and C# examples -
EVEN when I specify C++ in search. I *could* 'port' from either
language to C++, but it defeats the purpose i stated earlier.

How does it defeat the purpose? You study by looking at some other
code, you learn by writing your own code and verifying its behaviour.
You're not reinventing the wheel, the patterns are already coded for
you. Besides, C# is very close to C++, porting it should be a breeze.

Any one care to offer a link/resource etc?

www.google.com

V

 

[Cholo Lennon]

I am looking for design patterns implemented in C++ for the following
purposes:

1). Study and learn from the code
2). Avoid reinventing the wheel

Searches on google are annoyingly turning up Java and C# examples - EVEN
when I specify C++ in search. I *could* 'port' from either language to
C++, but it defeats the purpose i stated earlier.

Any one care to offer a link/resource etc?

Get the book "Design Patterns: Elements of Reusable Object-Oriented
Software" from GoF (the examples are mainly in C++)

http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612

Regards

 

[nmi]

I am looking for design patterns implemented in C++.

http://www.eventhelix.com/RealtimeMantra/

And it is really a very good idea to use more specific words in searching, e.g.:

c++ factory design pattern

 

[EventHelix.com]

I am looking for design patterns implemented in C++ for the following
purposes:

1). Study and learn from the code
2). Avoid reinventing the wheel

Searches on google are annoyingly turning up Java and C# examples - EVEN
when I specify C++ in search. I *could* 'port' from either language to
C++, but it defeats the purpose i stated earlier.

Any one care to offer a link/resource etc?

Design pattern related articles can be found at:

http://www.eventhelix.com/RealtimeMantra/Patterns/

 

[Richard James]

I am looking for design patterns implemented in C++ for the following
purposes:

1). Study and learn from the code
2). Avoid reinventing the wheel

Searches on google are annoyingly turning up Java and C# examples - EVEN
when I specify C++ in search. I *could* 'port' from either language to
C++, but it defeats the purpose i stated earlier.

Any one care to offer a link/resource etc?

I had some sitting on my HDD that I had downloaded off the web a few years
ago, but I forgot to record where I got them. I have searched and found
their new location.
http://www.vincehuston.org/dp/
Note that site gives examples in many languages and all the C++ ones are in
a horrible two column text format.

I also have link to a downloadable book but it is for Java. You can look if
you like.
http://www.mindview.net/Books/TIPatterns/

If google gives you trouble you might want to try searching for each design
pattern individually. Instead of Design Patterns.
Doing that leads me back to sites like this.
http://sourcemaking.com/design_patterns

Richard James

 

[John Kewley]

I am looking for design patterns implemented in C++ for the following
purposes:

1). Study and learn from the code
2). Avoid reinventing the wheel

Searches on google are annoyingly turning up Java and C# examples - EVEN
when I specify C++ in search. I *could* 'port' from either language to
C++, but it defeats the purpose i stated earlier.

Any one care to offer a link/resource etc?

Design patterns should, by definition, be about design, not
implementation. Therefore they should be language independent like in
the GoF book. Implementations of these though would be educational.

Code patterns / Implementation patterns / language idioms OTOH are often
language independent.

Note that patterns involving Java reflection may not may onto other
languages, likewise ones that involve C++ templates (for static
assertion checking for instance) aren't so easy to map to Java.

JK

 

[red floyd]

Design patterns should, by definition, be about design, not
implementation. Therefore they should be language independent like in
the GoF book. Implementations of these though would be educational.

I believe the GoF book actually has sample implementations in C++.

 

[dave_mikesell]

Design patterns should, by definition, be about design, not
implementation. Therefore they should be language independent like in
the GoF book. Implementations of these though would be educational.

The GoF book implements the patterns in C++, and some of them don't
make a lot of sense in other languages. For instance, in Python you
can instantiate an object by only knowing its class name, somewhat
obviating the need for your own abstract factory.

 

[Jeff Schwab]

I believe the GoF book actually has sample implementations in C++.

I see from my handy-dandy copy that some examples are given in
Smalltalk, and others in C++. The C++ examples look suspiciously Java-
like to me, suggesting a strong Smalltalk influence. (Or maybe the
example code is just showing its pre-standard, 1995 age.)

 

[Jeff Schwab]

The GoF book implements the patterns in C++, and some of them don't
make a lot of sense in other languages. For instance, in Python you
can instantiate an object by only knowing its class name, somewhat
obviating the need for your own abstract factory.

How does that follow? The point of Abstract Factory is that the
factory's clients don't have to know the exact types being
instantiated. The GoF example is a GUI widget factory; if the client
code wants a button, it shouldn't have to know the exact type that
will be used to instantiate the button.

Do you mean that client code should be passed a bunch of string
variables a priori, as in "here's your button class name, here's your
scroll-view class name," etc? That's not anywhere near as flexible as
Abstract Factory. The factory lets you delay the decision of which
object type to instantiate, right up to the moment you need the
object.

The GoF patterns apply to Python at least as heavily as to C++. I've
spent some time in c.l.python lately, and it seems the community
(which is otherwise great) has a lot of severe misconceptions about
static typing. I think they are largely derived from Alex Martelli's
personal bias. Python is a wonderful language, but unless you prefer
stack traces to compiler diagnostics, it's really never going to be a
suitable replacement for C++. (Of course, people might use it as one,
anyway, if the current anti-C++ zeitgeist endures much longer.)

 

[Ian Collins]

How does that follow? The point of Abstract Factory is that the
factory's clients don't have to know the exact types being
instantiated. The GoF example is a GUI widget factory; if the client
code wants a button, it shouldn't have to know the exact type that
will be used to instantiate the button.

Do you mean that client code should be passed a bunch of string
variables a priori, as in "here's your button class name, here's your
scroll-view class name," etc? That's not anywhere near as flexible as
Abstract Factory. The factory lets you delay the decision of which
object type to instantiate, right up to the moment you need the
object.

How does that differ form instantiating an object form a string variable?

 

[dave_mikesell]

How does that differ form instantiating an object form a string variable?

And when you add more concrete widgets in Python, you don't have to
create factories and related keys to look them up to instantiate
them. It's baked into Python.

 

[Jeff Schwab]

How does that differ form instantiating an object form a string variable?

Where do you get the string variable?

 

[dave_mikesell]

Where do you get the string variable?

If you're going to instantiate an object by class name, you have to
get it from somewhere...config file, serialized over a connection, in
a data struct, etc.

 

[Ian Collins]

Where do you get the string variable?

From wherever you would get the information required to instantiate and
object from an Abstract Factory. It's just a different way of achieving
the same end.

 

[Jeff Schwab]

From wherever you would get the information required to instantiate and
object from an Abstract Factory. It's just a different way of achieving
the same end.

No it's not. Putting the class-name in a string doesn't buy you
anything[1], since you still have to relate the objects to types that
may vary from one instantiation to the next. There are two separate
concerns here: What concepts need to be fulfilled, and which types
should fulfill them. The abstract factory handles the latter concern on
a per-instantiation basis.

Suppose you have an immutable 'rectangle' type. Client code creates
rectangles by requesting them from an abstract factory. Ordinarily,
each rectangle must store both its width and height. If the width and
height of such an immutable rectangle happen to be the same, a simpler
representation may be possible; figuring this out is the factory's job.
The client (pseudo-)code looks like this:

AbstractRectangle rect = abstractFactory->createRectangle(w, h);

The client code need neither know nor care what concrete type implements
the rectangle. This is the point of the Factory design pattern. It
gives you more flexibility than a single class-name per type.

The point of Abstract Factory is that not only can the client code be
isolated from concrete product types, but even from the concrete factory
type. It has exactly one more level of indirection.

You can mix the product-creation code together with product-use code in
C++, Python, or the language of your choice, but you'll just get muddled
code.


[1] If you are just trying to parameterize some existing object creation
code, a Python string might be OK as a ConcreteBuilder in the Builder
pattern; however, the interface certainly leaves something to be
desired. I personally would prefer the string at least be wrapped in a
dedicated type implementing a properly designed AbstractBuilder
interface, rather than just "whatever interface strings happen to support."

 

[James Kanze]

How does that differ form instantiating an object form a
string variable?

It might not be a string. More generally, the actual type which
is instantiated might depend on information not easily available
to the client code. One common use of the abstract factory
pattern is for GUI look and feel: the actual class you get
depends on an environment variable (which usually just
controlled which dynamic object you loaded to get the abstract
factory).