Return to Answer

This type of design does have its maintenance costs which multiply with the number of clients using the interface. The clients may now have to start thinking about how to express what they're doing to multiple slaves at once as often as possible because the scalar operations which just apply to one slave at a time will now be even slower than what you had when you had a scalar Slave object. They might have to construct lists of index pair ranges in advance to pass to a bulky aggregate operation indicating what sub-ranges of slaves to transform in parallel, requiring a secondary data structure to be managed by the client just to indicate what slaves they're interested in. Usage of the interface will always be somewhat unwieldy compared to what we could achieve with a single Slave interface. It's similar to the awkwardness of working with vertex buffer objects in OpenGL where you can no longer just loop through a list of vertices and render them one at a time individually in immediate mode. If there are a lot of non-critical cases where you want more convenience, you could create like a SlaveProxy class which provides that scalar interface but without storing anything more than an index and pointer to the Slaves aggregate and invokes non-scalar operations on it with an index range of just [n, n+1) to process the nth slave.

This type of design does have its maintenance costs which multiply with the number of clients using the interface. The clients may now have to start thinking about how to express what they're doing to multiple slaves at once as often as possible because the scalar operations which just apply to one slave at a time may now be even slower than what you had when you had a scalar Slave object. They might have to construct lists of index pair ranges in advance to pass to a bulky aggregate operation indicating what sub-ranges of slaves to transform in parallel, requiring a secondary data structure to be managed by the client just to indicate what slaves they're interested in. Usage of the interface will always be somewhat unwieldy compared to what we could achieve with a single Slave interface. It's similar to the awkwardness of working with vertex buffer objects in OpenGL -- while they are so much more efficient to do things with vertices in bulk, using them also comes with the cost where you can no longer just loop through a list of vertices and render them one at a time individually in immediate mode in the client code in such a convenient way. If there are a lot of non-critical cases where you want more convenience, you could create like a SlaveProxy class which provides that scalar interface but without storing anything more than an index and pointer to the Slaves aggregate and invokes non-scalar operations on it with an index range of just [n, n+1) to process the nth slave.

This type of design does have its maintenance costs which multiply with the number of clients using the interface. The clients may now have to start thinking about how to express what they're doing to multiple slaves at once as often as possible. They might have to construct lists of index pair ranges in advance to pass to a bulky aggregate operation indicating what sub-ranges of slaves to transform in parallel, requiring a secondary data structure to be managed by the client just to indicate what slaves they're interested in. Usage of the interface will always be somewhat unwieldy compared to what we could achieve with a single Slave interface. If there are a lot of non-critical cases where you want more convenience, you could create like a SlaveProxy class which provides that scalar interface but without storing anything more than an index and pointer to the Slaves aggregate.

This type of design does have its maintenance costs which multiply with the number of clients using the interface. The clients may now have to start thinking about how to express what they're doing to multiple slaves at once as often as possible because the scalar operations which just apply to one slave at a time will now be even slower than what you had when you had a scalar Slave object. They might have to construct lists of index pair ranges in advance to pass to a bulky aggregate operation indicating what sub-ranges of slaves to transform in parallel, requiring a secondary data structure to be managed by the client just to indicate what slaves they're interested in. Usage of the interface will always be somewhat unwieldy compared to what we could achieve with a single Slave interface. It's similar to the awkwardness of working with vertex buffer objects in OpenGL where you can no longer just loop through a list of vertices and render them one at a time individually in immediate mode. If there are a lot of non-critical cases where you want more convenience, you could create like a SlaveProxy class which provides that scalar interface but without storing anything more than an index and pointer to the Slaves aggregate and invokes non-scalar operations on it with an index range of just [n, n+1) to process the nth slave.

Design With Endless Breathing Room for Future Optimizations

Maintenance Costs

This type of design does have its maintenance costs which multiply with the number of clients using the interface. The clients may now have to start thinking about how to express what they're doing to multiple slaves at once as often as possible. They might have to construct lists of index pair ranges in advance to pass to a bulky aggregate operation indicating what sub-ranges of slaves to transform in parallel, requiring a secondary data structure to be managed by the client just to indicate what slaves they're interested in. Usage of the interface will always be somewhat unwieldy compared to what we could achieve with a single Slave interface. If there are a lot of non-critical cases where you want more convenience, you could create like a SlaveProxy class which provides that scalar interface but without storing anything more than an index and pointer to the Slaves aggregate.

Design With Endless Breathing Room for Future Optimizations