Refactoring dumb switch-case statements [closed]
up vote
0
down vote
favorite
I am struggling to invent a better way of eliminating stupid switch-case statements by adding more knowledge to the code.
switch (shapeType) {
case "circle":
shape = new Circle(colour,
Double.valueOf(req.getParameter("radius")),
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY"))
); break;
case "ellipse":
shape = new Ellipse(colour,
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY")),
Double.valueOf(req.getParameter("radiusX")),
Double.valueOf(req.getParameter("radiusY"))
); break;
}
My idea is to keep a dictionary
Map<String, ShapeFactory> shapesByShapeTypes;
for a later usage similar to
shapesByTypes[shapeType].create();
How good of an approach is it?
I am looking for a rather hard, fundamental and shameless critics. Feel free to mock it.
java object-oriented hash-map abstract-factory
asked Nov 19 at 11:35
vatevr
294
closed as off-topic by 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast Nov 20 at 14:29
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
up vote
0
down vote
favorite
I am struggling to invent a better way of eliminating stupid switch-case statements by adding more knowledge to the code.
switch (shapeType) {
case "circle":
shape = new Circle(colour,
Double.valueOf(req.getParameter("radius")),
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY"))
); break;
case "ellipse":
shape = new Ellipse(colour,
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY")),
Double.valueOf(req.getParameter("radiusX")),
Double.valueOf(req.getParameter("radiusY"))
); break;
}
My idea is to keep a dictionary
Map<String, ShapeFactory> shapesByShapeTypes;
for a later usage similar to
shapesByTypes[shapeType].create();
How good of an approach is it?
I am looking for a rather hard, fundamental and shameless critics. Feel free to mock it.
java object-oriented hash-map abstract-factory
asked Nov 19 at 11:35
vatevr
294
closed as off-topic by 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast Nov 20 at 14:29
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast
If this question can be reworded to fit the rules in the help center, please edit the question.
1
While your question is off-topic for code review (no implementation here), as a general hint: look into enums with abstract methods, so that you can have an enum for your shape types where each constant can create its each concrete shape.
– mtj
Nov 19 at 14:20
2
There is not enough context here to see what you are trying to achieve and give you the proper advice for doing it the best way. Please see How to Ask.
– 200_success
Nov 19 at 14:20
How about a functioncreateShapetaking the shape (circle/ellipse) and the parameters as arguments? Create a Shape class.
– Mast
Nov 20 at 14:29
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am struggling to invent a better way of eliminating stupid switch-case statements by adding more knowledge to the code.
switch (shapeType) {
case "circle":
shape = new Circle(colour,
Double.valueOf(req.getParameter("radius")),
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY"))
); break;
case "ellipse":
shape = new Ellipse(colour,
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY")),
Double.valueOf(req.getParameter("radiusX")),
Double.valueOf(req.getParameter("radiusY"))
); break;
}
My idea is to keep a dictionary
Map<String, ShapeFactory> shapesByShapeTypes;
for a later usage similar to
shapesByTypes[shapeType].create();
How good of an approach is it?
I am looking for a rather hard, fundamental and shameless critics. Feel free to mock it.
java object-oriented hash-map abstract-factory
asked Nov 19 at 11:35
vatevr
294
I am struggling to invent a better way of eliminating stupid switch-case statements by adding more knowledge to the code.
switch (shapeType) {
case "circle":
shape = new Circle(colour,
Double.valueOf(req.getParameter("radius")),
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY"))
); break;
case "ellipse":
shape = new Ellipse(colour,
Double.valueOf(req.getParameter("cX")),
Double.valueOf(req.getParameter("cY")),
Double.valueOf(req.getParameter("radiusX")),
Double.valueOf(req.getParameter("radiusY"))
); break;
}
My idea is to keep a dictionary
Map<String, ShapeFactory> shapesByShapeTypes;
for a later usage similar to
shapesByTypes[shapeType].create();
How good of an approach is it?
I am looking for a rather hard, fundamental and shameless critics. Feel free to mock it.
java object-oriented hash-map abstract-factory
java object-oriented hash-map abstract-factory
asked Nov 19 at 11:35
vatevr
294
asked Nov 19 at 11:35
vatevr
294
edited Nov 19 at 13:24
asked Nov 19 at 11:35
vatevr
294
asked Nov 19 at 11:35
vatevr
294
asked Nov 19 at 11:35
vatevr
294
294
closed as off-topic by 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast Nov 20 at 14:29
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast
If this question can be reworded to fit the rules in the help center, please edit the question.
closed as off-topic by 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast Nov 20 at 14:29
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – 200_success, Toby Speight, Graipher, Sᴀᴍ Onᴇᴌᴀ, Mast
If this question can be reworded to fit the rules in the help center, please edit the question.
1
While your question is off-topic for code review (no implementation here), as a general hint: look into enums with abstract methods, so that you can have an enum for your shape types where each constant can create its each concrete shape.
– mtj
Nov 19 at 14:20
2
There is not enough context here to see what you are trying to achieve and give you the proper advice for doing it the best way. Please see How to Ask.
– 200_success
Nov 19 at 14:20
How about a functioncreateShapetaking the shape (circle/ellipse) and the parameters as arguments? Create a Shape class.
– Mast
Nov 20 at 14:29
add a comment |
1
While your question is off-topic for code review (no implementation here), as a general hint: look into enums with abstract methods, so that you can have an enum for your shape types where each constant can create its each concrete shape.
– mtj
Nov 19 at 14:20
2
There is not enough context here to see what you are trying to achieve and give you the proper advice for doing it the best way. Please see How to Ask.
– 200_success
Nov 19 at 14:20
How about a functioncreateShapetaking the shape (circle/ellipse) and the parameters as arguments? Create a Shape class.
– Mast
Nov 20 at 14:29
1
1
While your question is off-topic for code review (no implementation here), as a general hint: look into enums with abstract methods, so that you can have an enum for your shape types where each constant can create its each concrete shape.
– mtj
Nov 19 at 14:20
While your question is off-topic for code review (no implementation here), as a general hint: look into enums with abstract methods, so that you can have an enum for your shape types where each constant can create its each concrete shape.
– mtj
Nov 19 at 14:20
2
2
There is not enough context here to see what you are trying to achieve and give you the proper advice for doing it the best way. Please see How to Ask.
– 200_success
Nov 19 at 14:20
There is not enough context here to see what you are trying to achieve and give you the proper advice for doing it the best way. Please see How to Ask.
– 200_success
Nov 19 at 14:20
How about a function
createShape taking the shape (circle/ellipse) and the parameters as arguments? Create a Shape class.– Mast
Nov 20 at 14:29
How about a function
createShape taking the shape (circle/ellipse) and the parameters as arguments? Create a Shape class.– Mast
Nov 20 at 14:29
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
While your question is off-topic for code review (no implementation here), as a general hint: look into enums with abstract methods, so that you can have an enum for your shape types where each constant can create its each concrete shape.
– mtj
Nov 19 at 14:20
2
There is not enough context here to see what you are trying to achieve and give you the proper advice for doing it the best way. Please see How to Ask.
– 200_success
Nov 19 at 14:20
How about a function
createShapetaking the shape (circle/ellipse) and the parameters as arguments? Create a Shape class.– Mast
Nov 20 at 14:29