Prototype and c++ conversion operator

[v4vijayakumar]

Can "c++ conversion operator" be considered as an example for
Prototype design pattern?

Following example explains, C++ conversion operator.

#include <iostream>
#include <string>
using namespace std;

class test
{
public:
operator string ()
{
return "test";
}
};

int main()
{
test t;
string s = t;

cout << s << endl;

return 0;
}

 

[Victor Bazarov]

Can "c++ conversion operator" be considered as an example for
Prototype design pattern?

Following example explains, C++ conversion operator.

#include <iostream>
#include <string>
using namespace std;

class test
{
public:
operator string ()
{
return "test";
}
};

int main()
{
test t;
string s = t;

cout << s << endl;

return 0;
}

IMHO, no. The point of the Prototype patters is that there exists
an object [of the same type] that has some traits you want your new
object to inherit, so to speak, and some traits you want your new
object to have different. The main point is that the prototype is
of the same type as the object you need to produce.

Generally speaking, the prototype in your case here is not the 't',
but the temporary object its conversion function returns. So, to
some extend you can probably claim that the conversion function does
play the role of prototyping mechanism, but the implementation of
this pattern is not in the conversion function but in the fact that
you copy-construct your 's' string in 'main'.

Just my $0.02.

V

 

[H. S. Lahman]

Responding to V4vijayakumar...

Can "c++ conversion operator" be considered as an example for
Prototype design pattern?

Only with a truly impressive stretch. B-)

C++ is an OOPL used for OOP. It provides a tactical implementation of an
OO design at the 3GL level that is compatible with the hardware
computational models. However, DESIGN patterns are about software design
(i.e., OOA/D). IOW, the tail should not be wagging the dog.

For example, note that almost all of the GoF design patterns address a
single design problem:

1 R1 collaborates with 1
[A] ---------------------------

where the actual collaboration requires substitution of B's behavior
based on some sort of dynamic solution context. That complexity is too
complicated to try to capture in the simple association above. So most
of the GoF patterns employ some sort of delegation of B's
responsibilities combined with polymorphic dispatch to resolve the
complexity. IOW, those design patterns are reifying a design element to
make the design an unambiguous specification for OOP.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
(e-mail address removed) for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH