You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The longer I work my way through the agents, the more I think it is worth considering to split up all classes that provide distinct behaviour depending on the string attribute backend. It seems to me a more OO approach would be inheriting from a generic(/abstrcact) base class and rewriting (currently) two agent classes for the two backends. Somewhat similar to what we did with the dashboard (due to the need for distributed capabilities of multiprocess.context.Process).
The text was updated successfully, but these errors were encountered:
I have thought of that, however in designing new agents, will such scheme require the user to choose to inherit from either MesaAgentMet4FoF or OSBrainAgentMet4FoF ? I am not sure if i'm getting what you're implying, however, the goal was to be able to define a new agent class based on a single abstract class i.e
I understand your thought. I think a three layered abstraction would be best here. The bottom layer defines the interface of an agent class. the middle layer implements this interface and is adapted to a certain backend and maybe more specializations in future. The third layer combines theses adaptions and avoids any trouble for the end-user by switching between the parameterizations of the agents classes (which would be our current class AgentMet4FoF with a lot less code). This third layer would do the case distinction and basically only instantiating the right class of the second layer which currently would be one of something like MesaAgentMet4FoF and OsBrainAgentMet4FoF.
We agree on the current structure being not so clean in terms of object-orientation. A three layered structure as proposed above might be a good idea though it is just one perspective. At a later time, we want to transfer the current string checking into something more robust and clean.
The longer I work my way through the agents, the more I think it is worth considering to split up all classes that provide distinct behaviour depending on the string attribute
backend
. It seems to me a more OO approach would be inheriting from a generic(/abstrcact) base class and rewriting (currently) two agent classes for the two backends. Somewhat similar to what we did with the dashboard (due to the need for distributed capabilities ofmultiprocess.context.Process
).The text was updated successfully, but these errors were encountered: