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
Currently, the TokenRejectFlow class and similar transaction flows are overly reliant on class hierarchies that treat flows as if they are transactions themselves. This design complicates the implementation and maintenance of transaction flows.
To improve this, we should refactor transaction flows so that transactions are treated as members of the flows rather than flows inheriting from transactions. This approach will simplify the design by:
Avoiding the need to reimplement selectors, mutators, and other functionality whenever creating new flows.
Allowing individual transactions within a flow to be modified independently (e.g., setting specific execution or transaction parameters).
Description
Currently, the
TokenRejectFlow
class and similar transaction flows are overly reliant on class hierarchies that treat flows as if they are transactions themselves. This design complicates the implementation and maintenance of transaction flows.To improve this, we should refactor transaction flows so that transactions are treated as members of the flows rather than flows inheriting from transactions. This approach will simplify the design by:
References
TokenRejectFlow
: feat: POC refactor for TokenRejectFlow hiero-sdk-cpp#868.The text was updated successfully, but these errors were encountered: