Return to Answer

You are right, 8 parameters -all strings- makes the constructor a candidate for a code review.

Consider some of the next points.

Essential attributes first

Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters or functions for the rest.

If all 8 attributes are required and read-only, there's not too much to do.

Encapsulation

Consider encapsulating related parameters. For example, A, B and C might go together within a new class. It reduces the number of arguments at the cost of one more class. It might not seem a big deal but, it contributes to express better the model and the code reuse. No to mention readability. Find out which parameters change together, at the same time due to the same reasons.

Use creational patterns

Instead of initializing messages directly, do It from factories or builders.

Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution.

In relation to this approach (which I was reluctant to trust), I posted a question where I ask about its suitability. The answers helped me out to be less reticent, so check it out if you are reluctant too.

Inheritance

Eventually, you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you find yourself asking for the type if(message.getType() == ...) all over the code.

You are right, 8 parameters -all strings- makes the constructor a good candidate for a code review.

Consider some of the next points.

Essential attributes first

Look the message model and figure out which attributes are necessary to initialize an instance in a consistent state. Reduce the number of arguments to the essential. Add setters or functions for the rest.

If all 8 attributes are required and read-only, there's not too much to do.

Encapsulation

Consider encapsulating correlated parameters. For example, A, B and C might be placed together into a new class. Find out which parameters change together, at the same time, due to the same reasons.

It reduces the number of arguments at the cost of one more class (complexity).

Use creational patterns

Instead of initializing messages directly from any place in the code source, do It from factories or builders.

Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution.

Regarding arrays, I posted a question where I ask about its suitability. I was reluctant to trust in such a solution. However, the answers helped me out to be less reticent, so check it out if you also dislike this solution. It might change your mind about this.

Inheritance

Eventually, you will realise that messages are good candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you ends up asking for the type if(message.getType() == ...) all over the code.

You are right, 8 parameters -all strings- makes the constructor a candidate for a code review.

Consider some of the next points.

Essential attributes first

Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters for the rest.

If all 8 attributes are required and read-only, there's not too much to do with this approach.

Encapsulation

Consider encapsulating related parameters. For example, A, B and C might go together within a new class. It reduces the number of arguments at the cost of one more class. It might not seem a big deal but, it contributes to express better the model and the code reuse. No to mention readability.

Use creational patterns

Instead of initializing messages directly, do It from factories or builders.

Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution.

In relation to this approach (which I was reluctant to trust), I posted a question where I ask about its suitability. The answers helped me out to be less reticent to this approach, so check it out if you are reluctant too.

Inheritance

Eventually, you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you find yourself asking for the type if(message.getType() == ...) all over the code.

You are right, 8 parameters -all strings- makes the constructor a candidate for a code review.

Consider some of the next points.

Essential attributes first

Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters or functions for the rest.

If all 8 attributes are required and read-only, there's not too much to do.

Encapsulation

Consider encapsulating related parameters. For example, A, B and C might go together within a new class. It reduces the number of arguments at the cost of one more class. It might not seem a big deal but, it contributes to express better the model and the code reuse. No to mention readability. Find out which parameters change together, at the same time due to the same reasons.

Use creational patterns

Instead of initializing messages directly, do It from factories or builders.

Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution.

In relation to this approach (which I was reluctant to trust), I posted a question where I ask about its suitability. The answers helped me out to be less reticent, so check it out if you are reluctant too.

Inheritance

Eventually, you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you find yourself asking for the type if(message.getType() == ...) all over the code.

You are right, 8 parameters -all strings- makes the constructor a candidate for a code review.

Consider some of the next points.

Essential attributes first

Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters for the rest.

If all 8 attributes are required and read-only, there's not too much to do with this approach.

Encapsulation

Consider encapsulating related parameters. For example, A, B and C might go together within a new class. It reduces the number of arguments at the cost of one more class. It might not seem a big deal but, it contributes to express better the model and the code reuse. No to mention readability.

Use creational patterns

Instead of initializing messages directly, do It from factories or builders.

Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution.

In relation to this approach (which I was reluctant to trust), I posted a question where I ask about its suitability. The answers helped me out to be less reticent to this approach, so check it out if you are reluctant too.

Inheritance

Eventually, you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you find yourself asking for the type if(message.getType() == ...) all over the code.

You are right, 8 parameters -all strings- makes the constructor a candidate for a code review.

Consider some of the next points.

Essential attributes first

Look at the message model and guess what attributes are essential to initialize a valid instance. Reduce the number of arguments to the essential. Add setters for the rest.

If all 8 attributes are required and read-only, there's not too much to do with this approach.

Encapsulation

Consider encapsulating related parameters. For example, A, B and C might go together within a new class. It reduces the number of arguments at the cost of one more class. It might not seem a big deal but, it contributes to express better the model and the code reuse. No to mention readability.

Use creational patterns

Instead of initializing messages directly, do It from factories or builders.

Arrays

If none of the above works, try an array of parameters. Given the lack of meaningful param's names, it's probably the simplest solution.

In relation to this approach (which I was reluctant to trust), I posted a question where I ask about its suitability. The answers helped me out to be less reticent to this approach, so check it out if you are reluctant too.

Inheritance

Eventually, you will realise that messages are excellent candidates for inheritance. Segmenting messages by attribute generates a little overhead because sooner than later you find yourself asking for the type if(message.getType() == ...) all over the code.