2 added 329 characters in body
source | link

One of the biggest mistakes I see in projects is reluctance to make domain object specific collections. What I mean by mistake is, an object specific collection can be a great place to centralize code and business logic that is done to a specific entity.

A domain object specific collection is a class which represents a collection of a specific domain object, as opposed a generic collection which can contain different types of objects. Because it is a collection built for a specific type of entity, you can include useful methods that would apply only to that object type.

In your case, I would create a class called CustomerByAge. This class can inherit from a generic collection in your language. It can also have a static Create method that handles the complex transformation logic. You now have a central place for this logic to live and be tested. For extra credit, you can place that transformation logic into CustomerByAgeFactory class if you want to make things extra testable at the price of some extra typing.

Also, additional logic and queries can now live in methods of this collection, for example:

customersByAge.GetAdults()

The above is the greatest advantage to this approach because usually the logic to filter down groups of entities gets sprinkled all over a project or put in a ill-defined and hard to maintain service class.

One of the biggest mistakes I see in projects is reluctance to make domain object specific collections. What I mean by mistake is, an object specific collection can be a great place to centralize code and business logic that is done to a specific entity.

In your case, I would create a class called CustomerByAge. This class can inherit from a generic collection in your language. It can also have a static Create method that handles the complex transformation logic. You now have a central place for this logic to live and be tested. For extra credit, you can place that transformation logic into CustomerByAgeFactory class if you want to make things extra testable at the price of some extra typing.

Also, additional logic and queries can now live in methods of this collection, for example:

customersByAge.GetAdults()

The above is the greatest advantage to this approach because usually the logic to filter down groups of entities gets sprinkled all over a project or put in a ill-defined and hard to maintain service class.

One of the biggest mistakes I see in projects is reluctance to make domain object specific collections. What I mean by mistake is, an object specific collection can be a great place to centralize code and business logic that is done to a specific entity.

A domain object specific collection is a class which represents a collection of a specific domain object, as opposed a generic collection which can contain different types of objects. Because it is a collection built for a specific type of entity, you can include useful methods that would apply only to that object type.

In your case, I would create a class called CustomerByAge. This class can inherit from a generic collection in your language. It can also have a static Create method that handles the complex transformation logic. You now have a central place for this logic to live and be tested. For extra credit, you can place that transformation logic into CustomerByAgeFactory class if you want to make things extra testable at the price of some extra typing.

Also, additional logic and queries can now live in methods of this collection, for example:

customersByAge.GetAdults()

The above is the greatest advantage to this approach because usually the logic to filter down groups of entities gets sprinkled all over a project or put in a ill-defined and hard to maintain service class.

1
source | link

One of the biggest mistakes I see in projects is reluctance to make domain object specific collections. What I mean by mistake is, an object specific collection can be a great place to centralize code and business logic that is done to a specific entity.

In your case, I would create a class called CustomerByAge. This class can inherit from a generic collection in your language. It can also have a static Create method that handles the complex transformation logic. You now have a central place for this logic to live and be tested. For extra credit, you can place that transformation logic into CustomerByAgeFactory class if you want to make things extra testable at the price of some extra typing.

Also, additional logic and queries can now live in methods of this collection, for example:

customersByAge.GetAdults()

The above is the greatest advantage to this approach because usually the logic to filter down groups of entities gets sprinkled all over a project or put in a ill-defined and hard to maintain service class.