我理解依赖注入本身的好处.我们以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一些信息,它基于它工作 - 我不告诉它该怎么做.在春天的情况下,我的宣言告诉春天应该做什么 - …
我有很少的异步任务在运行,我需要等到它们中至少有一个完成(将来我可能需要等待N个任务中的util M完成).目前它们被呈现为未来,所以我需要类似的东西
/**
* Blocks current thread until one of specified futures is done and returns it.
*/
public static <T> Future<T> waitForAny(Collection<Future<T>> futures)
throws AllFuturesFailedException
有这样的事吗？或类似的东西,对于Future来说不是必需的.目前我循环收集期货,检查一个是否完成,然后睡一段时间再检查一下.这看起来不是最好的解决方案,因为如果我长时间睡眠会增加不必要的延迟,如果我短时间睡眠则会影响性能.
我可以尝试使用
new CountDownLatch(1)
并在任务完成时减少倒计时并执行
countdown.await()
,但我发现只有控制未来的创造才有可能.这是可能的,但需要重新设计系统,因为当前创建任务的逻辑(将Callable发送到ExecutorService)与决定等待哪个Future分开.我也可以覆盖
<T> RunnableFuture<T> AbstractExecutorService.newTaskFor(Callable<T> callable)
并建立RunnableFuture与附加监听能力的自定义实现时通知任务完成,然后附上这样的监听器所需的任务和使用CountDownLatch,但是这意味着我必须重写newTaskFor每一个ExecutorService的我用 - 可能会有执行它不会扩展AbstractExecutorService.我也可以尝试包装ExecutorService用于同样的目的,但是我必须装饰所有生产Futures的方法.
所有这些解决方案都可行,但看起来非常不自然.看起来我错过了一些简单的东西,比如
WaitHandle.WaitAny(WaitHandle[] waitHandles)
在c#中.针对此类问题,是否有任何众所周知的解决方案？
更新:
最初我根本没有访问Future创建,所以没有优雅的解决方案.重新设计系统后,我得到了进入未来创造并能够countDownLatch.countdown()添加到执行过程中,那么我可以countDownLatch.await(),一切工作正常.谢谢其他答案,我不知道ExecutorCompletionService,并将它的确可以在相似的任务有帮助的,但在这个特殊的情况下,它不能被使用,因为一些期货在没有任何遗嘱执行人创造的 - 实际任务是通过网络发送到另一台服务器,远程完成并收到完成通知.
我想知道,在java 1.6 x64中让许多线程处于等待状态是多么昂贵.
更具体地说,我正在编写跨越许多计算机的应用程序,并将数据从一个计算机发送到另一个计算机.我觉得为每台连接的机器和任务分别设置单独的线程感觉更舒服,例如1)发送数据,2)接收数据,3)删除时重新建立连接.因此,假设集群中有N个节点,则每台机器将为N-1个邻居中的每个节点设置3个线程.通常会有12台机器,它们来自33个通信线程.
这些线程中的大多数将在大多数时间处于休眠状态,因此出于优化目的,我可以减少线程数并为每个线程提供更多工作.比如,例如.重新建立连接是接收线程的责任.或者通过单线程发送到所有连接的机器.
因此,对于拥有许多睡眠线程是否有任何显着的性能影响？
所以,我刚刚转到基于Ruby on Rails构建的新项目.我是新手,我还在学习它.我可以调试大多数应用程序代码,但似乎我无法调试单元测试代码和经过测试的代码.
当我在调试模式下运行单元测试时,我可以在单元测试类代码中设置断点,例如添加夹具的地方,但是断点在测试方法代码中不起作用,并且在测试代码中不起作用,在正常情况下它们在正常情况下工作流程.团队中的其他人都使用print语句进行单元测试调试.
那么,甚至可以在rails中调试单元测试代码吗？
我们正在使用jruby 1.3.1,rails-2.3.1并且我使用IntelliJ IDEA进行调试,如果我必须切换到eclipse或netbeans,我也没关系.
编辑:实际上,"不,这是不可能的"也是一个有用的答案,如果你知道它是如此.至少我会停止浪费时间
请考虑以下步骤:
0)发布开源模拟程序和模拟插件,它通过某些接口(I)进行通信,交换复杂的数据结构,共享内存并相互调用.对其应用所有许可许可.
1)Release Plugin,用于以接口(I)定义的方式处理任何程序.这个插件使用第三方GPL覆盖的代码,GPL本身也是如此.它最初是使用Mock Program开发和测试的.它作为任何GPL程序分发,并提供源代码.
2)发布闭源专有程序,用于以接口(I)定义的方式与任何插件通信.它最初是使用Mock插件开发,测试和发布的.
3.1)向程序添加安装脚本,下载GPL插件并将其附加到已安装的程序.
3.2)而不是安装脚本添加说明如何手动下载和附加GPL插件.
因此,最终用户获得专有程序,该程序受益于插件中的GPL覆盖代码.
问题:
0)如果它是合法的,那么通过开发人员的相当小的努力,在任何专有程序中获得任何GPL涵盖代码的利益是不是合法的方式？
1)如果它不合法,那么GPLv*的哪一部分或任何东西阻止谁做哪一步？
2)3.1和3.2之间是否有任何法律差异？
3)如果Mock Program and Plugin,专有程序和GPL插件是由单个人或不同的人开发的,是否存在法律上的差异; 有意或无意？
4)您的意见是什么 - 它是否足够道德？
5)这种策略是否有现有样本？
6)是否有任何更容易的合法方法来实现相同的结果 - 发布可能并且很可能从GPL代码中受益的专有程序？
更新:
从字面上看,这意味着为封闭源程序编写插件并在GPL下发布它会导致组合成为插件的扩展,因此属于GPL,涵盖整个封闭源程序太
但是这种组合不是分布式的,而是在最终用户机器上进行组合.就像我自己对Linux的修改一样,在我发货之前我不需要开源.在这种情况下,最终用户设法在不访问程序源的情况下进行修改 - 对他有利,但到目前为止我看不到任何违法行为.
为了使用GPL覆盖的插件,主程序必须在GPL下发布
我看到了GPL常见问题的那一部分.但是插件可以独立开发并随MockProram一起提供.它发生了,以便最终用户可以从MockProgram获取插件并将其放入专有程序.直到最后一步GPL和封闭源被分开.该步骤由最终用户完成,他没有义务,因为他不分发组合产品.
更新2
这个
如果法院认定一个是专门设计要求另一个,那么你可能会遇到麻烦.Mock Program和Mock Plugin的性质也可能发挥作用,关于它们是"真正的"程序还是傀儡.咨询律师.
看起来像问题3的答案.谢谢.
我正在开发非交互式cpu绑定应用程序,它只进行计算,几乎没有IO.目前它的工作时间太长,而我正在努力改进算法,我也认为它可以为改变语言或平台带来任何好处.目前,在使用英特尔C++编译器编译的Windows上,它是C++(没有OOP,因此它几乎是C).可以切换到ASM帮助和多少？可以切换到Linux和GCC帮助吗？
我正在努力学习如何使用升降机.我可以通过从Starting with Lift运行maven命令(之前我没有maven经验)来创建项目框架.它成功下载了所需的依赖项,一切正常,但它没有下载源 - 我想看看电梯是如何从内部工作的.
看起来它从这里下载依赖项,并且有编译的.jar文件以及源代码 - 有lift-mapper-1.0.jar和lift-mapper-1.0-sources.jar,但只下载了lift-mapper-1.0.jar到我的本地存储库.我可以手动下载源代码,但那里只有几个文件夹.那么,有没有办法告诉Maven下载与源的依赖关系？
您的应用程序的哪些部分未编码？我认为最明显的例子之一是数据库凭证 - 将它们硬编码被认为是不好的.在大多数情况下,很容易决定是否需要外部化或编码.对我来说规则很简单.如果出现以下情况,应将申请的某些部分外部化:
你有什么需要补充的吗？
这与关于spring cfg的这个问题有点相关.Spring配置对我来说似乎不太明显,因为在我的实践中,除了开发人员之外,任何人都不会修改它.外化的道路可以带你走远,整个项目被"配置",而不是编码 - 所以在哪里停下来？
所以请在这里发布一些你的经验的例子,当你从配置的东西中受益,而不是编码 - 比如春天的依赖注入配置等等.如果你使用spring - 如果没有重新编译,配置有多少经常改变？