I'd go with something which is similar to the mentioned MultiKey
: create a ReportParameter
class and use it as the key of the map:
public class ReportParameter {
private final String reportName;
private final Parameter parameter;
public ReportParameter(final String reportName, final Parameter parameter) {
this.reportName = reportName;
this.parameter = parameter;
}
// equals and hashCode here
}
(Make sure that is has proper hashCode
and equals
methods.)
I think it's easier to understand than the nested maps (for example, Map<String, Map<Enum, String>>
).
Furthermore, I'd consider creating and using different types (!= string) for the report name and the parameter names. String identifiers are hard to follow and it's easy to accidentally mix them up. Different types (for example, enums, like Parameter
) and type safety help here.
FromA sidenote from Code Complete 2nd Edition, Chapter 5: Design in Construction, Value of Information Hiding, page 96:
[...]
Most programmers would decide, "No, it isn’t worth creating a whole class just for an ID. I’ll just use ints."
[...]
Rather, the difference is one of heuristics—thinking about information hiding inspires and promotes design decisions that thinking about objects does not.
I'd go with something which is similar to the mentioned MultiKey
: create a ReportParameter
class and use it as the key of the map:
public class ReportParameter {
private final String reportName;
private final Parameter parameter;
public ReportParameter(final String reportName, final Parameter parameter) {
this.reportName = reportName;
this.parameter = parameter;
}
// equals and hashCode here
}
(Make sure that is has proper hashCode
and equals
methods.)
I think it's easier to understand than the nested maps (for example, Map<String, Map<Enum, String>>
).
Furthermore, I'd consider creating and using different types (!= string) for the report name and the parameter names. String identifiers are hard to follow and it's easy to accidentally mix them up. Different types and type safety help here.
From Code Complete 2nd Edition, Chapter 5: Design in Construction, Value of Information Hiding, page 96:
[...]
Most programmers would decide, "No, it isn’t worth creating a whole class just for an ID. I’ll just use ints."
[...]
Rather, the difference is one of heuristics—thinking about information hiding inspires and promotes design decisions that thinking about objects does not.
I'd go with something which is similar to the mentioned MultiKey
: create a ReportParameter
class and use it as the key of the map:
public class ReportParameter {
private final String reportName;
private final Parameter parameter;
public ReportParameter(final String reportName, final Parameter parameter) {
this.reportName = reportName;
this.parameter = parameter;
}
// equals and hashCode here
}
(Make sure that is has proper hashCode
and equals
methods.)
I think it's easier to understand than the nested maps (for example, Map<String, Map<Enum, String>>
).
Furthermore, I'd consider creating and using different types (!= string) for the report name and the parameter names. String identifiers are hard to follow and it's easy to accidentally mix them up. Different types (for example, enums, like Parameter
) and type safety help here.
A sidenote from Code Complete 2nd Edition, Chapter 5: Design in Construction, Value of Information Hiding, page 96:
[...]
Most programmers would decide, "No, it isn’t worth creating a whole class just for an ID. I’ll just use ints."
[...]
Rather, the difference is one of heuristics—thinking about information hiding inspires and promotes design decisions that thinking about objects does not.
I'd go with something which is similar to the mentioned MultiKey
: create a ReportParameter
class and use it as the key of the map:
public class ReportParameter {
private final String reportName;
private final Parameter parameter;
public ReportParameter(final String reportName, final Parameter parameter) {
this.reportName = reportName;
this.parameter = parameter;
}
// equals and hashCode here
}
(Make sure that is has proper hashCode
and equals
methods.)
I think it's easier to understand than the nested maps (for example, Map<String, Map<Enum, String>>
).
Furthermore, I'd consider creating and using different types (!= string) for the report name and the parameter names. String identifiers are hard to follow and it's easy to accidentally mix them up. Different types and type safety help here.
From Code Complete 2nd Edition, Chapter 5: Design in Construction, Value of Information Hiding, page 96:
[...]
Most programmers would decide, "No, it isn’t worth creating a whole class just for an ID. I’ll just use ints."
[...]
Rather, the difference is one of heuristics—thinking about information hiding inspires and promotes design decisions that thinking about objects does not.