- 浏览: 75344 次
- 性别:
- 来自: 杭州
最近访客 更多访客>>
文章分类
最新评论
-
ieniac:
516456267 写道离线版非常好使!
查看当前本机浏览器FlashPlayer版本 -
516456267:
离线版非常好使!
查看当前本机浏览器FlashPlayer版本
Alec Sharp, in the recent book Smalltalk by Example [SHARP], points up a very valuable lesson in few words:
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp
That is, you should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do.
The problem is that, as the caller, you should not be making decisions based on the state of the called object that result in you then changing the state of the object. The logic you are implementing is probably the called object’s responsibility, not yours. For you to make decisions outside the object violates its encapsulation.
Sure, you may say, that’s obvious. I’d never write code like that. Still, it’s very easy to get lulled into examining some referenced object and then calling different methods based on the results. But that may not be the best way to go about doing it. Tell the object what you want. Let it figure out how to do it. Think declaratively instead of procedurally!
It is easier to stay out of this trap if you start by designing classes based on their responsibilities, you can then progress naturally to specifying commands that the class may execute, as opposed to queries that inform you as to the state of the object.
Just the Data
The main purpose of this exercise is to ensure a correct division of responsibility that places the right functionality in the right class without causing excess coupling to other classes.
The biggest danger here is that by asking for data from an object, you are only getting data. You’re not getting an object—not in the large sense. Even if the thing you received from a query is an object structurally (e.g., a String
) it is no longer an object semantically. It no longer has any association with its owner object. Just because you got a string whose contents was “RED”, you can’t ask the string what that means. Is it the owners last name? The color of the car? The current condition of the tachometer? An object knows these things, data does not.
The fundamental principle of Object Oriented programming is the unification of methods and data. Splitting this up inappropriately gets you right back to procedural programming.
Invariants aren’t enough
Every class has invariants—things that must always be true. Some languages (such as Eiffel) provide direct support for specifying and checking invariants. Most languages do not, but that only means that the invariants are not stated—they still exist. For instance, an iterator has the invariant that (using Java as an example):
hasMoreElements() == true
// implies that:
nextElement()
// will return a value
In other words, if hasMoreElements()
is true, then attempting to get the next element must succeed, or something is seriously broken. If you are running multi-threaded code without the proper synchronization (locking), it may well be that the above invariant doesn’t hold: some other thread grabbed the last element before you did.
The invariant doesn’t hold; so something is wrong—you have a bug.
According to Design by Contract, as long as your methods (queries and commands ) can be freely intermixed, and there is no way to violate the class invariant by doing so, then you are ok. But while you are maintaining the class invariant, you may have also dramatically increased the coupling between the caller and the callee depending on how much state you have exposed.
For instance, suppose you have a container object C
. You could expose iterators for the held objects in this container, as many of the JDK core routines do, or you could provide a method that would run some function over all members in the collections for you. In Java you might declare this as something like:
public interface Applyable {
public void each(Object anObject);
}
...
public class SomeClass {
void apply(Applyable);
}
// Called as:
SomeClass foo;
...
foo.apply( new Applyable() {
public void each(Object anObject) {
// do what you want to anObject
}
});
(Forgive the neologic barbarism of “Apply-able”; we’ve found it handy to name interfaces as “-able”, but English isn’t as cooperative as one would like).
This is easier to code in languages with function pointers, and even easier in Perl or Smalltalk where such concepts are built in, but you should get the idea: “run this function over all contained items, I don’t care how.”
You can achieve the same results both ways, either via an apply
sort of method or via iterators. The choice really comes down to how much coupling you are willing to have: To minimize coupling, expose the minimum amount of state necessary. As shown here, apply
exposes less state than exposing an iterator does.
Law of Demeter
So we’ve decided to expose as little state as we need to in order to accomplish our goals. Great! Now within our class can we just starting sending commands and queries to any other object in the system will-nilly? Well, you could, but that would be a bad idea, according to the Law of Demeter. The Law of Demeter tries to restrict class interaction in order to minimize coupling among classes. (For a good discussion on this topic, see [APPLETON]).
What that means is that the more objects you talk to, the more you run the risk of getting broken when one of them changes. So not only do you want to say as little as possible, you don’t want to talk to more objects than you need to either. In fact, according to the Law of Demeter for Methods, any method of an object should only call methods belonging to:
- itself.
- any parameters that were passed in to the method.
- any objects it created.
- any composite objects.
Specifically missing from this list is methods belonging to objects that were returned from some other call. For example (we’ll use Java syntax here):
SortedList thingy = someObject.getEmployeeList();
thingy.addElementWithKey(foo.getKey(), foo);
This is what we are trying to prevent. (We also have an example of Asking instead of Telling in foo.getKey()
). Direct access of a child like this extends coupling from the caller farther than it needs to be. The caller is depending on these facts:
- someObject holds employees in a SortedList.
- SortedList’s add method is
addElementWithKey()
- foo’s method to query its key is
getKey()
Instead, this should be:
someObject.addToThingy(foo);
Now the caller is only depending on the fact that it can add a foo
to thingy
, which sounds high level enough to have been a responsibility, not too dependent on implementation.
The disadvantage, of course, is that you end up writing many small wrapper methods that do very little but delegate container traversal and such. The cost tradeoff is between that inefficiency and higher class coupling.
The higher the degree of coupling between classes, the higher the odds that any change you make will break something somewhere else. This tends to create fragile, brittle code.
Depending on your application, the development and maintenance costs of high class coupling may easily swamp run-time inefficiencies in most cases.
Command/Query Separation
Now back to to the ask vs. tell thing. To ask is a query, to tell is a command. I subscribe to the notion of maintaining these as separate methods. Why bother?
- It helps to maintain the “Tell, Don’t Ask” principle if you think in terms of commands that perform a very specific, well defined action.
- It helps you to think about class invariants if you class is primarily command based. (If you are just tossing data out, you probably aren’t thinking much in the way of invariants).
-
If you can assume that evaluation of a query is free of any side effects, then you can:
- use queries from within a debugger without affecting the process under test.
- create built-in, automatic regression tests.
- evaluate class invariants, pre- and post-conditions.
The last, of course, is why Eiffel requires only side-effect free methods to be called from within an Assertion. But even in C++ or Java, if you want to manually check the state of an object at some point in the code, you can do so with confidence if you know the queries you are calling will not cause anything else to change.
References
[SHARP] Sharp, A. “Smalltalk By Example” McGraw-Hill, 1997.
[APPLETON] Appleton, B. Introducing Demeter and Its Laws
发表评论
-
Sublime Text 2 Custom Layout
2012-10-15 15:21 6571. Edit Sublime Text 2\Data ... -
Linux Tips
2012-10-15 06:43 565-- How to config ip in Linux F ... -
Change FireBug DEFAULT font-family
2011-12-31 16:44 7101. Search *firebug*.xpi in Fire ... -
cygwin for e-texteditor
2011-08-17 11:03 625install cygwin for ete Se ... -
Config Remark
2011-06-19 15:06 8151. version control 2. out o ... -
IE associate Fix
2010-08-11 09:33 616注册动态链接库 for %%i in (c:\windows ... -
qq.foxmail.crack
2009-10-20 17:31 886javascript:var s=/mail.qq.com/; ... -
Editing/Authoring Actionscript3 Classes In IntelliJ IDEA
2009-08-25 17:54 2026I wanted to see whether it was ... -
Flex & RIA
2009-08-22 23:28 736Framework: a. Cairngorm [MVC] ... -
Never, never, never use String in Java (or at least less often :-)
2009-08-22 19:24 986Never, never, never use (unwrap ... -
Extract flash from Excel or Word
2009-06-05 14:34 821打开含有Flash的EXCEL文档, 点击"视图& ... -
Google的九条创新原则
2009-06-04 11:57 706Innovation, not instant perfec ... -
Ten Quotients of Success
2009-05-29 10:50 963成功是每一个人都梦想 ... -
How to Rate a Software Developer
2009-05-29 10:42 933How do you rate a software deve ...
相关推荐
show and tell
Steal This File Sharing Book: What They Won't Tell You About File Sharing 有问题,我的QQ:571669275
Steal This Computer Book 3: What They Won't Tell You About the Internet 有问题,我的QQ:571669275
完整工程案例:图像描述---Show and Tell: A Neural Image Caption Generator,基于Inception V3与LSTM实现图像描述,运行环境(Tensorflow1.0及以上,Python3.6)
Show and Tell_ Lessons learned from the 2015 MSCOCO Image Captioning Challenge
仿照泰豪网站首页,整个首页包括轮播图和动画,http://www.tellhow.cn/,这是网站首页,效果一模一样,练习编写,如果有兴趣可以下载看看,引入了轮播图框架和动画框架
Tellus公司是加拿大最主要的通信公司之一,它向全球客户提供通信产品和服务,将加拿大与整个世界连接起来。Tellus电子商务分部与Sun的工程师一道,创建了一个以Web为中心的专门供服务提供商(SP)应用的解决方案。这是...
Unit Tell me when the pain startedPPT教案.pptx
I have 1TB disk, but the system tell me it was 931GB disk
浙江杭州下城区2019-2020学年第一学期教学质量监测九年级语文试题及答案.pdf
教育精品资料
从用户的Facebook NewsFeed隐藏权力的破坏者游戏。 支持语言:English (United States)
From Show to Tell A Survey on Image Captioning.zip
完整工程案例:图像描述---Show and Tell: A Neural Image Caption Generator,基于Inception V3与LSTM实现图像描述,运行环境(Tensorflow1.0及以上,Python3.6)
广东省博罗县泰美中学七年级英语下册 Module 6 Unit 1 Could you tell me how to get to the National Stadium导学案(无答案)(新版)外研版
05 show attend and tell讲解
Description : Function to tell whether the disk is smaller than SMALL_DSK_BYTES.
Cmaes 带有面向对象的 ask/tell 接口的 CMA-ES 的 MATLAB 实现。
中英对照版 Things I Tell New Testers