Difference between revisions of "Blueprint-EncapsulatingData"
(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" ...") |
|||
| Line 1: | Line 1: | ||
| − | As part of the current on going Tempest redesign, I would like to propose | + | As part of the current on going Tempest redesign, I would like to propose the encapsulation of data into objects as a base for future Factory implementation. |
For example: (I'll use the Identity component "Keystone" as an example) | 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) | 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 | + | This approach gives you the power to be modular in your design, it adds readability, can be used to write more general purpose methods in the future (see example below) and avoid conflicts if something has changed. (like if the Devs decide to add / remove a parameter like "tenant" for example) |
So code such as: | So code such as: | ||
| Line 17: | Line 17: | ||
Where "user" represents an Object of type KeystoneUser. (In this case) | Where "user" represents an Object of type KeystoneUser. (In this case) | ||
| − | + | Note that this approach gives us the power to change the "create_user" method in the future to allow the use of different Identity component, thus reuse our code. (and object) | |
| − | 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 | + | This is only an example taken from the current Identity implementation, but it can easily be generalized into other objects as well. |
| + | |||
| + | From here we can easily move (in the future) to a more 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 blueprint 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. | 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. | ||
| − | --[[User:Tkammer|Tkammer]] ([[User talk:Tkammer|talk]]) | + | --[[User:Tkammer|Tkammer]] ([[User talk:Tkammer|talk]]) 14:10, 5 June 2013 (UTC) |
Latest revision as of 14:10, 5 June 2013
As part of the current on going Tempest redesign, I would like to propose the encapsulation of data into objects as a base for future Factory implementation.
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, it adds readability, can be used to write more general purpose methods in the future (see example below) and avoid conflicts 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)
Note that this approach gives us the power to change the "create_user" method in the future to allow the use of different Identity component, thus reuse our code. (and object)
This is only an example taken from the current Identity implementation, but it can easily be generalized into other objects as well.
From here we can easily move (in the future) to a more 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 blueprint 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.
