On 18.09.2015 17:28, Joseph L. Casale wrote:
So a design pattern I use often is to create Python objects to represent
objects returned from what ever api I am abstracting. For example I
might create named tuples for static data I dont intend to change or
for an object I can both query for and create, I might build a class to
represent it.
The problem now comes from the following:
# foo now contains a handle to the remote api.
foo = InstanceOfApiWrapper()
Is it necessary to have an instance of that API? Just curiosity here.
# queues is a container of Queue classes.
queues = foo.get_queues()
queue = queues[0]
queue.delete()
Alright. I see you want to have concrete classes, so you work with HTTP
like you would do with SOAP-bases web services.
I actually was referring to the self-expanding capability of REST
(please note, REST is not HTTP, HTTP is one protocol that can be use to
build an REST-ful API). It's basically like: you query a resource which
holds an link to another resource which you then you query by following
that link and so on and so forth. So, all what you need for REST is one
starting point to explore the resource graph.
In this case its possible for foo (InstanceOfApiWrapper) to inject a reference
to itself so the delete() can actually make the call.
# I want to create a queue from scratch...
disparate_queue = Queue(x, y, z)
# Now what happens? No handle to an api?
disparate_queue.delete()
I don't see an issue here. Looks quite readable.
An alternative is:
foo.delete_queue(disparate_queue)
That's not a pattern I prefer, what facilities in Python provide for a
workaround
here?
You always can add attributes to objects. So, add something like an
__api__ attribute (which nobody would ever use except you when creating
these queue objects in "get_queues").
One option is to put everything in one module and use globals. If the handle is
initialized it'll just work.
Problem with that is its not thread safe (without work) and I subscribe to
one object per file (bloody hard with Python's import/load procedure.
It's perfectly fine to add a "secret" API instance to the object. It's
called aspect-oriented programming. You remove the aspect of how to
correctly manage an API instance and put that knowledge into a separate
piece of code. *thumbs up*
Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list
