array with reusable elements
my question is about idea in general


It's flawed, in several ways. 

Premature Optimization

The code smell I get is that the whole point is avoiding instantiating and then disposing Array elements.  Reasons we stay away from optimizing up front


We end up spending too much time on it 
Corrupting our business design for the sake of something that we don't even know is an issue. 
We don't know yet where and how much actual performance is affected. 
We cannot know if our up front optimization is in fact better than what we would have done; it could be worse!


Resizing?

I thought this is what we're trying to avoid. 

Where is the "resizing"? I assume it will be in Add() and Remove(). If there is no resizing - the size is fixed at instantiation, then the class name is wrong.

The conventional wisdom says resizing Array is less performant than resizing a List. In fact the C#/.NET team went to great lengths to make sure List automatic resizing performs well. Do you have the time and other resources to make your home-spun Array resizing worth not using what the .NET framework already gives you?

Wrong Perspective

I see the client having to write his code in terms of Arrays and array elements when it should be in terms of your business objects - TradeOrder, for example.

The structure - the array - should not be the emphasis in your design. If you keep going down this road you are in for ugly maintenance problems over time. 

Give the business classes "collection friendly" capabilities

I imagine sorting, searching, preventing duplicates, uniqueness, etc. might be important qualities when we make a collection of things. So TradeOrder should implement IEquatable and IComparable.

ResizeableArray, or any other TradeOrder user's code, should not be doing this:

if (trade1.stockName == trade2.stockName &amp;&amp; trade1.shares == trade2.shares &amp;&amp; ...)


Client code should be able to do this:

if (trade1.Equals(trade2))


Should ResizableArray inherit Array?

Array already implements foreach, for example. You'll get all the built-in goodness and it will be exposed at the 'class level' to the client. There's lots of nifty search and sort methods that take advantage of ICompareable implementation.


  Some fields are never changes so as I reuse elements I need to assign those fields just once


Memory Leaks

As ResizableArray gets used it will have empty and occupied elements scattered throughout the Array. You will end up writing code to scan the array for every Add(). Otherwise you'll be adding new elements when there are empty elements available.

It looks like we leave TradeOrder objects in unused array elements. This is the case at instantiation, clearly. Also removing things involves Count but not nulling the reference there. I guarantee you'll be spending lots of extra code and lots of debugging time trying to keep the Count in synch with the actual active objects.

We don't know what an empty element is

The Count is being incremented/decremented but we're leaving objects in place. I'm assuming that at some point we're done with a given object, in which case it should be disposed of. Besides the memory issue, how do we know what array elements are in use and which ones we can over-write?


  // made public to use in "foreach", but better to be private
      public T[] array;


NO.  

ResizeableArray should implement IEnumerable.

You are forcing client code to be written like this:

foreach (var trade in tradeOrders.array)


When they should write:

foreach (var trade in tradeOrders)


This is a violation of OO principles. Single Responsibility, Law of Demeter (least knowledge), Encapsulation ... a discussion for another time.

As a practical matter do not force the client to have to know how to manipulate the class properties. ResizableArray should know how to iterate itself. 

The client should not tell the ResizeableArray object to resize, or how.