public class PicoUserManager extends LogSwitcher
{
　　..... //用户管理功能
}
public class PicoXXXX1Manager extends LogSwitcher
{

　　..... //业务功能
}
public class PicoXXXX2Manager extends LogSwitcher
{

　　..... //业务功能
}
只是Template模式而已，因为每个类都必须继承自LogSwitcher
而且logging.enableLogging(new SimpleLog("pico"));//激活log
如何能产生具体的日志信息，我的理解是每个类产生的日志信息
完全可能是不一样的，不用在每个类里面写代码，而直接使用Log类
如何能达到日志记录的目的，至少Log类应该在适当的时候有机会
调用写日志方法，是用什么通知机制呢

说人剽窃，是要证据的。比如行文，或者例子。说思想相似，只能说是英雄所见或者殊途同归。

1个是PICO的注册方式和你的NEW方式，相比前者要麻烦很多，后者简便。

2是XML指定PICO规定了不能是工厂，限制了你的代码灵活。

对于第1个，我也不懂，说一下我的看法。
我第一感觉是PICO处理的很清晰，很条理，你的NEW确实方便，但我认为不规范。框架要面向客户，如果自己可能真的就NEW了。当然还有你所发现的动态优势。

第2个我觉得你是走了极端，自己给自己找麻烦，嘿嘿，不介意我这么说吧，PICO不完美，但你说的这个好象用到的人不多，所以不是很重要的因素吧。

说的可能都是谬论，望各位专家指教。

Service Locator 并非（Dependency Injection）的一种:
http://www.martinfowler.com/articles/injection.html#InversionOfControl

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

三种注入形式：
1. Constructor Injection 构造注入，就是把接口从构造方法中传进去。
2. Setter Injection Setter注入，就是把接口从setXxxx方法传给需要的对象
3. Interface Injection 接口注入，与其说是“接口注入”还不如说是用某一个特定的方法注入（就是名称不是以set开头）。

Service Locator vs Dependency Injection

1. 它们都是消除程序与组件间依赖的两种不同的方式。
2. Service Locator要求程序通过某一种程序入口找出特定的组件界面（接口）然后进行访问；而“依赖注入”这是由容器根据某一种配置文件，将对象需要的组件接口传递给该对象。

所以你的文章中关于Service Locator是依赖注入的一种方式，真的不敢苟同。