实例化

一、面向对象编程 面向对象--Object Oriented Programming，简称oop，是一种程序设计思想。在说面向对象之前，先说一下什么是编程范式，编程范式你按照什么方式来去编程，去实现一个功能。举个例子，你要做饭，可以用电磁炉，也可以用煤气灶。不同的编程范式本质上代表对各种类型的任务采取的不同的解决问题的思路，两种最重要的编程范式分别是面向过程编程和面向对象编程。 提到面向对象，就不得不提到另一种编程思想，面向过程；什么是面向过程呢，面向过程的思想是把一个项目、一件事情按照一定的顺序，从头到尾一步一步地做下去，先做什么，后做什么，一直到结束。这种思想比较好理解，其实这也是一个人做事的方法，我们之前编程的思想也都是使用这种思想。这种编程思想，只要前面有一个步骤变了，那么后面的就也要变，后面维护起来比较麻烦，这样的编程思想，我们在写一些简单的小程序、只执行一次的脚本时可以使用。而面向对象呢，面向对象的思想是把一个项目、一件事情分成更小的项目，或者说分成一个个更小的部分，每一部分负责什么方面的功能，最后再由这些部分组合而成为一个整体。这种思想比较适合多人的分工合作，就像一个大的机关，分各个部门，每个部门分别负责某样职能，各个部门可以充分发挥自己的特色，只要符合一定前提就行了。 举个例子：比如刚才说的一个大的机关，要做某一个项目，从面向过程的思想来说，应该是这样分析的

spring容器高层视图 Spring 启动时读取应用程序提供的Bean配置信息，并在Spring容器中生成一份相应的Bean配置注册表，然后根据这张注册表实例化Bean，装配好Bean之间的依赖关系，为上层应用提供准备就绪的运行环境。 Bean缓存池：HashMap实现 IOC容器介绍 Spring 通过一个配置文件描述 Bean 及 Bean 之间的依赖关系，利用 Java 语言的反射功能实例化 Bean 并建立 Bean 之间的依赖关系。 Spring 的 IoC 容器在完成这些底层工作的基础上，还提供了 Bean 实例缓存、生命周期管理、 Bean 实例代理、事件发布、资源装载等高级服务。 BeanFactory 是 Spring 框架的基础设施，面向 Spring 本身； ApplicationContext 面向使用 Spring 框架的开发者，几乎所有的应用场合我们都直接使用 ApplicationContext 而非底层的 BeanFactory。 BeanFactory BeanFactory体系架构： BeanDefinitionRegistry ： Spring 配置文件中每一个节点元素在 Spring 容器里都通过一个 BeanDefinition 对象表示，它描述了 Bean 的配置信息。而 BeanDefinitionRegistry

easySpring 在学到Java的Spring容器概念这里，我参考网上的博客和自己的理解实现了一个简易的Spring容器也就是这个项目。该项目分为 up 和 down 两部分。 up 模块只实现了最简单的IOC和AOP功能，两者并没有联系起来。 后来在 down 中实现了更复杂的IOC、AOP功能，并使两者能够很好地进行协作。 1. 简单的IOC和AOP的实现 1.1 简单的IOC容器实现 先从简单的 IOC 容器实现开始，最简单的 IOC 容器只需4步即可实现，如下： 加载 xml 配置文件，遍历其中的 标签 获取标签中的 id 和 class 属性，加载 class 属性对应的类，并创建 bean 遍历 标签中的 标签，获取属性值，并将属性值填充到 bean 中 将 bean 注册到 bean 容器中 代码结构如下： SimpleIOC // IOC 的实现类，实现了上面所说的4个步骤 SimpleIOCTest // IOC 的测试类 Car // IOC 测试使用的 bean Wheel // 同上 ioc . xml // bean 配置文件 容器实现类 SimpleIOC 的代码： package easySpring . up . ioc ; import org . w3c . dom . Document ; import org . w3c . dom .

Oracle中的视图和实例化视图之间有什么区别？ #1楼 物化视图 -磁盘上包含查询结果集的表 非标准化视图 -从基础表中提取数据的查询 #2楼 在Mike McAllister的漂亮回答中加了... 当编译器认为视图查询很 简单 时，只能将实例化视图设置为通过数据库 自动 刷新以检测更改。 如果认为它太复杂，它将无法设置本质上是内部触发器的组件来跟踪源表中的更改，从而仅更新mview表中的更改行。 创建实例化视图时，您会发现Oracle同时创建了mview 和具有相同名称的表 ，这会使事情变得混乱。 #3楼 视图： 视图只是一个命名查询。 它不存储任何内容。 视图上存在查询时，它将运行视图定义的查询。 实际数据来自表。 物化视图： 物理存储数据并定期更新。 查询MV时，它会提供MV中的数据。 #4楼 物化视图是由选择查询驱动的数据逻辑视图，但是查询结果将存储在表或磁盘中，查询的定义也将存储在数据库中。 物化视图的性能优于普通视图，因为物化视图的数据将存储在表中，并且表可能会被索引，因此连接速度更快，并且在物化视图刷新时也会进行连接，因此无需每次触发连接语句，视情况而定。 其他区别包括：在使用View的情况下，我们总是获取最新数据，但是在实现视图的情况下，我们需要刷新视图以获取最新数据。 在实例化视图的情况下，我们需要额外的触发器或某种自动方法，以便我们可以保持MV的刷新

Java内部类 1、内部类分为成员内部类、静态嵌套类、方法内部类、匿名内部类。 几种内部类的共性： A、内部类仍然是一个独立的类，在编译之后会内部类会被编译成独立的.class文件，但是前面冠以外部类的类命和$符号。 B、内部类不能用普通的方式访问。内部类是外部类的一个成员，因此内部类可以自由地访问外部类的成员变量，无论是否是private的。 2、 成员内部类 形式如下： class Outer { class Inner{} } 编译上述代码会产生两个文件：Outer.class和Outer$Inner.class。 成员内部类内不允许有任何静态声明！下面代码不能通过编译。 class Inner{ static int a = 10; } 能够访问成员内部类的唯一途径就是通过外部类的对象！ A、从外部类的非静态方法中实例化内部类对象。 class Outer { private int i = 10; public void makeInner(){ Inner in = new Inner(); in.seeOuter(); } class Inner{ public void seeOuter(){ System.out.print(i); } } } 表面上，我们并没有创建外部类的对象就实例化了内部类对象，和上面的话矛盾。事实上

一、单例模式 单例模式分为以下8种： 饿汉式： 静态常量 静态代码块 懒汉式： 线程不安全 线程安全，同步方法 线程安全，同步代码块 双重检查 静态内部类 枚举 单例模式的使用场景： 需要频繁创建和销毁的对象；创建时耗时过多或消耗资源过多，但又经常用到的对象（比如session工厂、数据源等） （1）饿汉式 - 静态常量写法 代码实现： /** * 设计模式之单例模式 * 饿汉式（静态常量） * * @author song * @create 2020/3/4 15:08 */ public class SingletonTest01 { public static void main(String[] args) { Singleton instance1 = Singleton.getInstance(); Singleton instance2 = Singleton.getInstance(); System.out.println("两次获取的实例一样吗：" + (instance1 == instance2)); //true } } class Singleton { //私有构造方法，使其不可在外部通过构造器实例化 private Singleton() { } //定义为常量，保证实例对象不变 private final static Singleton

目录 1 IGame游戏公司的故事 1.1 讨论会 1.2 实习生小李的实现方法 1.3 架构师的建议 1.4 小李的小结 2 探究依赖注入 2.1 故事的启迪 2.2 正式定义依赖注入 3 依赖注入那些事儿 3.1 依赖注入的类别 3.1.1 Setter注入 3.1.2 Construtor注入 3.1.3 依赖获取 3.2 反射与依赖注入 3.3 多态的活性与依赖注入 3.3.1 多态性的活性 3.3.2 不同活性多态性依赖注入的选择 4 IoC Container 4.1 IoC Container出现的必然性 4.2 IoC Container的分类 4.2.1 重量级IoC Container 4.2.2 轻量级IoC Container 4.3 .NET平台上典型IoC Container推介 4.3.1 Spring.NET 4.3.2 Unity 参考文献 1 IGame游戏公司的故事 1.1 讨论会 话说有一个叫IGame的游戏公司，正在开发一款ARPG游戏（动作&角色扮演类游戏，如魔兽世界、梦幻西游这一类的游戏）。一般这类游戏都有一个基本的功能，就是打怪（玩家攻击怪物，借此获得经验、虚拟货币和虚拟装备），并且根据玩家角色所装备的武器不同，攻击效果也不同。这天，IGame公司的开发小组正在开会对打怪功能中的某一个功能点如何实现进行讨论

1 Ioc是什么？ Ioc：Inversion of Control，控制反转，控制权从应用程序转移到框架（如Ioc容器），是框架的共有特性。 1.1 为什么需要IoC容器？IoC容器是如何演变的？ （1）、应用程序主动控制对象的实例化及依赖装配 a. A a = new AImpl(); B b = new BImpl(); a.setB(b); 本质：创建对象，主动实例化，直接获取依赖，主动装配 缺点：更换实现需要重新编译源代码 　　　很难更换实现、难于测试 耦合实例生产者和实例消费者 b. A a = AFactory.createA(); B b = BFactory.createB(); a.setB(b); 本质：创建对象，被动实例化，间接获取依赖，主动装配 （简单工厂） 缺点：更换实现需要重新编译源代码 很难更换实现、难于测试 c. A a = Factory.create(“a”); B b = Factory.create(“b”); a.setB(b); <!—配置.properties--> a=AImpl b=BImpl 本质：创建对象，被动实例化，间接获取依赖， 主动装配 （工厂+反射+properties配置文件、 Service Locator、注册表） 缺点：冗余的依赖装配逻辑 (2)、可配置通用工厂 ： 工厂主动控制 ，应用程序被动接受

从Java1.1开始引入了内部类以来，它就引起了人们的激烈争论。其实任何优秀的语言特性用得不好就是滥用，内部类用得不好就会导致代码像迷宫一样，导致出现毫无重用的综合征。 1、内部类分为成员内部类、静态嵌套类、方法内部类、匿名内部类。 几种内部类的共性： A、内部类仍然是一个独立的类，在编译之后会内部类会被编译成独立的.class文件，但是前面冠以外部类的类命和$符号。 B、内部类不能用普通的方式访问。内部类是外部类的一个成员，因此内部类可以自由地访问外部类的成员变量，无论是否是private的。 2、成员内部类：形式如下 class Outer { class Inner{} } 编译上述代码会产生两个文件：Outer.class和Outer$Inner.class。 成员内部类内不允许有任何静态声明！下面代码不能通过编译。 class Inner{ static int a = 10; } 能够访问成员内部类的唯一途径就是通过外部类的对象！ A、从外部类的非静态方法中实例化内部类对象。 class Outer { private int i = 10 ; public void makeInner(){ Inner in = new Inner(); in.seeOuter(); } class Inner{ public void seeOuter(){ System.out

这是与Java/C++的巨大不同。目前还没仔细想这个特征与TClass之间的联系，先记住结论再说。以后再回来修改这个帖子。 unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; TXXX = class(TObject) private FList: TList; protected function PeekItem: Pointer; virtual; abstract; property List: TList read FList; public constructor Create; destructor Destroy; override; procedure Show; end; var Form1: TForm1; implementation {$R *.dfm}