哪位大神懂点OOD的,帮忙看这个uml该怎么设计哈?
图中AQIDay下面是将xls和csv格式的文件进行统一,AQIDay是我设计的面向对象,即将将xls和cvs中每一条记录看成是一个AQIDay对象.
AQIDay上是通过实现Format()方法将xls和csv中每一条记录统一成AQIDay对象.
我很疑问的是,'CommonExcelFileHandler','AQIDay', 'BasicAQIFormatHandler'3个对象间最好是什么样的?
在这里我是将AQIDay依赖于CommonExcelFileHandler和BasicAQIFormatHandler.
不懂这种面向对象的设计是否合理?
------解决思路----------------------
如果你将随便一个方法也当做一个类，你得弄多少类（或者接口）啊？
OOD设计也仍然是要尽可能地精炼的。只有符合某种“必须拆解”的东西才拆解，而非常简单的东西就应该作为关联类（或者接口）中的属性或者方法。
在设计中，应该基于“业务领域概念”来设计，而不应该出现什么纯粹计算机领域的概念。你的什么“xxxxFileHandler“是非常突兀的，是乱源。
如果说一套数据资料需要有两种不同的保存和读写形式，那么你只要有 AQIDay、ExcelAQIDay、CSVAQIDay这三个类就够了。而相应的操作，应该出现在 AQIDay的定义中，并且被另外两个所继承。
比如说写代码
public class DataProc
{
......
public void ReadAQI(DateTime month)
{
var x = new CSVAQIDay( new DateTime(month.Year, month.Month, 1));
foreach(var y in x.Datas)
{
.....显示y
}
x.Add(....);
x.Save(); //以CSV格式保存数据，而不是Excel格式
}
}
那么这类程序，显然就需要通过AQIDay类的 Datas 属性和 Add、Save方法来操作。那么你的图上并没有！
而format操作，纯粹是你将来编写实现Save方法时的内部实现，很低级、很靠“后”的东西。
在你的图上，什么“xxxxHandler”、“format”这种东西是多余的，而真正需要作为开发合同的AQIDay的高层接口属性和方法缺失。可见你在画这个图的时候，也不能够给人家明确写出具体的AQIDay类对象的操作行为、脚本，而只是一个含糊其辞的状态。
初学者有一种毛病，就是总是念念不忘纠结底层的技术（在高层次的设计图上纠结结一点点技术术语，例如什么Handler之类的），而忽略大量真正需要设计的属性、行为、时序、通讯、用例等等。这是不对的。你知道技术再多，你现在要面对的是设计接口、协议，而底层技术是将来具体实现的人才应该去关心的事情。
------解决思路----------------------
抛开需求变更的预期不谈，没法谈"OOD"，如果你仅仅实现"xls"和"csv"，而没有第三种格式，硬编码又有何不妨？
如果说你还有别的格式支持，你需要的是抽象和重构，而不是拿出几张uml图高谈阔论。
------解决思路----------------------
我只是来看OOD的，不说话，上面有大神在
------解决思路----------------------
按楼主的描述，似乎是一个系统中的数据读写接口。这个接口需要从xls或csv文件中读取数据和保存数据到这两类文件中？如果我理解没错的话，这个类只需要暴露两个接口：
bool Load(AQIDay obj, string type);
bool Save(AQIDay obj, string type);
这两个接口的实现方法中，通过type参数，调用不同的实现xls或csv文件读写的方法即可。很简单的一个接口类，或者是一个wcf服务类啊。
------解决思路----------------------
我也觉得是简单问题复杂化了。
向10楼说的暴露两个接口就OK。
或者使用简单工厂模式。