Jump to: navigation, search

Blueprint-EncapsulatingData

Revision as of 12:31, 5 June 2013 by Tkammer (talk | contribs) (Created page with "As part of the current on going Tempest redesign, I would like to propose to encapsulate data into separate objects. For example: (I'll use the Identity component "Keystone" ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

As part of the current on going Tempest redesign, I would like to propose to encapsulate data into separate objects.

For example: (I'll use the Identity component "Keystone" as an example) We should create an object Called: "KeystoneUser" which will hold all the relevant keystone user information (like username, password, token (if exist), tenant, etc) This approach gives you the power to be modular in your design and avoid conflicts in the future if something has changed. (like if the Devs decide to add / remove a parameter like "tenant" for example)

So code such as:

   self.client.create_user(self.alt_user, self.alt_password,
                                       self.data.tenant['id'],
                                       self.alt_email)

Can be rewritten into:

   self.client.create_user(user)

Where "user" represents an Object of type KeystoneUser. (In this case)

This is only an example taken from the current Identity implementation, but it can easily be generalized into "Volume", "Image", etc.

From here we can easily move (in the future) to a general "User" type with basic username/password, so if someone would like to add/replace the Identity component to something else, all that he/she will need to do is inherit/composite the User class while the test itself will stay the same. (but this is a whole new blue print by itself)

I believe that in general, we should try and make Tempest as modular as possible and encapsulating / separating responsibilities into objects can be a good first step.

--Tkammer (talk) 12:31, 5 June 2013 (UTC)