public class MyObject
{
public static enum Type {A, B, C, D;}
public static final int ID_MAIN = 1;
public static final int ID_MAIN_UK = 2;
public static final int ID_MAIN_US = 3;
public static final int ID_SUB = 4;
// lots more constants here
public static final String DESCRIPTION_1 = "Desc Full Name";
public static final String DESCRIPTION_2 = "Desc2 Full Name";
// lots more constants here
private int id;
public MyObject(final int id)
{
this.id = id;
}
//simple getter
public int getID() { return this.id;}
// real responsibility of the class is in the following two methods
public static String getDescription()
{
switch(id)
{
case MyObject.ID_MAIN:
case MyObject.ID_MAIN_UK:
return MyObject.DESCRIPTION_1;
case MyObject.ID_SUB:
return MyObject_Description_2;
default:
// throw IllegalArgException
}
}
public static Type getType(int id)
{
switch(id)
{
case MyObject.ID_MAIN:
case MyObject.ID_SUB:
return Type.A;
case MyObject.ID_MAIN_UK:
case MyObject.ID_MAIN_US:
return Type.B;
default:
return Type.Undefined;
}
}
}
基本上,有一個ID映射到描述和類型。這個ID在類的構造過程中被傳入,並且應該映射到已經包含在類中的一組常量。如果id不是常量列表的一部分,則當嘗試獲取映射到id的描述時會引發錯誤,如果查詢類型,則返回'Unknown'類型。該ID將描述映射到一組常量。相同的ID映射到某個類型(定義爲枚舉)。重構具有多重責任的Java類
這段代碼非常難看,因爲在頂部定義了大量的常量,這使得開關語句非常臃腫。有沒有一種簡單的方法來重構這個,而不改變公共接口?它看起來非常簡單,但無論你如何切片,它都顯得很醜陋。我如何簡化這些映射以使代碼更簡潔?
我正在考慮代表文本文件中的映射,並且有一個管理器類在hashmap中保存了簡單的容器。當構造管理器類時,它將通過讀取文本文件並將它們映射到ID來創建對象。當經理查詢與ID,它只是調用相應的get方法,例如:
class Manager
{
private HashMap<int, MyObject> objectMap;
public Manager() {} //construct the object map
public String getDescription(int id) { return objectMap.get(id).getDescription();}
public Type getType(int id) { return objectMap.get(id).getType();}
}
class DataContainer
{
private String description;
private Type type;
public DataContainer(String desc, Type type) {//set mem vars}
public String getDescription() //simple getter
public Type getType() //simple getter
}
但是這種解決方案似乎過於複雜。有沒有更好的解決方案,最好是能將所有內容都保存在一個類中的解決方案
這個答案可能是更適合http://codereview.stackexchange.com/ – mdewitt
這個問題似乎是題外話,因爲它是關於代碼審查,並應朝着codereview.stackexchange.com – Snicolas
@重定向mdewitt:OP顯然不會要求CR。代碼審查從作者認爲接近完美的代碼開始。在這裏作者問如何解決*特定的問題*,代碼只是一個例子。 – maaartinus