1.系统架构问题：程序应尽量写成“低耦合，高内聚”。

（名词解释和理解：
耦合：不同的模块拼装到一起，产生相互依赖的关系。
高耦合：不同模块之间连接点很多，造成错综复杂的连接关系，修改程序时牵一发则动全身。
低耦合：模块层次化，我觉得理想的效果是，每一层的模块只与它上一层和下一层的模块进行耦合，同层之间的模块是没有交互的。
）


2.类的四大基本关系：
a.关联关系：如A类调用B类。
b.继承关系：如A类是B类的父类。
c.聚合关系：如装橘子的箱子，箱子是否存在与里面装没装橘子没有任何关系，也就是说橘子不会影响箱子的存在。
d.组合关系：如一个小组，小组是否存在与小组中是否有组员是息息相关的，如果没有组员，小组就不存在了。


3.通过聊天室项目分析系统架构，讲解了事件监听模式：

a.问题：在见面上显示聊天消息时，需要把文本域传给通信模块，在通信模块中把消息显示到文本域上，如果要对界面进行改动的话，需要改动通信模块，修改起来过于蛋疼。



b.解决方案：设计模式之——监听器模式的应用
和按钮加上事件监听器是一个模型




具体化到按钮上：事件源是按钮，监听器是动作监听器。
具体化到聊天室中：事件源是通信模块，监听器待实现。





4.OOA（面向对象分析），OIP（面向接口编程）

还是上述模型，假设我的消息监听器就是一个Class，那么它的功能是捕捉通信模块收到的文本消息，然后显示到界面模块上。如果我要捕捉其他的消息，或者说做出不同的处理呢？如果消息监听器是个Class的话，那么我就要实现多个不同的监听器，并在通信模块中修改代码，也很蛋疼。
换用Interface，把消息监听器定义成一个Interface,那么整个模块图就成下面的样子了。




这样子，我要怎么处理消息，我就怎么处理消息，只需要实现一个新的类就OK了，再也不蛋疼了。
还有一点：消息也定义成Interface，那么我要增加消息的种类只需要实现新的消息类就OK了，不必修改通信模块的代码。
5.总结：设计软件要做到“低耦合，高内聚”，理解四大关系，多用接口，先定规则再实现，根据实际情况选择相应的设计模式，理解胡老师的监听器模式