QA » openQA Project » openQA Tests » qe-yam

*Actions
The idea is to decouple the dependency on the action and take is out of the class. Each class can carry its own action(s) context. And because there are widgets that can perform more than one actions the Strategy pattern cannot apply with the normal implementation.
In case that each subclass had one action we could implement the above pattern creating another field in the base class that the action could be inherited and act. the Subclass would have only to pass itself in the methods.
With the current proposal, it removes the coupling in the base class and extends the action modules, so it can act independently. The Actions class has only one variable. I have named it context(name is under consideration, dont stick on it), that has the params to pass in the request. As that, it is a hash. the main item is :action. Set also attr_accessor to :context, such as the each class can append its items(See textbox.rb)

*Items
All items functions have some things in common. We have complex data structure, they dig for :label and items returns always an Array. We can unify the logic and pass this in the base class. Classes that use different key, like table.rb can override the function. I provide a function that acts on Arrays and i tested among all the examples.

*setting/getting values
I did not spend too much time on it because i had not understood the exact usecase for it.
However, in my understanding the text in textbox with the above changes can easily(and with variety of ways) be set. for instance i used the following code in set function

def set(value)
  @edit_action.context.merge!(value: value) # or edit_action.context[:value] = 'val'
  @edit_action.execute(self)
  self
end

Note that the Actions class uses attr_accessor :context to make the variable accessible.
My idea here is that as those values are just another context, no more action is required.

Finally i provide UML that i hope can make some things cleat in a visual way

In addition to the meeting i want to add the following clarifications.
The strategy pattern solves the problem to dynamically swap the algorithms used in an application. it provides a means to define a family of algorithms. And it lets the algorithm vary independently from clients that use them while it hides details of an algorithm's implementation
The Command pattern is a Behavior pattern and as such it encapsulates a much smaller level of detail than an algorithm0

In fact if you notice the proposal Action.rb it implements the command pattern in a way. Instead of having an Interface where from you create a family of actions, the actions are defined as Constants where i think this is how you would do it in the ruby world. But by its own it does not uncouple the action calls from the design.

[0] https://i.stack.imgur.com/wTO3S.jpg