昨天我讨论了一种架构编码风格,如果一个方法的调用者或方法的逻辑应该决定一些东西。
现在如何完成(简化):
有一个类Page
,其属性为List<Hotel>
。
public class Page {
private String name;
private List<Hotel> hotels;
}
决定在方法中包含业务逻辑,以便调用者不关心页面信息的设置方式。
public void fillPageWithHotels(Page page, List<DummyInfo> dummyInfos){
//business logic...
List<Hotel> hotels = new ArrayList<>();
for(DummyInfo di : dummyInfos){
//create a hotel instance and fill the infos of dummy inside hotel attributes
Hotel h = new Hotel(di.getName());
//many other information set to hotel attributes...
hotels.add(h);
}
//important part here. The List of hotels is set here to the page
page.setHotels(hotels);
}
第一个问题:这是一个好的设计还是该方法应该返回List<Hotel>
?
为什么我问这个问题:
现在我有另一个扩展酒店的课程。 public class HotelDetail extends Hotel
HotelDetail
现在也是Page
对象中的一个属性。
我还必须调用fillPageWithHotels
方法。但现在我不需要Hotel
而是HotelDetail
实例。
来电者无法决定他是否需要Hotel
或HotelDetail
。
if(decisionIsHotel){ new Hotel()} else {new HotelDetail()}
并将其提交给页面。 (我个人不喜欢的)或者该方法现在应该是通用的吗?方法从方法参数中输出Page
并具有泛型返回类型。
public <T extends Hotel> T fillPageWithHotels(List<DummyInfo> dummyInfos){}
或其他更好的代码/架构风格。
这个问题的最佳架构风格是什么?
EDIT1:
我的第一种方法:我不给Page
作为方法参数,而是给一个genric返回类型:
public <T extends Hotel> List<T> fillPageWithHotels(Class<T> c, List<DummyInfo dummyInfos){
//business logic...
List<T> hotels = new ArrayList<>();
for(DummyInfo di : dummyInfos){
//create a hotel instance and fill the infos of dummy inside hotel attributes
T t = c.newInstance();
//many other information set to hotel attributes...
hotels.add(t);
}
return hotels;
}
答案 0 :(得分:2)
在我看来,管理方法参数的状态并不是一个好主意。
如果method是类的一部分,我们可以简单地删除第一个参数:
class Page {
...
public void fillPageWithHotels(List<DummyInfo> dummyInfos){
...
setHotels(hotels);
}
}
否则可能是实用方法:
class Factory {
public static List<Hotel> createHotels(List<DummyInfo> dummyInfos){
...
}
}
...
page.setHotels(Factory.createHotels(dummyInfos));
如果调用者无法确定他需要什么类型,则无法指定泛型。