IT的人经常搞些概念唬自己

无视

原帖由 交易人生 于 2011-10-26 10:55 发表
没看不起di，不过不想把简单问题复杂说法。

咱们都是纯技术说着玩，大家都没当真，就是纯分享，注重说话内容，忽略用词和语气.

我个人没有冒犯的意思，你大人大量，别介意就好。

key

DI is much * 1000 more than that.

原帖由 交易人生 于 2011-10-25 16:53 发表
前两天碰到一个前同事，讲面试考他dependency injection，他没用过，不行；我说你肯定用过，他说他后来google了，一堆framework， EnLib的unity还什么.net spring framework等等。

明明是instance variable，非搞个怪名字。

感叹一下。

交易人生

原帖由 无视 于 2011-10-26 13:17 发表


咱们都是纯技术说着玩，大家都没当真，就是纯分享，注重说话内容，忽略用词和语气.

我个人没有冒犯的意思，你大人大量，别介意就好。

没觉得你冒犯谁，的确技术归技术，觉得你说的挺好的。

交易人生

原帖由 key 于 2011-10-26 13:38 发表
DI is much * 1000 more than that.

DI的模式的确简单，你要说more than that，可能是指的应用和衍生品。

flyspirit

原帖由 porcorosso 于 2011-10-26 13:08 发表


概念不难理解嘛。。。就名称牛了些。。。
呵呵被你们楼上的哄得傻呼傻呼。。。

名称也还好了， 也挺贴切的， Dependency 说明有关系， Injection表示两个部分本来是分离的， 可能在不同模块里面， 甚至可能是两个公司开发的， 在运行的时候， 把一个插入到另一个里面使用。

porcorosso

今天一同事show给我看他的php code，用了非常多的DI，我心里想：有必要吗？还是纯粹炫耀？

atransformer

原帖由 porcorosso 于 2011-10-27 23:00 发表
今天一同事show给我看他的php code，用了非常多的DI，我心里想：有必要吗？还是纯粹炫耀？

这种人很多。 其实很多简单程序，用stream line 比 oo 速度快，效率高。 但总有人非要显出程序员的水平。

我们原来有个程序，运行巨慢。每次一点按钮，要等一个小时。我看看代码，傻了。为了封装 数据库 utility class. 每一个数据分析返回都建立一个database connection. 代码看着挺好，其实就是扯淡。 我把它改了，用sqlbulkcopy, 程序运行时间缩短到2分钟。

porcorosso

原帖由 atransformer 于 2011-10-27 23:14 发表


这种人很多。 其实很多简单程序，用stream line 比 oo 速度快，效率高。 但总有人非要显出程序员的水平。

我们原来有个程序，运行巨慢。每次一点按钮，要等一个小时。我看看代码，傻了。为了封装 数据库 utility class. 每 ...

fyang1024

这个概念有可能最先出现在JAVA里，但我没考证过
class A {
  B b;
}
用面向对象的语言，可以说A类依赖于B类
在UML里，有一种关系叫Dependency，是一种有方向的关系，就是这种关系
当实例化一个A类的对象时，通常是要实例化一个B类的对象或实例（instance)，否则b就是NULL
在Dependency Injection这个概念以前，创建B实例的工作通常是在代码中完成的，
比如
A a = new A();
a.setB(new B());
Dependency Injection的概念是由Framework或容器来帮你实例化这些对象。
上面的代码变成
InstanceFactory.config(“instances.xml”);
A a = InstanceFactory.getInstance(“a”);
其中instances.xml的内容如下
<instance id="a" class="A">
   <property name = "b" ref = "b"/>
</instance>
<instance id="b" class="B"/>

这么麻烦之后有一个好处就是
实例之间的依赖关系完全由instances.xml定义了，而不是散落在代码中
你可以有appInstances.xml和unitTestInstances.xml
这样容易Mock实例，方便单元测试

在JAVA中有些对象比如HttpRequestServlet只有在服务器启动后才能获得，
这样单元测试就做不了了

zhanglianwei

依赖注入不过是给这个概念找了一个名字呢。实际上就是通过反射机制实现的。

概念这玩意就是你得用它的名字，要不然你怎么让别人理解你说的东西。

比如Singleton吧。多简单的一个东西，为啥叫Singleton模式？因为必须有个名字，要不然你得花10分钟来让别人明白你在说什么。有了名词以后，一秒钟就解决了。

zhanglianwei

滥用DI很正常，就连设计模式的作者都说过自己遇到小问题也喜欢用设计模式去套，后来发现自己也在滥用这些概念。有些程序员就喜欢在自己的代码里面套各种模式而已，没办法，你也不能说他写得不对。性能之类么，是没有优化好，和DI本身没关系。

key

原帖由 zhanglianwei 于 2011-10-28 17:56 发表
就连设计模式的作者都说过自己遇到小问题也喜欢用设计模式去套，后来发现自己也在滥用这些概念

求出处，谢谢。

梦呓人

感谢偶像的贴，我刚知道原来constructor里带parameter就叫DI.....


偶像，再请问一下：MVVM里面怎么体现DI呢？

locatelli

这种考题最没意思了

交易人生

原帖由 BJ-KING 于 2011-10-31 17:03 发表
感谢偶像的贴，我刚知道原来constructor里带parameter就叫DI.....


偶像，再请问一下：MVVM里面怎么体现DI呢？

你才是我偶像；

mvvm，比如在viewmodel里，你可以这样：
public class MyDataItem
{
    ...
}

public interface IMyData
{
    ObservableCollection <MyDataItem> GetMyData();
}

public class MyTestData: IMyData
{...
}

public class MyWorkData: IMyData
{...
}

public class MyViewModel : INotifyPropertyChanged
{
    private IMyData _myDataSource;

    private ObjservableCollection<MyDataItem> _myData;
    public ObjservableCollection<MyDataItem> MyData
    {
      ...
    }
    [Inject]
    MyViewModel(IMyData source)
    {
            _myDataSource = source;
            _myData = source.GetMydata();
    }
}

这样做的目的就是用MyTestData做unit test，因为真正的数据来源可以是数据库，web/wcf service或者其他什么的，不可能做unit test。

简单应用而已。

dcc82

"Dependency Injection is where components are given their dependencies through their constructors, methods, or directly into fields."
自己天天都在DI，有时候并没有察觉，但是比较喜欢这样的design pattern，感觉对维护代码方面有很大好处---极大的增加灵活性，降低object和object的相互依存关系，我个人感觉还有一个很明显的好处是：方便unit testing，因为可以随便mock object，注入到class中去

zhanglianwei

原帖由 key 于 2011-10-29 14:15 发表

求出处，谢谢。

忘了在哪里看到的了。

不过反对滥用设计模式很普遍了，我随便Google都Google出来一段：

“　　1995年，GoF（以Erich Gamma为首的“四人帮”）所著的《设计模式——可复用面向对象软件的基础》（Design Patterns--Elements of Reusable Object Oriented Software）一书出版了。这本书在面向对象编程/设计领域具有划时代的意义。不夸张地说，这本书就是面向对象程序员的红宝书，对于面向对象程序员来说，应该人手一册。没有读过这本书，对于面向对象的理解还停留在很低的层次；读过了这本书，才算真正理解了一些面向对象的精华。很自然，这本书一时间洛阳纸贵，后来还陆续出现了很多以不同语言的实例来解释GoF设计模式的著作，例如《Java设计模式》、《C#设计模式》等等。
　　
　　但是物极必反，任何事情都不能走极端，否则就会造成不良后果。在项目开发不适当的时机使用设计模式，或者在不适当的场合使用设计模式，都会给项目开发带来很多不必要的复杂性，从而增加大量的沟通成本，甚至会严重影响开发效率。以前听说过一个笑话：一个程序员发邮件给Erich Gamma，说在他们最近的一个项目中，他尽力使用了23种GoF设计模式中的21种，还有两种怎么也找不到适用的场合。他感到很苦恼，希望能够得到 Erich的帮助。
　　
　　这个笑话说的当然是一种最极端的情况。尽管如此，大量的实践证明，不当使用（不适当的时机、不适当的场合）设计模式会给项目开发带来很大的麻烦。自己挖坑把自己埋进去，这是很多一知半解的面向对象架构师经常做的事情。言必称架构、言必称模式正是中毒很深的迹象。
　　
　　1998 年出版的《反模式——危机中软件、架构和项目的重构》（AntiPatterns——Refactoring Software, Architectures, and Projects in Crisis）这本书对于滥用设计模式的趋势来说可谓是一剂很及时的解毒良药。反模式其实也是一种模式（正如设计模式是一种模式一样），不过它主要考察的是这种模式所带来的不良后果。这本书系统地总结了很多种类的反模式，以及如何识别出这些反模式并且加以避免。这些反模式涵盖了软件开发、软件架构和项目管理等方面。虽然这本书并不是专门针对设计模式展开讨论的，但是不当使用设计模式很多时候都会导致出现反模式。平衡感是优秀的面向对象架构师应该拥有的素质，《反模式》这本书可以使架构师拥有更好的平衡感。
　　
　　1999年出版的Martin Fowler所著的《重构——改善既有代码的设计》（Refactoring: Improving the Design of Existing Code）这本书对于如何改善现有代码的设计提出了非常具体的解决办法。Martin Fowler在这本书中认为，不应该在最初编码时就使用设计模式，而应该将设计模式作为重构的目标。实际上，设计模式正是Erich等人在对一些开发框架进行重构的过程中总结出来的。后来2004年出版的Joshua Kerievsky所著的《重构与模式》（Refactoring to Patterns）在《重构》的基础上更加详细地探讨了重构与设计模式之间的关系，以及如何在重构的过程中逐渐引入设计模式。
　　
　　2000年出版的Kent Beck所著的《解析极限编程——拥抱变化》（Extreme Programming explained--Embrace change）响亮地提出了简单设计、不为明天而设计的口号，进一步为滥用设计模式的趋势消了毒。 ”

无视

anti-pattern实在pattern滥用的情况下提出的，但绝大多数project不是滥用，而是用的不够，没有pattern的意识。

在当前一些framework的帮助下，很多pattern都不再提倡，不过那23种模式对于oo的训练还是很有帮助的。

pattern不是全部，不懂不算啥，很多软件开发过程中的best practise/procedure要比它重要很多，但最为一个不断成长的程序员，不经过pattern方面的历练恐怕说不过去。

huaxianz

原帖由 zhanglianwei 于 2011-11-1 12:27 发表


忘了在哪里看到的了。

不过反对滥用设计模式很普遍了，我随便Google都Google出来一段：

“　　1995年，GoF（以Erich Gamma为首的“四人帮”）所著的《设计模式——可复用面向对象软件的基础》（Design Patterns--Elements of ...

+1
我也曾经记不起出处的见过。中心思想就是凡事要有个度。

baobeima

Mark

lostbf

学习了

雄鹰展翅

it民工不少啊