但是，显然，这些观点在同事那里是站不住脚的：
1。不管你需不需要额外的功能，你直接调用这个api好了。又不需要额外写代码。
2。项目中大家都使用PropFactory来读取配置。如果大家你写一个ajoo way of reading property，他写一个bjoo way of reading property，那不是乱套了？这样做破坏了一致性，增大了团队协作的难度。
3。依赖依赖了，有什么关系？这个几乎是公司内部的事实标准了。大家都这么用，还是头回听说有人对这个依赖有问题的。
4。如果不用PropFactory，谁能保证你的代码在任何情况都工作？这个项目的build process， deploy process都很复杂，难以预测你这个代码在nightly build甚至在生产环境中也会工作。

对此，当然我是不同意的。我认为，ClassLoader.loadResourceAsStream几乎是工业界的标准，相比于一个公司自制的标准，我还是更倾向于相信被无数人证明工作的业界标准。
而且，试图让PropFactory包打一切也是不现实的。起码，你用的commons logging， log4j等等开源库，都不可能依赖于你自己写的PropFactory，它们只能使用ClassLoader。所以这个一致性从一开始不存在。
后，我认为“一致性”在项目中被错误解读了。打个比方，项目中大家一致都是用jsp，但是我不认为当只需要一个servlet或者甚至一个静态的html的时候，我们也必须要为了一致性通过jsp来绕一圈生成这个servlet或者html.

经过争论，我还是做了妥协，只要我可以注射Map，你非要用in house framework而不是业界标准来读文件，也罢。

于是我的方案变成：

    new ImplFactoryProxy(PropFactory.getInstance().getProperty("defaults.properties").toProperties()) 

这个toProperties()是PropFactory框架提供的一个函数，可以把我们inhouse的IProperties转换成java.util.Properties。

终面向用户的接口（在没有采用ioc容器的情况下，只好还是允许客户代码主动取得ServiceFactory实例。）是：

    public class ServiceFactoryUtil { 
      public static ServiceFactory getServiceFactory(); 
    } 

这个类负责调用PropFactory.getInstance()，并且提供singleton服务以避免重复读取properties文件。

这几乎是我可以接受的底线了。

但是，同事仍然不满意。他喜欢的是我不去注射Map，而是在ImplFactoryProxy内部直接调用PropFactory。这个在我来说是不可考虑的。

当然，他也退了一步，同意我的注射方式。但是认为我不应该注射java.util.Map，而应该注射IProperties。

同事的理由：
1。这样可以避免一个toProperties()调用。别人读代码的时候，可以不会纳闷“为什么这里要这么做？”。
2。java.util.Map这个接口太肥大。我需要的其实是一个get()，多加上keySet()和containsKey()，用一个java.util.Map不合适。

而我反对使用IProperties，理由是：
1。IProperties不是标准接口，我宁愿以来jdk标准接口。毕竟熟悉java.util.Map的比IProperties多多了吧？即使IProperties是在公司内部被“一致”使用。
2。没人会纳闷为什么要调用toProperties()。如果这都要纳闷，那么整个遗留系统的那数万行的代码没法读了。
3。如果说java.util.Map不是小接口，IProperties也不是。它也有一些我不需要的函数。
4。整个公司从来没有人用注射的方式来使用IProperties。大家都是PropFactory.getInstance()这样从头调用的。难保注射IProperties不会出什么问题。（比如，同步问题？后来，虽然同步问题没法验证，我确实发现了IProperties不支持Serializable，致使我的ServiceFactory也不能Serializable。这样类似的问题，如果真是采用了IProperties，还不知道会不会陆续向外蹦呢）。

终，因为我是这个功能的开发者，还是以我的意见为主了。但是我并没有说服同事。在争论过程中，让我深感郁闷的是，我的“减小依赖”的论点根本不为同事接受，似乎在他们看来“依赖”并不能作为一个理由。而我也发现要把减小依赖和他们接受的DRY，unit test等原则直观地联系起来不太容易。

那么，你是怎么看这个问题的呢？