Need new architecture for passing operations to contained objects

[stiber]

What kind of issue is this?

• Bug report
• Feature request
• Question not answered in documentation
• Cleanup needed

Right now, we have a high degree of nesting of objects in other objects, which means that operations done at a high level, for example from main(), must be passed down a long chain of method calls to reach the object that can actually perform the operation. We need to fix this.

What is affected by this?

How do we replicate the issue/how would it work?

Expected behavior (i.e. solution or outline of what it would look like)

Other Comments

[stiber]

Here are the common operations provided by simulation entities:

• retrieveParameters()
• allocateCPUMemory()
• allocateGPUMemory()
• initializeState()
• copyToGPU()
• copyFromGPU()
• deallocateGPUMemory()
• deallocateCPUMemory()
• shutdown()

And maybe serialization/deserialization operations, but the architecture of cereal pretty much precludes these being implemented using the chain of command pattern.

[stiber]

Hi @christopherdokeefe, I know we had a very brief conversation about the structure of the chain. In particular, you originally had one chain, with each node having a function and the operation it handles. At that point in time, I was thinking that Simulator would implement a separate chair for each operation type, with a separate public method for each type, and so I argued for a separate chain for each operation type, you you have now in ChainOperationManager.

However, you should have argued against this. With the agreement that we'll have a separate OperationManager class, with a single executeOperation() method, separate chains is more complex than it needs to be. So, yeh, I guess I'm saying that we should go back to a single chain with each ChainNode having a data members like:

std::function<void()> function;
Operations::op operation;

This will not only greatly simplify the code, but will mean we can add or modify the set of operations with minimal changes.

[christopherdokeefe]

I see. I'll get those changes done today, it shouldn't be difficult to change.

…

On Wed, Jul 1, 2020, 6:50 PM Michael Stiber ***@***.***> wrote: Hi @christopherdokeefe <https://github.com/christopherdokeefe>, I know we had a very brief conversation about the structure of the chain. In particular, you originally had one chain, with each node having a function and the operation it handles. At that point in time, I was thinking that Simulator would implement a separate chair for each operation type, with a separate public method for each type, and so I argued for a separate chain for each operation type, you you have now in ChainOperationManager <https://github.com/UWB-Biocomputing/SummerOfBrain/blob/cacc666bbf77efffa45d68ab8c8423b8c168df2c/ChainOfResponsibility/ChainOperationManager.h#L30-L34> . However, you should have argued against this. With the agreement that we'll have a separate OperationManager class, with a single executeOperation() method, separate chains is more complex than it needs to be. So, yeh, I guess I'm saying that we should go back to a single chain with each ChainNode having a data members like: std::function<void()> function; Operations::op operation; This will not only greatly simplify the code, but will mean we can add or modify the set of operations with minimal changes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFMPYSLOZBEBOLDKQ6ZKZR3RZPRTTANCNFSM4OG7XFBA> .