也不知道是不是该放到这个区。 :(
大家先看看吧。
今天,年轻的同事又来问我一个日志分析程序的设计。
帮他把程序由原来的每种格式需要写一段代码,改成了根据配置,调用不同的Parser实例进行处理的程序。
使我想起了一直困扰我的一个问题,什么是对象?
刚接触到面向对象,是看c++的书,第一句话,对象是对实际事物的抽象,从此陷入万劫不复之境地。
反而无法正确的面向对象设计。
直至工作一段时间,看别人的程序,自己写,使用设计模式。
到今天,可以用OO的设计简化代码,并给程序带来简单扩展性时,再回头来看,这个定义是一个极大陷阱。
(下面才开始我的想法,呵呵,写点铺垫)
OO里,从语言上来讲一个Object是一堆成员变量和方法的结合体。
从我的程序设计经验来讲,对象并不仅仅是对事物的抽象。
中学在电脑班学习数据结构的时候,对一句话印象深刻:
数据结构+算法 才是完整的算法
借鉴这个说法,对象是同时对事物和行为的抽象。
对事物的抽象
简单事物(pojo)
有关联的多个事物
事物之间的关联
对行为的抽象
独立行为,简单行为,比如string的trim操作。
上下文相关行为,根据环境不同,输入的参数会导致不同的结果。
条件行为,输入的参数包含数据和条件,根据条件不同导致会导致行为不同。
以我同事的那个项目为例,原有的设计是:
读入一行日志
分解成多个日志项,每一个项有一个格式名称
对于incoming log进行进行日志的解析
对于page_visit_log进行日志的解析
生成incoming log的sql,插入数据库,
生成page_visit_log的sql,插入数据库
每种日志项的格式有所不同,所以需要以名称标识,总共有13种日志。
所以类似的代码要写13次。
即使使用过程方式,也要在过程内部写13种case,而且由于代码不在一起,维护更麻烦。
如果用对象抽象:
数据抽象
--日志格式 (日志格式主要是列的名称定义)
行为抽象
--根据日志格式进行解析(条件行为)
--根据日志格式生成sql,为了性能,需要同种的日志能够叠加后批量插入
按照这样的描述,我们可以以日志格式作为构造的参数设计Parser类。
class Parser {
构造函数:日志格式名称 {
根据名称读入相关的格式
}
日志解析:日志项 {
}
生成sql: 解析后结果 {
}
}
嗯,早上来了,继续编辑。
不过我的意见是,对初学者不要考虑太多理论上的东西,实际多尝试用设计模式解决问题后再来
自己体会比较好。
大家先看看吧。
今天,年轻的同事又来问我一个日志分析程序的设计。
帮他把程序由原来的每种格式需要写一段代码,改成了根据配置,调用不同的Parser实例进行处理的程序。
使我想起了一直困扰我的一个问题,什么是对象?
刚接触到面向对象,是看c++的书,第一句话,对象是对实际事物的抽象,从此陷入万劫不复之境地。
反而无法正确的面向对象设计。
直至工作一段时间,看别人的程序,自己写,使用设计模式。
到今天,可以用OO的设计简化代码,并给程序带来简单扩展性时,再回头来看,这个定义是一个极大陷阱。
(下面才开始我的想法,呵呵,写点铺垫)
OO里,从语言上来讲一个Object是一堆成员变量和方法的结合体。
从我的程序设计经验来讲,对象并不仅仅是对事物的抽象。
中学在电脑班学习数据结构的时候,对一句话印象深刻:
数据结构+算法 才是完整的算法
借鉴这个说法,对象是同时对事物和行为的抽象。
对事物的抽象
简单事物(pojo)
有关联的多个事物
事物之间的关联
对行为的抽象
独立行为,简单行为,比如string的trim操作。
上下文相关行为,根据环境不同,输入的参数会导致不同的结果。
条件行为,输入的参数包含数据和条件,根据条件不同导致会导致行为不同。
以我同事的那个项目为例,原有的设计是:
读入一行日志
分解成多个日志项,每一个项有一个格式名称
对于incoming log进行进行日志的解析
对于page_visit_log进行日志的解析
生成incoming log的sql,插入数据库,
生成page_visit_log的sql,插入数据库
每种日志项的格式有所不同,所以需要以名称标识,总共有13种日志。
所以类似的代码要写13次。
即使使用过程方式,也要在过程内部写13种case,而且由于代码不在一起,维护更麻烦。
如果用对象抽象:
数据抽象
--日志格式 (日志格式主要是列的名称定义)
行为抽象
--根据日志格式进行解析(条件行为)
--根据日志格式生成sql,为了性能,需要同种的日志能够叠加后批量插入
按照这样的描述,我们可以以日志格式作为构造的参数设计Parser类。
class Parser {
构造函数:日志格式名称 {
根据名称读入相关的格式
}
日志解析:日志项 {
}
生成sql: 解析后结果 {
}
}
嗯,早上来了,继续编辑。
不过我的意见是,对初学者不要考虑太多理论上的东西,实际多尝试用设计模式解决问题后再来
自己体会比较好。