基础知识: 需求!

charon， 确实，准确的说法应该是“可观测语义”。
其实最精确的说法，也许应该是：“相对观测模块的可观测语义”。

比如说， log， 这个动作是副作用，有和没有是不同的。

但是如果用这个相对的可观测语义，只要外界调用者对是否存在log不关心，那么这其实也算是一个可观测语义的透明。

对于你提出的这个“增加了成员变量必然也改动了接口”，我想一个比较合适的用例可能是cache。在开始，我可能为了简单，直接实现，所以不需要任何状态。
而后来如果我想做一个cache以提高效率，那么就需要一个局部状态。
比如：

interface Calc{
  int calc(int i);;
}
class CalcImpl implements Calc{
  public int calc(int i);{
    //do some very complex calculation
    return r;
  }
  ...
  public static Calc instance();{return singleton;}
}

这是第一版。

在第二版，我注意到计算非常耗时，也许可以通过cache来提高效率。

于是，我可以加一个HashMap来缓存一些计算结果。这时我可能就会想给对象加入局部状态。于是，singleton就不合适了。


更合适的例子，我还要再想想。

谨慎地说，我也不是很清楚你这个描述的具体含义。
不过，我所说的“透明”的意思：
1。内部的代码更改的驱动是优化或者重构。（优化之如singleton， 重构如我举的张三李四写Hello的例子）
2。重构或者优化驱动的内部代码变动不能影响外部的接口。
3。外部的需求变化当然可能也可能不影响内部实现。这些不是我的静态厂所负责的。所以我不能说：“对象根本不被环境所影响改变”。任何的东西最终的驱动都是需求。需求变化了只扩展不更改当然好。但是如果被迫更改（我相信ocp只是可以无限逼近的美好理想），也只能更改。这时候就要看怎样更改代价最低。
无论如何，外部需求变化不在静态厂所解决的问题范围之内。

终于提出一个明确的概念了：

potian
在我看来一个事物发生变化肯定是由于外部的环境发生了变化，从而引起事物内部发生的重整。而我进一步认为new是最近似透明的做法，因为这主要是一种语言自身的行为，而非程序员的动作。只是在new的时候有逻辑化很复杂的情况下才有必要去工厂化解决。我想这也是ajoo的本意。而我想分歧可能在于究竟什么时候就可以认为是复杂的逻辑了。而ajoo似乎更加强调接口的重要，也就是IoC和DIP的关心的问题。这个问题如果真的会造成某种对设计的影响，应该会改变现在众多实现的基础环境。
我还是我最初的观点，ajoo的做法道理上是行得通的，但是使用价值还需要他或者别人来证明。
同时请注意ajoo的这句话

因为“透明”这个概念被大家关注也是今天的事。

不是，这里不是singleton的好处。

我举这个例子是说：

开始， 我因为实现没有状态，使用了singleton。
后来，我发现我需要对象状态，所以废除了singleton。

无论如何，这个instance()接口不变。

ajoo

好的设计模式完全可以做到你所说的透明。
那何必需要静态工厂呢？我实在想不出来静态工厂在你所说的透明的概念的前提下 的必要性

oz, 我不认为变化完全是外界需求变化驱动的。
我认为重构是可以在需求没有变化的时候的一种自我结构调整。
虽然重构的最终目的是应对将来可能出现的需求变化，但是重构本身不一定在需求变化时才发生。

举个例子？
再说，静态工厂不可以算是一个模式？

ajoo 我提个建议：
针对你所说的透明概念。
你能不能完整举一个比较有意义的例子来阐明你所说得观点。
然后，我们针对你的例子做进一步的讨论！
源代码是最好的文档

不然讨论容易按照个人的思维发散！

ajoo
注意到我对于变化的时候用了“我”这个主语了吗？这只是说明我个人的对于重构的态度，也就是如果不修改我就不会动运行着的代码,当然这只是我的选择。我之所以这样选择，主要是因为外部环境的变化注定会发生，并且往往以我不能掌握的方式发生。也就是我认为你往往没有时间去做内部的驱动的重构，而只能在由于外部驱动的重构的同时考虑内部的结构问题。
不过我倒是要提醒大家重构并不是不会改变接口和行为的，比如f（a，b，c，d)重构为f（A）。（注明：当初有段时间我曾经对此持否定观点，现在改变了）