相关疑难解决方法(0)

我理解依赖注入本身的好处.我们以Spring为例.我也了解其他Spring功能的好处,如AOP,不同类型的帮助等等.我只是想知道,XML配置有哪些好处,例如:

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

与普通的旧java代码相比,例如:

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

这是更容易调试,编译时间检查,任何只知道java的人都可以理解.那么依赖注入框架的主要目的是什么？(或显示其好处的一段代码.)

更新:
如果是

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

如果有多个,IoC框架如何猜测我希望注入哪个myService实现？如果只有一个给定接口的实现,并且我让IoC容器自动决定使用它,它将在第二个实现出现后被破坏.如果故意只有一个可能的接口实现,那么你不需要注入它.

看到IoC的一小部分配置显示它的好处真的很有趣.我已经使用Spring一段时间了,我无法提供这样的例子.我可以展示单行,它们展示了我使用的hibernate,dwr和其他框架的好处.

更新2:
我意识到可以在不重新编译的情况下更改IoC配置.这真的是个好主意吗？我可以理解,有人想要在不重新编译的情况下更改数据库凭据 - 他可能不是开发人员.在您的实践中,开发人员以外的其他人更改IoC配置的频率如何？我认为对于开发人员来说,没有努力重新编译该特定类而不是更改配置.对于非开发人员,您可能希望让他的生活更轻松,并提供一些更简单的配置文件.

更新3:

接口与其具体实现之间的映射的外部配置

使它延伸有什么好处？你没有把你的所有代码都放在外部,而你绝对可以 - 只需将它放在ClassName.java.txt文件中,即时手动读取和编译 - 哇,你避免重新编译.为什么要避免编译？!

您可以节省编码时间,因为您以声明方式提供映射,而不是在过程代码中

我知道有时声明性方法可以节省时间.例如,我只声明bean属性和DB列之间的映射,并且hibernate在加载,保存,基于HSQL构建SQL等时使用此映射.这是声明性方法的工作原理.对于Spring(在我的示例中),声明具有更多行并且具有与对应代码相同的表达性.如果有一个例子,这种声明比代码短 - 我希望看到它.

控制反转原理允许简单的单元测试,因为您可以用假的替换实际的实现(比如用内存替换SQL数据库)

我确实理解控制优势的反转(我更喜欢将这里讨论的设计模式称为依赖注入,因为IoC更通用 - 有很多种控制,我们只反转其中一种 - 控制初始化).我在问为什么有人为了它需要的东西而不是编程语言.我绝对可以使用代码替换真假实现.并且此代码将表达与配置相同的内容 - 它将仅使用伪值初始化字段.

mary = new FakeFemale();

我确实理解DI的好处.我不明白外部XML配置与配置执行相同操作的代码相比会带来哪些好处.我不认为应该避免编译 - 我每天编译,我还活着.我认为DI的配置是声明性方法的坏例子.如果声明一次并且以不同方式多次使用声明,则声明可能很有用 - 例如hibernate cfg,其中bean属性和DB列之间的映射用于保存,加载,构建搜索查询等.Spring DI配置可以很容易地转换为配置代码,就像在这个问题的开头,它可以吗？它只用于bean初始化,不是吗？这意味着声明式方法不会在这里添加任何内容,是吗？

当我声明hibernate映射时,我只是给hibernate一些信息,它基于它工作 - 我不告诉它该怎么做.在春天的情况下,我的宣言告诉春天应该做什么 - …

在我的分析器报告中,我越来越多地看到依赖注入的基于模拟的测试结果.许多依赖项都是静态的,但是因为我们想要单独测试方法,所以它们会更改为实例成员,如下例所示:

class ShortLivedThing {
   IDependency1 dep1;
   IDependency1 dep2;
   IDependency1 dep3;
   ...

   int TheRealData;

   // Constructor used in production 
   public ShortLivedThing() {
     dep1 = new Dep1(); dep2 = new Dep2(); dep3 = new Dep3();
   }

   // DI for testing 
   public ShortLivedThing(IDependency1 d1, IDependency2 d2, IDependency3 d3) { 
     dep1 = d1(); dep2 = d2(); dep3 = d3();
   }
}

反过来,依赖关系大部分时间都有其他依赖关系,依此类推.每次在测试之外进行方法调用时,这导致(实际上是"静态")对象树的实例化.每个对象都非常小(只有几个指针),但树效果将其变为不断增加的性能.

我们对于它可以做些什么呢？

我正在尝试设计一种更灵活的Singleton形式.

我想解决的问题如下:

• 单身人士无法轻易进行测试.
• 他们滥用面向对象的方法,不允许继承,代码变得线性,许多开发人员倾向于过度使用它们.
• 它们仅限于一个实例,在重复相同机制的意义上而不重复类本身(例如,ThreadPool作为每个应用程序的单例操作的方式,但每个应用程序都有自己的实例).

现在,我到目前为止提出的解决方案如下:

• 使Singleton类成为具有内部构造函数的常规公共类(只能由同一个包的类访问).
• 与每个面向产品的类一样,所有静态属性和静态常量都被移动到一个内部SingletonShared类,该类将作为参数传递给Singleton的构造函数.这两个隐藏在公众背后SingletonFactory,具有静态方法getInstance(key).
• 在情况下,我们所面对的是更复杂的系统,其中每个单需要它自己的一套独特的参数,我加的静态方法setAdapter(adapter)的SingletonFactory.使用该方法getShared(key),实现的类ISingletonAdapter 应该返回该SingletonShared实例的值(例如, SingletonXmlAdapter将Xml文件传递给构造函数,并根据给定的键对某个节点进行反序列化).

以上所有都包装Singleton在一起.

现在,出于测试能力的目的,可以选择将Singleton标记为内部类,并使其实现ISingleton公共接口.

问题:

1. 这个解决方案可以接受
2. 是否有更好/更清洁/更短的方法来达到同样的效果？
3. 哪个版本最好(Singleton作为内部与构造函数作为内部)？

谢谢!