I come from OOP pradigm and I also know a bit about functional programming and its advantages. Over time I came to like the separation of data and transformations that are applied to it using pure functions. While I like the OOP idea of encapsulating data and the operations you can perform on it using classes I also started to dislike the mess coming from keeping data and functions on one level. However for many reasons I don't feel like switching to functional programming totally (one of them is working in an environment where this would cause massive disruption) and I prefer to take baby steps in selected areas.

So I started to do a middle way, half baked things like creating a props object for keeping the instance properties that really define the state of the object (as in you can serialize or store just the props object and you can recreate the object from that) - sort of the way FB React framework does it in the components. I like the idea that I can store the instanceA props object externally then swap it with a temporary one, use the usual instanceA methods to play with that temporary state and then return to the old props.

There are tons of use cases having to do mostly with reusing the same subsystem 'engine' in all it's current configuration and dependencies to a) manage some temporary state b) simulate some operation without affecting the actual current state c) implementing a material and tool metaphor where you use tool to transform the material in some way, etc.

I started to look for a design pattern describing that strategy, namely having objects with decoupled swappable state to see what are the limitations, some other uses or possible improvements but what I found is this is most often regarded as an anti pattern in OOD (it breaks the 'object should only manipulate it's own data' idea). It is obviously also not really a purely functional approach.

So my question is: given I haven't invented a wheel here is it a recognized pattern or maybe an antipattern for a really good reason or maybe it's a pattern that can become antipattern when used incorrectly like Singleton but it has some well described merits, limits and drawbacks?

(For a bit more of a domain context I work most of the time programming custom, multimedia websites mixing event driven architecture with 60fps updates and lots of non standard UI solutions that often require some improvisation and are subject to late-in-the-process experimentation so the overall architecture needs to be very open to massive changes of requirements in the middle of the projects so I can (and do) live with a bit of punk rock programming patterns).

I come from OOP pradigm and I also know a bit about functional programming and its advantages. Over time I came to like the separation of data and transformations that are applied to it using pure functions. While I like the OOP idea of encapsulating data and the operations you can perform on it using classes I also started to dislike the mess coming from keeping data and functions on one level. However for many reasons I don't feel like switching to functional programming totally (one of them is working in an environment where this would cause massive disruption) and I prefer to take baby steps in selected areas.

So I started to do a middle way, half baked things like creating a props object for keeping the instance properties that really define the state of the object (as in you can serialize or store just the props object and you can recreate the object from that) - sort of the way FB React framework does it in the components. I like the idea that I can store the instanceA props object externally then swap it with a temporary one, use the usual instanceA methods to play with that temporary state and then return to the old props.

There are tons of use cases having to do mostly with reusing the same subsystem 'engine' in all it's current configuration and dependencies to a) manage some temporary state b) simulate some operation without affecting the actual current state c) implementing a material and tool metaphor where you use tool to transform the material in some way, etc.

I started to look for a design pattern describing that strategy, namely having objects with decoupled swappable state to see what are the limitations, some other uses or possible improvements but what I found is this is most often regarded as an anti pattern in OOD (it breaks the 'object should only manipulate it's own data' idea). It is obviously also not really a purely functional approach.

So my question is: given I haven't invented a wheel here is it a recognized pattern or maybe an antipattern for a really good reason or maybe it's a pattern that can become antipattern when used incorrectly like Singleton but it has some well described merits, limits and drawbacks?

(For a bit more of a domain context I work most of the time programming custom, multimedia websites mixing event driven architecture with 60fps updates and lots of non standard UI solutions that often require some improvisation and are subject to late-in-the-process experimentation so the overall architecture needs to be very open to massive changes of requirements in the middle of the projects so I can (and do) live with a bit of punk rock programming patterns).

EDIT To be more specific, I usually need the 'tool' object to have some state, configuration and dependencies of it's own and that's keeping me from having just pure function or static methods.