Oop分析方法

为了实现Oop，这个我已经在一个前端的js项目中实现了Oop,过后总结：对于js这种动态语言，可以在运行时动态组件对象的属性和方法这种，解释型的语言来讲，真的是OOP，如果不存在关系数据库，仅仅是从后端来取数据，这样，保持数据的完整性，将前端作为一个一个的组件模块化来开发真的是一个好的方法。

我的方法总结，实现了string.format，然后Js与Html和css的完全分离，jquery类库的使用上，体现出了context 上下文和selector这种模块化的思想。

各种Oop的语言究其根本来讲，方法是通用的，oop语言的优势就在于复用上，于最近在尝试的ddd中的方法很像，但大体，我还是喜欢使用外观来分所有的外部挂载的service，在Js中的放，就相当于是一commonjs规范？

总之就是单页应用了，前端的模块化思想。

oop思想的总结：模板，继承，事件，对于design pattern,抽象接口，其实就是把操作给分出来，就像是cqrs架构，然后 bounded context这样的思想，使用各种设计模式的话，将交互分离出来。解耦合，然后.net层与ui controller分离采用的则是ioc。

这样界面层就完全不用考虑实现，体现的oop中的基于接口而非实现。

关于Ioc容器的实现，以及.net中的aop，静态语言中大部分都通过反射，而泛型是类的模板。

其实说到底 各种design　ｐａｔｔｅｒ归根到底只是一种限制的策略，为了达到各对象的相应独立性，严格限制起来，别人无法调用，那么也就达到了相对无关性，因为其他的方式是无法访问的！

最近看到ＤＤＤ，对ｅｖａｎｓ的各种模式也看了，今天翻看了一下，然后对比了以前看ＦＯＷＬＥＲ的分析模式这样。

最后我自己的总结：　感觉是　对于一个实体，发散思维的话就是：人物地时事

什么人什么时间什么地点用什么东西多长时间做了什么事，产生了什么影响

与四色原型挺像的

这是一个起点，从起点来分析的话，再以一泛化出多个，也就出现了ｆｏｌｗｅｒ的　所谓团体模式等等一些模式

然后就是分类了，角色分类，人物分类，地点分类，时间分类，长短，事件分类

然后把各种操作作为上下文来处理。内部达到一个相对封闭的团体。