Hi Dmitry,

I might not use a property...

If several methods need an array to collaborate, this array becomes part of the process state. Object properties are meant to keep object state. So the key question here is whether the object and the process are identical. If you create the object, call a method and release the object, the object matches the process. In this case the array property would be the way to go.

If, however, the object sits around for much longer and does other things than this one method that sits on the top of the group, there's no identity between object state and process state. When you would store process state in the object, the object now becomes kind of locked to this process. While this process is executing, you cannot call any other method, because this would interfere with the array. You don't need a multi-threaded environment to get into this situation. If your process raises events, these events are executing custom code that is outside the control of the object. There could very well be code that calls the object itself through a cascade of events.

If you need process state, there are basically two options: Redesign the class so that the class becomes the process, or make the state a parameter that is passed between methods. How you implement the latter is technical detail. You can use plain parameters, a separate state object, or a private variable. A separate state object would probably the cleanest and most extensible solution, a private array is likely to be the fastest one.