Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #108588 > unrolled thread
| Started by | dieter <dieter@handshake.de> |
|---|---|
| First post | 2016-05-13 09:21 +0200 |
| Last post | 2016-05-13 09:21 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Design: Idiom for classes and methods that are customizable by the user? dieter <dieter@handshake.de> - 2016-05-13 09:21 +0200
| From | dieter <dieter@handshake.de> |
|---|---|
| Date | 2016-05-13 09:21 +0200 |
| Subject | Re: Design: Idiom for classes and methods that are customizable by the user? |
| Message-ID | <mailman.627.1463124126.32212.python-list@python.org> |
Dirk Bächle <tshortik@gmx.de> writes:
> ...
> My questions
> ============
>
> - Is this a good approach, that I could use for other parts of the architecture as well, e.g. the Node class mentioned above?
You might look at the "adpater" pattern.
It is heavily used in Zope - and there looks something like:
* components are abstracted by interfaces (--> "zope.interface")
* where flexibility is needed, the code looks like
component = queryAdapter(<context>, interface, default=...)
or
component = queryUtility(interface, default=...)
to get a component implementing "interface".
(utilities are in some way adapters for "None", i.e.
those independent of a context)
* there is an adapter registry,
its content is specified either via an XML specification file
or via Python code
Back to top | Article view | comp.lang.python
csiph-web