Lee C -
Here is a technique for avoiding the if-elseif-elseif...-else method
for building objects. It is a modified form of ChainOfResponsibility
pattern, in which you have a collection of factory methods that all
have a common signature, or a collection of Factory classes that all
implement a
Paul McGuire [EMAIL PROTECTED] wrote:
Lee C -
Here is a technique for avoiding the if-elseif-elseif...-else method
for building objects. It is a modified form of ChainOfResponsibility
pattern, in which you have a collection of factory methods that all
have a common signature, or a
On Sun, 26 Jun 2005 17:58:11 -0400, George Sakkis wrote
(in article [EMAIL PROTECTED]):
Paul McGuire [EMAIL PROTECTED] wrote:
Lee C -
Here is a technique for avoiding the if-elseif-elseif...-else method
for building objects. It is a modified form of ChainOfResponsibility
pattern, in
Ok, I'm glad you guys liked that design pattern. Here are a few
additional footnotes:
1. As George mentions, the order of the converters is *very* important,
especially in this particular case. One might question whether '1+0j'
would convert to a complex or an int - my first thought was to make
On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek [EMAIL PROTECTED]
wrote:
[...]
Now, the same sort of behaviour where the if type testing has been
replaced with code more in keeping with the OOP approach:
class C(object):
...def report(self):
...print Found a C
...
Chinook wrote:
I understand what you are saying. The point I'm messing up my head with
though, is when the entity (tree node in my case or variable record content
deconstructing in the aspect example I noted) is not an instance of a class
already - it is obtained from an external source
Jordan Rastrick wrote:
Without knowing more about your problem, I think the most obvious OO
approach would be to write a seperate (simple) class for each of
node_type_1, node_type_2, etc.
While I agree that this is the cleanest and usually simplest approach,
it does have its drawbacks. I'm
OO approach to decision sequence?
-
In a recent thread (Cause for using objects?), Chris Smith replied with (in
part):
If your table of photo data has several types of photos, and you find
yourself saying
if is_mugshot:
#something
, the programmer, and is not thrust upon
you by the language.
And you certainly don't want metaclasses or anything else that complex
and deep for something like this.
Chinook wrote:
OO approach to decision sequence?
-
In a recent thread (Cause for using objects?), Chris
Chinook said unto the world upon 18/06/2005 02:17:
OO approach to decision sequence?
-
In a recent thread (Cause for using objects?), Chris Smith replied with (in
part):
If your table of photo data has several types of photos, and you find
yourself
Jordan Rastrick wrote:
I've coded some simple recursive tree data structures using OO before
(unfortunately not in Python though). It's not nessecarily an
ill-suited approach to the task, although it depends on the specific
details of what you're doing. What's the the piece of code from which
On Sat, 18 Jun 2005 03:52:28 -0400, Brian van den Broek wrote
(in article [EMAIL PROTECTED]):
Chinook said unto the world upon 18/06/2005 02:17:
OO approach to decision sequence?
-
In a recent thread (Cause for using objects?), Chris Smith replied
On Sat, 18 Jun 2005 09:10:25 -0400, George Sakkis wrote
(in article [EMAIL PROTECTED]):
Chinook wrote:
I understand what you are saying. The point I'm messing up my head with
though, is when the entity (tree node in my case or variable record content
deconstructing in the aspect example I
13 matches
Mail list logo