＋设为首页 ＋添加到收藏夹
there is a principle of object-oriented design known as the dependency inversion principle (dip). this principle tells us that we should try to avoid depending on things that are concrete. for example, given the choice between holding a reference to a list or its derivative linkedlist, we should choose the base class list.
linkedlist balls = new linkedlist();we should write: 【程序编程相关:关于Map和List的性能测试报告】
in other words, rather than writing: 【推荐阅读:用BeanShell实现公式管理】
the dip says: "depend on abstractions, not on concretions." this is just another way of expressing the old maxim of information hiding. in this case we are hiding the true type of an object from all of its users. 【扩展信息:设计合适的接口】
list balls = new linkedlist();the reason for this should be obvious. we can pass balls around as a list to any function or object that takes a list argument. later, if we decide to change the definition of balls to an arraylist, we need only change one line of code.
but what about the new statement above? it specifically uses the concrete class linkedlist. this clearly violates the dip. indeed, the statement list balls = new linkedlist(); is quixotic. it tilts at windmills by flagrantly exposing the concrete type of balls and then pretending to hide it.
if we only create the balls list in one place, then at least we can claim to be hiding its type from the rest of the application, even if we do expose it here in one place. however, if we have a function of the form:
... 下一页