人气：530286
访问用户量：1166
笔记经验：
总积分：1958
级别：普通会员
搜索本笔记
ta的交流分类
ta的全部笔记
浏览(8502)|(1)
&&交流分类：|笔记分类:
10.3& 模式讲解
10.3.1& 认识中介者模式
（1）模式的功能
中介者的功能非常简单，就是封装对象之间的交互。如果一个对象的操作会引起其它相关对象的变化，或者是某个操作需要引起其它对象的后续或连带操作，而这个对象又不希望自己来处理这些关系，那么就可以找中介者，把所有的麻烦扔给它，只在需要的时候通知中介者，其它的就让中介者去处理就可以了。
&&&&&& 反过来，其它的对象在操作的时候，可能会引起这个对象的变化，也可以这么做。最后对象之间就完全分离了，谁都不直接跟其它对象交互，那么相互的关系，全部被集中到中介者对象里面了，所有的对象就只是跟中介者对象进行通信，相互之间不再有联系。
把所有对象之间的交互都封装在中介者当中，无形中还得到另外一个好处，就是能够集中的控制这些对象的交互关系，这样有什么变化的时候，修改起来就很方便。
（2）需要Mediator接口吗
&&&&&& 要回答这个问题，先要搞清楚一件事情，接口用来干什么的？对，接口是用来实现“封装隔离”的，那么封装谁？隔离谁呢？Mediator接口嘛，肯定是用来封装中介者对象的，使得使用中介者对象的客户对象跟具体的中介者实现对象分离开。
&&&&&& 了解了上面这些内容，回过来想想，有没有使用Mediator接口的必要，那就取决于是否会提供多个不同的中介者实现。如果中介者实现只有一个的话，而且预计中也没有需要扩展的要求，那么就可以不定义Mediator接口，让各个同事对象直接使用中介者实现对象；如果中介者实现不只一个，或者预计中有扩展的要求，那么就需要定义Mediator接口，让各个同事对象来面向中介者接口编程，而无需关心具体的中介者实现。
（3）同事关系
&&&&&& 在标准的中介者模式中，把使用中介者对象来交互的那些对象称为同事类，这不是乱叫的，在中介者模式中，要求这些类都要继承相同的类，也就是说，这些对象从某个角度讲是同一个类型，算是兄弟对象。
&&&&&& 正是这些兄弟对象之间的交互关系很复杂，才产生了把这些交互关系分离出去，单独做成中介者对象，这样一来，这些兄弟对象就成了中介者对象眼里的同事。
（4）同事和中介者的关系
&&&&&& 在中介者模式中，当一个同事对象发生了改变，需要主动通知中介者，让中介者去处理与其它同事对象相关的交互。
&&&&&& 这就导致了同事对象和中介者对象之间必须有关系，首先是同事对象需要知道中介者对象是谁；反过来，中介者对象也需要知道相关的同事对象，这样它才能与同事对象进行交互。也就是说中介者对象和同事对象之间是相互依赖的。
（5）如何实现同事和中介者的通信
&&&&&& 一个同事对象发生了改变，会通知中介者对象，中介者对象会处理与其它同事的交互，这就产生了同事对象和中介者对象的相互通信。怎么实现这种通信关系呢？
&&&&&& 一种实现方式是在Mediator接口中定义一个特殊的通知接口，作为一个通用的方法，让各个同事类来调用这个方法，在中介者模式结构图里画的就是这种方式。在前面示例的也是这种方式，定义了一个通用的changed方法，并且把同事对象当做参数传入，这样在中介者对象里面，就可以去获取这个同事对象的实例的数据了。
&&&&&& 另外一种实现方式是可以采用观察者模式，把Mediator实现成为观察者，而各个同事类实现成为Subject，这样同事类发生了改变，会通知Mediator。Mediator在接到通知过后，会与相应的同事对象进行交互。
（6）中介者模式的调用顺序示意图
中介者模式的调用顺序如图10.5所示：
图10.5& 中介者模式的调用顺序示意图
10.3.2& 广义中介者
仔细查看中介者的结构、定义和示例，会发现几个问题，使得中介者模式在实际使用的时候，变得繁琐或困难。
其一：是否有必要为同事对象定义一个公共的父类？
大家都知道，Java是单继承的，为了使用中介者模式，就让这些同事对象继承一个父类，这是很不好的；再说了，这个父类目前也没有什么特别的公共功能，也就是说继承它也得不到多少好处。
在实际开发中，很多相互交互的对象本身是没有公共父类的，强行加上一个父类，会让这些对象实现起来特别别扭。
其二：同事类有必要持有中介者对象吗？
同事类需要知道中介者对象，以便当它们发生改变的时候，能够通知中介者对象，但是，是否需要作为属性，并通过构造方法传入，这么强的依赖关系呢？
也可以有简单的方式去通知中介对象，比如把中介对象做成单例，直接在同事类的方法里面去调用中介者对象。
其三：是否需要中介者接口？
在实际开发中，很常见的情况是不需要中介者接口的，而且中介者对象也不需要创建很多个实例，因为中介者是用来封装和处理同事对象的关系的，它一般是没有状态需要维护的，因此中介者通常可以实现成单例。
其四：中介者对象是否需要持有所有的同事？
虽说中介者对象需要知道所有的同事类，这样中介者才能与它们交互。但是是否需要做为属性这么强烈的依赖关系，而且中介者对象在不同的关系维护上，可能会需要不同的同事对象的实例，因此可以在中介者处理的方法里面去创建、或者获取、或者从参数传入需要的同事对象。
其五：中介者对象只是提供一个公共的方法，来接受同事对象的通知吗？
从示例就可以看出来，在公共方法里，还是要去区分到底是谁调过来，这还是简单的，还没有去区分到底是什么样的业务触发调用过来的，因为不同的业务，引起的与其它对象的交互是不一样的。
因此在实际开发中，通常会提供具体的业务通知方法，这样就不用再去判断到底是什么对象，具体是什么业务了。
&&&&&& 基于上面的考虑，在实际应用开发中，经常会简化中介者模式，来使开发变得简单，比如有如下的简化：
通常会去掉同事对象的父类，这样可以让任意的对象，只要需要相互交互，就可以成为同事；
还有通常不定义Mediator接口，把具体的中介者对象实现成为单例；
另外一点就是同事对象不再持有中介者，而是在需要的时候直接获取中介者对象并调用；中介者也不再持有同事对象，而是在具体处理方法里面去创建、或者获取、或者从参数传入需要的同事对象。
&&&&&& 把这样经过简化、变形使用的情况称为广义中介者。
&&&&&& 还是来举个实际点的例子看看吧。
1：部门与人员
几乎在每个应用系统中都需要这样的功能模块：部门管理、人员管理，为了简单点演示，把模块简化成类，也就是有一个部门类Dep和人员类User。
&&&&&& 首先想想部门类Dep和人员类User之间是什么关系，一对一？一对多？还是多对多？
&&&&&& 可能在不同的系统里面，根据需要会做成不同的关系，但从实际情况讲，部门和人员应该是多对多的，也就是一个部门可以有多个人，而一个人也可以加入多个部门。
&&&&&& 对于一个部门有多个人，估计大家都能理解。而一个人也可以加入多个部门，或许有些朋友就觉得有些问题了，因为在他们做系统的经验上，是一个人只属于一个部门的。
事实上一个人是可以属于多个部门的，比如：某人是开发部的经理，同时也是销售部门的技术总监，为销售部门给客户的解决方案中的技术部分进行把关，同时还可以是客户服务部门的技术顾问，为他们解决客户的技术问题提供指导。
&&&&&& 好了，理解了部门和人员是多对多的关系过后，有些朋友可能会做出如下的设计，不就是个多对多吗，类之间的多对多也很容易表达啊，如下：
public class Dep { &&& private Collection&User& colUser = new ArrayList&User&(); } public class User { &&& private Collection&Dep& colDep = new ArrayList&Dep&(); }
很简单，是吧，一个部门有多个人员，一个人员属于多个部门。
2：问题的出现
&&& 真的这么简单吗？再进一步想想部门和人员的功能交互，就会知道这样设计是存在问题的，举几个常见的功能：
部门被撤销
部门之间进行合并
人员从一个部门调职到另外一个部门
想想要实现这些功能，按照前面的设计，该怎么做呢？
（1）系统运行期间，部门被撤销了，就意味着这个部门不存在了，可是原来这个部门下所有的人员，每个人员的所属部门中都有这个部门呢，那么就需要先通知所有的人员，把这个部门从它们的所属部门中去掉，然后才可以清除这个部门。
（2）部门合并，是合并成一个新的部门呢，还是把一个部门并入到另一个部门？如果是合并成一个新的部门，那么需要把原有的两个部门撤销，然后再新增一个部门；如果是把一个部门合并到另一个部门里面，那就是撤销掉一个部门，然后把这个部门下的人员移动到这个部门。不管是那种情况，都面临着需要通知相应的人员进行更改这样的问题。
（3）人员离职了，反过来就需要通知他所属于的部门，从部门的拥有人员的记录中去除掉这个人员。
（4）人员调职，同样需要通知相关的部门，先从原来的部门中去除掉，然后再到新的部门中添加上。
看了上述的描述，感觉如何？是不是“烦就一个字”啊！
&&&&&& 麻烦的根源在什么地方呢？仔细想想，对了，麻烦的根源就在于部门和人员之间的耦合，这样导致操作人员的时候，需要操作所有相关的部门，而操作部门的时候又需要操作所有相关的人员，使得部门和人员搅和在了一起。
3：中介者来解决
找到了根源就好办了，采用中介者模式，引入一个中介者对象来管理部门和人员之间的关系，就能解决这些问题了。
如果采用标准的中介者模式，想想上面提出的那些问题点吧，就知道实现起来会很别扭。因此采用广义的中介者来解决，这样部门和人员就完全解耦了，也就是说部门不知道人员，人员也不知道部门，它们完全分开，它们之间的关系就完全由中介者对象来管理了。这个时候的结构如图10.6所示：
图10.6& 引入中介者后的结构示意图
好了，还是看代码示例会比较清晰。
4：实现示例&&&
（1）首先定义部门类，示例代码如下：
/** &* 部门类 &*/ public class Dep{ &&& /** &&& &* 描述部门编号 &&& &*/ &&& private String depId; &&& /** &&& &* 描述部门名称 &&& &*/ &&& private String depN & &&& public String getDepId() { &&&&&& return depId; &&& } &&& public void setDepId(String depId) { &&&&&& this.depId = depId; &&& } &&& public String getDepName() { &&&&&& return depN &&& } &&& public void setDepName(String depName) { &&&&&& this.depName = depN &&& } &&& /** &&& &* 撤销部门 &&& &* @return 是否撤销成功 &&& &*/ &&& public boolean deleteDep(){ &&&&&& //1：要先通过中介者去清除掉所有与这个部门相关的部门和人员的关系 &&&&&& DepUserMediatorImpl mediator =
DepUserMediatorImpl.getInstance(); &&&&&& mediator.deleteDep(depId); &&&&&& //2：然后才能真的清除掉这个部门 &&&&&& //请注意在实际开发中，这些业务功能可能会做到业务层去， &&&&&& //而且实际开发中对于已经使用的业务数据通常是不会被删除的， &&&&&& //而是会被做为历史数据保留 &&&&&& &&& } }
（2）接下来定义人员类，示例代码如下：
/** &* 人员类 &*/ public class User{ &&& /** &&& &* 人员编号 &&& &*/ &&& private String userId; &&& /** &&& &* 人员名称 &&& &*/ &&& private String userN & &&& public String getUserId() { &&&&&& return userId; &&& } &&& public void setUserId(String userId) { &&&&&& this.userId = userId; &&& } &&& public String getUserName() { &&&&&& return userN &&& } &&& public void setUserName(String userName) { &&&&&& this.userName = userN &&& } &&& /** &&& &* 人员离职 &&& &* @return 是否处理成功 &&& &*/ &&& public boolean dimission(){ &&&&&& //1：要先通过中介者去清除掉所有与这个人员相关的部门和人员的关系 &&&&&& DepUserMediatorImpl mediator =
DepUserMediatorImpl.getInstance(); &&&&&& mediator.deleteUser(userId); &&&&&& //2：然后才能真的清除掉这个人员 &&&&&& //请注意，实际开发中，人员离职，是不会真的删除人员记录的， &&&&&& //通常是把人员记录的状态或者是删除标记设置成已删除， &&&&&& //只是不再参加新的业务，但是已经发生的业务记录是不会被清除掉的&&&& & &&&&&& &&& } }
（3）顺带看一下描述部门和人员关系的对象，非常简单，示例代码如下：
/** &*& 描述部门和人员关系的类 &*/ public class DepUserModel { &&& /** &&& &* 用于部门和人员关系的编号，用做主键 &&& &*/ &&& private String depUserId; &&& /** &&& &* 部门的编号 &&& &*/ &&& private String depId; &&& /** &&& &* 人员的编号 &&& &*/ &&& private String userId; &&& &&& &&& }
（4）具体的中介者实现
首先中介者要管理部门和人员的关系，所以在中介者实现里面添加了一些测试的数据，为此还专门做了一个用来描述部门和人员关系的数据对象；其次在中介者里面只是实现了撤销部门和人员离职相应的关系处理，其它的没有实现；另外，这个中介者实现被实现成单例的了。示例代码如下：
/** &* 实现部门和人员交互的中介者实现类 &* 说明：为了演示的简洁性，只示例实现撤销部门和人员离职的功能 &*/ public class DepUserMediatorImpl{ &&& private static DepUserMediatorImpl mediator = new DepUserMediatorImpl(); &&& private DepUserMediatorImpl(){ &&&&&& //调用初始化测试数据的功能 &&&&&& initTestData(); &&& } &&& public static DepUserMediatorImpl getInstance(){ &&&&&& return mediator; &&& } &&& &&& /** &&& &* 测试用，记录部门和人员的关系 &&& &*/ &&& private Collection&DepUserModel& depUserCol = new ArrayList&DepUserModel&(); &&& /** &&& &* 初始化测试数据 &&& &*/ &&& private void initTestData(){ &&&&&& //准备一些测试数据 &&&&&& DepUserModel du1 = new DepUserModel(); &&&&&& du1.setDepUserId(&du1&); &&&&&& du1.setDepId(&d1&); &&&&&& du1.setUserId(&u1&);&&&& &&&&&& depUserCol.add(du1); &&&&&& &&&&&& DepUserModel du2 = new DepUserModel(); &&&&&& du2.setDepUserId(&du2&); &&&&&& du2.setDepId(&d1&); &&&&&& du2.setUserId(&u2&);&&&& &&&&&& depUserCol.add(du2); &&&&&& &&&&&& DepUserModel du3 = new DepUserModel(); &&&&&& du3.setDepUserId(&du3&); &&&&&& du3.setDepId(&d2&); &&&&&& du3.setUserId(&u3&);&&&& &&&&&& depUserCol.add(du3); &&&&&& &&&&&& DepUserModel du4 = new DepUserModel(); &&&&&& du4.setDepUserId(&du4&); &&&&&& du4.setDepId(&d2&); &&&&&& du4.setUserId(&u4&);&&&& &&&&&& depUserCol.add(du4); &&&&&& &&&&&& DepUserModel du5 = new DepUserModel(); &&&&&& du5.setDepUserId(&du5&); &&&&&& du5.setDepId(&d2&); &&&&&& du5.setUserId(&u1&);&&&& &&&&&& depUserCol.add(du5); &&& } &&& /** &&& &* 完成因撤销部门的操作所引起的与人员的交互，需要去除相应的关系 &&& &* @param depId 被撤销的部门对象的编号 &&& &* @return 是否已经正确的处理了因撤销部门所引起的与人员的交互 &&& &*/ &&& public boolean deleteDep(String depId) { &&&&&& //请注意：为了演示简单，部门撤销后， &&&&&& //原部门的人员怎么处理等后续业务处理，这里就不管了 &&&&&& &&&&&& //1：到记录部门和人员关系的集合里面，寻找跟这个部门相关的人员 &&&&&& //设置一个临时的集合，记录需要清除的关系对象 &&&&&& Collection&DepUserModel& tempCol = new ArrayList&DepUserModel&(); &&&&&& for(DepUserModel du : depUserCol){ &&&&&&&&&& if(du.getDepId().equals(depId)){ &&&&&&&&&&&&& //2：需要把这个相关的记录去掉，先记录下来 &&&&&&&&&&&&& tempCol.add(du); &&&&&&&&&& } &&&&&& } &&&&&& //3：从关系集合里面清除掉这些关系 &&&&&& depUserCol.removeAll(tempCol); &&&&&& &&&&&& &&& } &&& /** &&& &* 完成因人员离职引起的与部门的交互 &&& &* @param userId 离职的人员的编号 &&& &* @return 是否正确处理了因人员离职引起的与部门的交互 &&& &*/ &&& public boolean deleteUser(String userId) { &&&&&& //1：到记录部门和人员关系的集合里面，寻找跟这个人员相关的部门 &&&&&& //设置一个临时的集合，记录需要清除的关系对象 &&&&&& Collection&DepUserModel& tempCol = new ArrayList&DepUserModel&(); &&&&&& for(DepUserModel du : depUserCol){ &&&&&&&&&& if(du.getUserId().equals(userId)){ &&&&&&&&&&&&& //2：需要把这个相关的记录去掉，先记录下来 &&&&&&&&&&&&& tempCol.add(du); &&&&&&&&&& } &&&&&& } &&&&&& //3：从关系集合里面清除掉这些关系 &&&&&& depUserCol.removeAll(tempCol); &&& &&&&&& &&& } &&& /** &&& &* 测试用，在内部打印显示一下一个部门下的所有人员 &&& &* @param dep 部门对象 &&& &*/ &&& public void showDepUsers(Dep dep) { &&&&&& for(DepUserModel du : depUserCol){ &&&&&&&&&& if(du.getDepId().equals(dep.getDepId())){ &&&&&&&&&&&&& System.out.println(&部门编号=&+dep.getDepId() +&下面拥有人员，其编号是：&+du.getUserId()); &&&&&&&&&& } &&&&&& } &&& } &&& /** &&& &* 测试用，在内部打印显示一下一个人员所属的部门 &&& &* @param user 人员对象 &&& &*/ &&& public void showUserDeps(User user) { &&&&&& for(DepUserModel du : depUserCol){ &&&&&&&&&& if(du.getUserId().equals(user.getUserId())){ &&&&&&&&&&&&& System.out.println(&人员编号=&+user.getUserId() +&属于部门编号是：&+du.getDepId()); &&&&&&&&&& } &&&&&& } &&& } &&& /** &&& &* 完成因人员调换部门引起的与部门的交互 &&& &* @param userId 被调换的人员的编号 &&& &* @param oldDepId 调换前的部门的编号 &&& &* @param newDepId 调换后的部门的编号 &&& &* @return 是否正确处理了因人员调换部门引起的与部门的交互 &&& &*/ &&& public boolean changeDep(String userId,String oldDepId , String newDepId) { &&&&&& //本示例不去实现了 &&& &&& &&& } &&& /** &&& &* 完成因部门合并操作所引起的与人员的交互 &&& &* @param colDepIds 需要合并的部门的编号集合 &&& &* @param newDep 合并后新的部门对象 &&& &* @return 是否正确处理了因部门合并操作所引起的与人员的交互 &&& &*/ &&& public boolean joinDep(Collection&String& colDepIds , Dep newDep){ &&&&&& //本示例不去实现了&&&&& &&&&&& &&& } }
（5）测试一下，看看好用不，客户端示例代码如下：
public class Client { &&& public static void main(String[] args) { &&&&&& DepUserMediatorImpl mediator = DepUserMediatorImpl.getInstance(); &&&&&& //准备要撤销的部门，仅仅需要一个部门编号 &&&&&& Dep dep = new Dep(); &&&&&& dep.setDepId(&d1&); &&&&&& Dep dep2 = new Dep(); &&&&&& dep2.setDepId(&d2&); &&&&&& //准备用于测试的人员，也只需要一个人员编号 &&&&&& User user = new User(); &&&&&& user.setUserId(&u1&); &&&&&& &&&&&& //测试撤销部门，在运行之前，输出一下，看这个人员属于哪些部门&&&&&& &&&&&& System.out.println(&撤销部门前------------------&); &&&&&& mediator.showUserDeps(user);&&&&&& &&&&&& //真正执行业务，撤销这个部门 &&&&&& dep.deleteDep();&&&& &&&&&& //再次输出一下，看这个人员属于哪些部门 &&&&&& System.out.println(&撤销部门后------------------&); &&&&&& mediator.showUserDeps(user); &&&&&& &&&&&& //测试人员离职，在运行之前，输出一下，看这个部门下都有哪些人员 &&&&&& System.out.println(&---------------------------------&); &&&&&& System.out.println(&人员离职前------------------&); &&&&&& mediator.showDepUsers(dep2);&&&&&& &&&&&& //真正执行业务，人员离职 &&&&&& user.dimission();&&& &&&&&& //再次输出一下，看这个部门下都有哪些人员 &&&&&& System.out.println(&人员离职后------------------&); &&&&&& mediator.showDepUsers(dep2); &&& } }
测试结果如下：
撤销部门前------------------ 人员编号=u1属于部门编号是：d1 人员编号=u1属于部门编号是：d2 撤销部门后------------------ 人员编号=u1属于部门编号是：d2 --------------------------------- 人员离职前------------------ 部门编号=d2下面拥有人员，其编号是：u3 部门编号=d2下面拥有人员，其编号是：u4 部门编号=d2下面拥有人员，其编号是：u1 人员离职后------------------ 部门编号=d2下面拥有人员，其编号是：u3 部门编号=d2下面拥有人员，其编号是：u4
好好体会一下，看看这样做是不是变得更容易了些，而且也实现了中介者想要实现的功能，那就是让同事对象相互分离，由中介对象统一管理它们的交互。
10.3.3& 中介者模式的优缺点
l&&&&&&&&& 松散耦合 &&& 中介者模式通过把多个同事对象之间的交互封装到中介者对象里面，从而使得同事对象之间松散耦合，基本上可以做到互不依赖。这样一来，同事对象就可以独立的变化和复用，而不再像以前那样“牵一发而动全身”了。
l&&&&&&&&& 集中控制交互 &&& 多个同事对象的交互，被封装在中介者对象里面集中管理，使得这些交互行为发生变化的时候，只需要修改中介者对象就可以了，当然如果是已经做好的系统，那就扩展中介者对象，而各个同事类不需要做修改。
l&&&&&&&&& 多对多变成一对多 &&& 没有使用中介者模式的时候，同事对象之间的关系通常是多对多的，引入中介者对象过后，中介者对象和同事对象的关系通常变成了双向的一对多，这会让对象的关系更容易理解和实现。
l&&&&&&&&& 过度集中化 &&& 中介者模式的一个潜在缺点是，如果同事对象的交互非常多，而且比较复杂，当这些复杂性全部集中到中介者的时候，会导致中介者对象变得十分的复杂，而且难于管理和维护。
10.3.4& 思考中介者模式
1：中介者模式的本质
中介者模式的本质：封装交互。
中介者模式的目的，就是用来封装多个对象的交互，这些交互的处理多在中介者对象里面实现，因此中介对象的复杂程度，就取决于它封装的交互有多复杂了。
&&&&&& 只要是实现封装对象之间的交互功能，就可以应用上中介者模式，而不必过于拘泥于中介者模式本身的结构。标准的中介者模式限制很多，导致能完全按照标准使用中介者模式的地方并不是很多，而且多集中在界面实现上。只要本质不变，稍稍变形一下，简化一下，或许能更好的使用中介者模式。
2：何时选用中介者模式
建议在如下情况中，选用中介者模式：
如果一组对象之间的通信方式比较复杂，导致相互依赖、结构混乱，可以采用中介者模式，把这些对象相互的交互管理起来，各个对象都只需要和中介者交互，从而使得各个对象松散耦合，结构也更清晰易懂。
如果一个对象引用很多的对象，并直接跟这些对象交互，导致难以复用该对象。可以采用中介者模式，把这个对象跟其它对象的交互封装到中介者对象里面，这个对象就只需要和中介者对象交互就可以了。
10.3.5& 相关模式
l&&&&&&&&& 中介者模式和外观模式 &&& 这两个模式有相似的地方，也存在很大的不同。 &&& 外观模式多用来封装一个子系统内部的多个模块，目的是向子系统外部提供简单易用的接口，也就是说外观模式封装的是子系统外部和子系统内部模块间的交互；而中介者模式是提供多个平等的同事对象之间交互关系的封装，一般是用在内部实现上。 &&& 另外，外观模式是实现单向的交互，是从子系统外部来调用子系统内部，不会反着来，而中介者模式实现的是内部多个模块间多向的交互。
l&&&&&&&&& 中介者模式和观察者模式 &&& 这两个模式可以组合使用。 &&& 中介者模式可以组合使用观察者模式，来实现当同事对象发生改变的时候，通知中介对象，让中介对象去进行与其它相关对象的交互。
---------------------------------------------------------------------------
原创内容 &跟着cc学设计系列 之&
原创内容，转载请注明出处【】
---------------------------------------------------------------------------
相关笔记推荐
精品视频课程推荐
深入浅出的讲解JavaBen的写法、JavaBean的用法、JavaBean的实现机制、JavaBean对应翻译的代码理解。
内容概述：Shiro是目前最热门、最易用、功能超强大的Java权限管理框架，强烈推荐，每个项目都必备的权限管理技术！通过本课程，你将从零开始直到彻底掌握Shiro的相关开发知识，达到可以进行实际项目开发的能力。包括：权限管理基础、Shiro入门、配置、身份认证、授权、Realms、Session管理、和Spring的集成、Web、Cache等众多开发细节技术
技术要点：源码级分析Shiro的授权过程、自定义开发Realm、多个Realms的开发配置、自定义开发AuthenticationStrategy、自定义开发自定义SessionDAO、和Struts2+Spring3的集成（包括修正struts2的bug）、Shiro和SpringMVC+Spring3的集成、包装使用其他的Cache框架、缓存数据同步更新的解决方案等等实际开发中常用的内容
本课程是《软件系统功能设计实战训练》网络班的全套学习视频，通过6个具体的设计案例，综合应用几乎全部的GoF设计模式，以及多种设计理念和方法。
每个设计案例都各有侧重点，训练的难度会逐步加大，以切实帮助各位学员快速的掌握软件系统设计的方法，提升自己的软件系统设计能力。
系统、完整的学习Spring Web MVC开发的知识。包括：Spring Web MVC入门；理解DispatcherServlet；注解式控制器开发详解；数据类型转换；数据格式化；数据验证； 拦截器；对Ajax的支持；文件上传下载；表单标签等内容；最后以一个综合的CRUD带翻页的应用示例来综合所学的知识
实现通过Wifi来在局域网内相互传递信息和语音通话的功能；学习Service；Broadcast Receiver；SharedPreference；SQLite；语音录制、播放、传输等；网络开发：wifi处理、UDP编程、TCP编程；多种设计模式的应用 等等
浏览(8502)|(1)
&&交流分类：|笔记分类:
本质:封装交互,松散(对象间)耦合。
版权所有 Copyright(C) 私塾在线学习网}