面向对象，尝试重定义一下

也不知道是不是该放到这个区。
大家先看看吧。

今天，年轻的同事又来问我一个日志分析程序的设计。
帮他把程序由原来的每种格式需要写一段代码，改成了根据配置，调用不同的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： 解析后结果 {
}
}

嗯，早上来了，继续编辑。
不过我的意见是，对初学者不要考虑太多理论上的东西，实际多尝试用设计模式解决问题后再来
自己体会比较好。

学习～
唉，对面向对象的理解还好浅薄，
恩，以后要多用用设计模式。