[EMAIL PROTECTED] a écrit :
Hallo,
users in this forum has been kind enough to point out. Only my
implementations are often not that clean, and I may call things
something different than the normal convention, which is a source of
confusion for myself and others trying to communicate with me.
I think, you should start with the classical books of Design Patterns
to get a solid understanding and especially vocabulary to communicate
with your coworkers. Its easier and better to say, that you will use a
strategy pattern than to describe the architecture in many sentences
to your partner in a ambigious way.
Indeed. But now there's the risk that coworkers implement this as:
class AbstractFooStrategy(object):
def run(self, yadda):
raise NotImplementedError
class SimpleFooStrategy(AbstractFooStrategy):
def run(self, yadda):
# code here
class Bar(object):
def __init__(self, foo_strategy):
if not isinstance(foo_strategy, AbstractFooStrategy):
raise ValueError("yadda yadda")
self.foo_strategy = foo_strategy
def do_this(self, yadda):
return self.foo_strategy.run(yadda)
b = Bar(SimpleFooStrategy())
instead of:
class Bar(object):
def __init__(self, foo_strategy):
self.foo_strategy = foo_strategy
def do_this(self, yadda):
return self.foo_strategy(yadda)
def baaz(yadda):
# code here
b = Bar(baaz)
Thats in my opinion the first and
the key benefit of Design Patterns.
Totally agree - at least as long as coworkers clearly understand the
difference between design and implementation.
Speaking in the same language. The
next step should be to apply your knowledge to your programming
language.
Indeed !-)
So I will recommend the classical GOF Books
<aol />
While most implementation example are way over the top in the context of
a hi-level dynamic language like Python, the GOF is one of the best book
on OO design I've ever read - if not the only that was worth reading
(disclaimer : I didn't read much dead-tree stuff on OO).
--
http://mail.python.org/mailman/listinfo/python-list
