意外收获：看懂了多态，反射和实现。总是不能静心

写论文的时候，因为想画UML，结果看了一堆有关设计的东西



通俗点讲:反射是用在于一些写程序的时候无法确定是用哪一个类(或接口)而采用的手段,很常用的就是数据库的工厂模式,当我们不知道客户将用access还是SQL Server 还是orcale的时候,为了不跟随客户的需求改来改去,我们就要用到反射



IoC就是Inversion of Control，控制反转。在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。 .... IoC很年轻，还在发展。伴随着IOC的发展，AOP，COP，SOP等等都在不断的发展。作为程序员，随时关注着新的思想的发展是一件public class Girl { void kiss(Boy boy){ // kiss boy boy.kiss(); }}
Well，这是对Girl最好的方法，只要想办法贿赂了Girl的父母，并把Boy交给他。那么我们就可以轻松的和Girl来Kiss了。看来几千年传统的父母之命还真是有用哦。至少Boy和Girl不用自己瞎忙乎了。
这就是IOC，将对象的创建和获取提取到外部。由外部容器提供需要的组件



谢谢棒场，呵呵~楼上的兄弟讲得也太直接了当了，虽然是万物归于原始都是面向对象，但如果只用多态的使用来描述Provider模型的话，我觉得就有点不妥了，因为运用了多态的原理来实现东西太多了，太简单概括可能会使得更混乱而不能达到沟通的作用。想想当年Martin Fowler为什么要重新给IoC重新定义个Dependency Injection字词出来，呵呵。 我觉得Provider模型本身的意图是跟GOF策略模式最能匹配的了，而在API对象中抽象Provider引用的具体Provider实例又是使用工厂模式来实现，当然如果工厂内部都想要做到不直接依赖于具体类(不直接new)，那通常的解决方法就是使用反射了。其实不单是.NET，JAVA也一样是通过反射机制来创建具体类的实例，从而将修改点转移到配置上的。大部分框架涉及到“配置”和“创建实例”基本都是反射机制实现的了，因为.NET和JAVA都支持反射，所以使用反射就算是没有直接new那么高效高速，但也变得理所当然似的了，呵呵



继承的目的是复用，继承复用包括两方面的复用：抽象（接口）复用，实现（过程）复用。 多态的目的就是要将抽象复用及实现复用剥离开来，子类虽然拥有和父类一样的抽象接口，但实现过程却未必一样，多态的引入就是要在继承的基础上实现变异的可能性。当然子类继承也不一定会产生实现差异，所以多态允许在产生差异的时候override父类接口，没有产生差异的时候直接继承。 interface则是另一种复用方式，interface只允许抽象复用，而禁止实现复用，所以interface比继承显得更轻量，但实际上系统中的实现复用必须由其他机制来保证



运行时，才明确具体是指那个对象，这给client代码，带来了很大的灵活性。使依赖注入、针对抽象与接口编程、同一行代码操作不同类的对象(用接口)等等成为可能。



我的观点是大大增强代码的复用性,使得项目架构更加清晰,松耦合. 比如在实际应用中我可以轻松继承一个System.Window.Forms.Control命名空间下的类比如Button打造属于自己的NixButton类而当一些原有系统的方法参数要求的传入的参数类型是Button时,我不必修改原有代码而直接把NixButton的实例对象传进去依然可用. 从而达到代码复用和架构松耦合的效果 子类继承了父类的所有接口,包括invoke handler/object对应表然后按继承关系和invoke handler不同而调用不同的实现代码!



多态是和继承相反的概念 多态是父类调子类的实现，继承是子类调父类的实现，由于多态时不知道会被哪个子类继承，所以定义的东西都是虚函数，当你执行这个虚函数时，首先找到该虚函数代表的实体子类，并执行子类中的相关代码


画uml的过程之我见
zidianjian 发表于 2006-6-3 14:58:00
在画uml的图时，书上介绍的一般是先画系统用例图，再 画时序图等过程。我查资料，看视频讲座等，他们也是仁者见仁，说法不一。经过我自己这段时间的分析，学习，动手画图得出一个结论：首先画的是业务用利图，这一步很重要，（一般书上没有这一步，视频讲座中看到过）。因为我们刚接到一个项目时，还不了解这个公司的情况，有些需求分析就可能理解偏差或者漏掉。所以我们的先 画业务用例图来了解公司的运营过程，本系统在公司的地位等，从开始就要给系统一个准确的定位。接下来就是画系统的用例图，作需求分析。再下来就得画类图，根据需求的名称，动词来获取类。（在一些书中他们认为每个用例都 画一个时序图，画完用例图紧接着就画时序图）。我按书上的过程画下来，但到了生成代码的时候就出错了，因为时序图中的信息在生成代码时要转化成类中的方法，因为在 画时序图的时候还没有画出类图，所以用的都是没有和类对应的对象名。书上一般讲的都是如何画各种 uml图，没有用到生成代码，所以这个问题就没有体现出来。我个人认为在画完用例图后应该先画类图，再画时序图，这样就不会出现上面的问题了。
Re:画uml的过程之我见
bird(游客)发表评论于2006-6-7 17:18:00
根据iconix的思想，需要先画域模型图，可以把它看作是类图的缩版，但是不需要属性，也不需要方法，它起一个规范名称的作用，然后画用例图，写用例文本， 画健壮性分析图，最后画时序图，在这一系列的过程中不断的更新域模型图，在健壮性分析后模型图中已经有了属性，时序图后，方法也应该已经分配给了模型图，最后这样一个域模型图就成了类图，最后要做的就是规范化、模式化了

A use case is a sequence of actions that an actor (usually a person, but perhaps an external entity, such as anothersystem) performs within a system to achieve a particular goal.A use case is most effectively stated from the perspective of the user as a present-tense verb phrase in activevoice. For example, one use case within a travel website might be called “Find Hotel,” while a portfolio system islikely to contain use cases named “Do Trade Entry,” “Update Portfolio Information,” and “Generate Reports.”

ICONIX Process can be broken down into the following steps (the items in bold are the concrete modelingactivities that you perform at each step):
Step 1: Identify your real-world domain objects (domain modeling).
Step 2: Define the behavioral requirements (use cases).
Step 3: Perform robustness analysis to disambiguate the use cases and identify gaps in the domain model.
Step 4: Allocate behavior to your objects (sequence diagrams).
Step 5: Finish the static model (class diagram).
Step 6: Write/generate the code (source code).
7: Perform system and user-acceptance testing.