标签Quml 状态图 cd it 分类QY件设?
说明Q?br /> 构g事物是名词，是模型的静态部分?br /> 行ؓ事物是动态部分，表示行ؓ?br /> ? l事物是l织部分?br /> 注释事物是解释部分?/font>
在UMLpȝ开发中有三个主要的模型Q?br />
下面具体说明Q?/font>
1.cdQ描qCl对象、接口、协作等事物之间的关pR如下图(摘自|络)Q?/font>
3.用例?/strong>Q描qCl用例、参与者以及它们之间的关系Q其展示的是该系l在它的外面环境中所提供 的外部可见服务。如下图(摘自|络)Q?/font>
4.交互?/strong>Q包?strong>序列?/strong>Q?font color="#ff0000">序?/font>Q和协作?/strong>Q两者对应，序图是消息旉序Q有对象生命 U和控制焦点。协作图是强调接收和发送消息的对象的结构组l，有\径和序受如下图(摘自|络)Q?/font>
5.状态图Q展CZ一个状态机Q由状态、{换、事件和zdl成。强调事件行为的序。如下图(? 自网l?Q?/font>
]]>
Transcribed by Duke Hillard
Transmitted by Anupam Trivedi, Sajitha Tampi, and Meghshyam Jagannath
Re-html-ized and edited by Kragen Sittler
Last modified 1996-04-10 or earlier
Table of Contents
- The Silent Void
- The Ancient Masters
- Design
- Coding
- Maintenance
- Management
- Corporate Wisdom
- Hardware and Software
- Epilogue
Book 1 - The Silent Void
Thus spake the master programmer:
``When you have learned to snatch the error code from the trap frame, it will be time for you to leave.''
1.1
Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming.
If the Tao is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is great, then the application is great. The user is pleased and there exists harmony in the world.
The Tao of Programming flows far away and returns on the wind of morning.
1.2
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
1.3
In the beginning was the Tao. The Tao gave birth to Space and Time. Therefore Space and Time are Yin and Yang of programming.
Programmers that do not comprehend the Tao are always running out of time and space for their programs. Programmers that comprehend the Tao always have enough time and space to accomplish their goals.
How could it be otherwise?
1.4
The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at it.
If it were not for laughter, there would be no Tao.
The highest sounds are hardest to hear.
Going forward is a way to retreat.
Great talent shows itself late in life.
Even a perfect program still has bugs.
Book 2 - The Ancient Masters
Thus spake the master programmer:
``After three days without programming, life becomes meaningless.''
2.1
The programmers of old were mysterious and profound. We cannot fathom their thoughts, so all we do is describe their appearance.
Aware, like a fox crossing the water. Alert, like a general on the battlefield. Kind, like a hostess greeting her guests. Simple, like uncarved blocks of wood. Opaque, like black pools in darkened caves.
Who can tell the secrets of their hearts and minds?
The answer exists only in Tao.
2.2
Grand Master Turing once dreamed that he was a machine. When he awoke he exclaimed:
``I don't know whether I am Turing dreaming that I am a machine, or a machine dreaming that I am Turing!''
2.3
A programmer from a very large computer company went to a software conference and then returned to report to his manager, saying: ``What sort of programmers work for other companies? They behaved badly and were unconcerned with appearances. Their hair was long and unkempt and their clothes were wrinkled and old. They crashed our hospitality suite and they made rude noises during my presentation.''
The manager said: ``I should have never sent you to the conference. Those programmers live beyond the physical world. They consider life absurd, an accidental coincidence. They come and go without knowing limitations. Without a care, they live only for their programs. Why should they bother with social conventions?
``They are alive within the Tao.''
2.4
A novice asked the Master: ``Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?''
The Master replies: ``That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.''
Book 3 - Design
Thus spake the master programmer:
``When the program is being tested, it is too late to make design changes.''
3.1
There once was a man who went to a computer trade show. Each day as he entered, the man told the guard at the door:
``I am a great thief, renowned for my feats of shoplifting. Be forewarned, for this trade show shall not escape unplundered.''
This speech disturbed the guard greatly, because there were millions of dollars of computer equipment inside, so he watched the man carefully. But the man merely wandered from booth to booth, humming quietly to himself.
When the man left, the guard took him aside and searched his clothes, but nothing was to be found.
On the next day of the trade show, the man returned and chided the guard saying: ``I escaped with a vast booty yesterday, but today will be even better.'' So the guard watched him ever more closely, but to no avail.
On the final day of the trade show, the guard could restrain his curiosity no longer. ``Sir Thief,'' he said, ``I am so perplexed, I cannot live in peace. Please enlighten me. What is it that you are stealing?''
The man smiled. ``I am stealing ideas,'' he said.
3.2
There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.''
3.3
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?''
``An operating system,'' replied the programmer.
The warlord uttered an exclamation of disbelief. ``Surely an accounting package is trivial next to the complexity of an operating system,'' he said.
``Not so,'' said the programmer, ``when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design.''
The warlord of Wu nodded and smiled. ``That is all good and well, but which is easier to debug?''
The programmer made no reply.
3.4
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''
``It will take one year,'' said the master promptly.
``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''
The master programmer frowned. ``In that case, it will take two years.''
``And what if I assign a hundred programmers to it?''
The master programmer shrugged. ``Then the design will never be completed,'' he said.
Book 4 - Coding
Thus spake the master programmer:
``A well-written program is its own heaven; a poorly-written program is its own hell.''
4.1
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.
4.2
A novice asked the master: ``I have a program that sometime runs and sometimes aborts. I have followed the rules of programming, yet I am totally baffled. What is the reason for this?''
The master replied: ``You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.
``The rules of programming are transitory; only Tao is eternal. Therefore you must contemplate Tao before you receive enlightenment.''
``But how will I know when I have received enlightenment?'' asked the novice.
``Your program will then run correctly,'' replied the master.
4.3
A master was explaining the nature of Tao of to one of his novices. ``The Tao is embodied in all software - regardless of how insignificant,'' said the master.
``Is the Tao in a hand-held calculator?'' asked the novice.
``It is,'' came the reply.
``Is the Tao in a video game?'' continued the novice.
``It is even in a video game,'' said the master.
``And is the Tao in the DOS for a personal computer?''
The master coughed and shifted his position slightly. ``The lesson is over for today,'' he said.
4.4
Prince Wang's programmer was coding software. His fingers danced upon the keyboard. The program compiled without an error message, and the program ran like a gentle wind.
``Excellent!'' the Prince exclaimed, ``Your technique is faultless!''
``Technique?'' said the programmer turning from his terminal, ``What I follow is Tao - beyond all techniques! When I first began to program I would see before me the whole problem in one mass. After three years I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off.''
Prince Wang said, ``Would that all of my programmers were as wise!''
Book 5 - Maintenance
Thus spake the master programmer:
``Though a program be but three lines long, someday it will have to be maintained.''
5.1
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries.
5.2
A manager asked a programmer how long it would take him to finish the program on which he was working. ``It will be finished tomorrow,'' the programmer promptly replied.
``I think you are being unrealistic,'' said the manager, ``Truthfully, how long will it take?''
The programmer thought for a moment. ``I have some features that I wish to add. This will take at least two weeks,'' he finally said.
``Even that is too much to expect,'' insisted the manager, ``I will be satisfied if you simply tell me when the program is complete.''
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.
5.3
A novice programmer was once assigned to code a simple financial package.
The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
When the master asked about this, the novice became indignant. ``Don't be so impatient,'' he said, ``I'll put in the financial stuff eventually.''
5.4
Does a good farmer neglect a crop he has planted?
Does a good teacher overlook even the most humble student?
Does a good father allow a single child to starve?
Does a good programmer refuse to maintain his code?
Book 6 - Management
Thus spake the master programmer:
``Let the programmers be many and the managers few - then all will be productive.''
6.1
When managers hold endless meetings, the programmers write games. When accountants talk of quarterly profits, the development budget is about to be cut. When senior scientists talk blue sky, the clouds are about to roll in.
Truly, this is not the Tao of Programming.
When managers make commitments, game programs are ignored. When accountants make long-range plans, harmony and order are about to be restored. When senior scientists address the problems at hand, the problems will soon be solved.
Truly, this is the Tao of Programming.
6.2
Why are programmers non-productive?
Because their time is wasted in meetings.
Why are programmers rebellious?
Because the management interferes too much.
Why are the programmers resigning one by one?
Because they are burnt out.
Having worked for poor management, they no longer value their jobs.
6.3
A manager was about to be fired, but a programmer who worked for him invented a new program that became popular and sold well. As a result, the manager retained his job.
The manager tried to give the programmer a bonus, but the programmer refused it, saying, ``I wrote the program because I thought it was an interesting concept, and thus I expect no reward.''
The manager upon hearing this remarked, ``This programmer, though he holds a position of small esteem, understands well the proper duty of an employee. Let us promote him to the exalted position of management consultant!''
But when told this, the programmer once more refused, saying, ``I exist so that I can program. If I were promoted, I would do nothing but waste everyone's time. Can I go now? I have a program that I'm working on."
6.4
A manager went to his programmers and told them: ``As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon.'' At this, all of them became angry and several resigned on the spot.
So the manager said: ``All right, in that case you may set your own working hours, as long as you finish your projects on schedule.'' The programmers, now satisfied, began to come in at noon and work to the wee hours of the morning.
Book 7 - Corporate Wisdom
Thus spake the master programmer:
``You can demonstrate a program for a corporate executive, but you can't make him computer literate.''
7.1
A novice asked the master: ``In the east there is a great tree-structure that men call `Corporate Headquarters'. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying `Go, Hence!' or `Go, Hither!' and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity be?"
The master replied: ``You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?''
7.2
In the east there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from Corporate Headquarters. This message it drops into the midst of the programmers, like a seagull making its mark upon the beach. Then the bird mounts on the wind and, with the blue sky at its back, returns home.
The novice programmer stares in wonder at the bird, for he understands it not. The average programmer dreads the coming of the bird, for he fears its message. The master programmer continues to work at his terminal, for he does not know that the bird has come and gone.
7.3
The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master's office while the master waited in silence.
``This is an integrated, distributed, general-purpose workstation,'' began the magician, ``ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state of the art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?''
The master raised his eyebrows slightly. ``It is indeed amazing,'' he said.
``Corporate Headquarters has commanded,'' continued the magician, ``that everyone use this workstation as a platform for new programs. Do you agree to this?''
``Certainly,'' replied the master, ``I will have it transported to the data center immediately!'' And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, ``I cannot find the listing for my new program. Do you know where it might be?''
``Yes,'' replied the master, ``the listings are stacked on the platform in the data center.''
7.4
The master programmer moves from program to program without fear. No change in management can harm him. He will not be fired, even if the project is cancelled. Why is this? He is filled with Tao.
Book 8 - Hardware and Software
Thus spake the master programmer:
``Without the wind, the grass does not move. Without software, hardware is useless.''
8.1
A novice asked the master: ``I perceive that one computer company is much larger than all others. It towers above its competition like a giant among dwarfs. Any one of its divisions could comprise an entire business. Why is this so?''
The master replied, ``Why do you ask such foolish questions? That company is large because it is large. If it only made hardware, nobody would buy it. If it only made software, nobody would use it. If it only maintained systems, people would treat it like a servant. But because it combines all of these things, people think it one of the gods! By not seeking to strive, it conquers without effort.''
8.2
A master programmer passed a novice programmer one day. The master noted the novice's preoccupation with a hand-held computer game. ``Excuse me,'' he said, ``may I examine it?''
The novice bolted to attention and handed the device to the master. ``I see that the device claims to have three levels of play: Easy, Medium, and Hard,'' said the master. ``Yet every such device has another level of play, where the device seeks not to conquer the human, nor to be conquered by the human.''
``Pray, great master,'' implored the novice, ``how does one find this mysterious setting?''
The master dropped the device to the ground and crushed it underfoot. And suddenly the novice was enlightened.
8.3
There was once a programmer who worked upon microprocessors. ``Look at how well off I am here,'' he said to a mainframe programmer who came to visit, ``I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self- consistent and easy-to-use. Why do you not quit your present job and join me here?''
The mainframe programmer then began to describe his system to his friend, saying ``The mainframe sits like an ancient sage meditating in the midst of the data center. Its disk drives lie end-to-end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am.''
The microcomputer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
8.4
Hardware met Software on the road to Changtse. Software said: ``You are Yin and I am Yang. If we travel together we will become famous and earn vast sums of money.'' And so the set forth together, thinking to conquer the world.
Presently they met Firmware, who was dressed in tattered rags and hobbled along propped on a thorny stick. Firmware said to them: ``The Tao lies beyond Yin and Yang. It is silent and still as a pool of water. It does not seek fame, therefore nobody knows its presence. It does not seek fortune, for it is complete within itself. It exists beyond space and time.''
Software and Hardware, ashamed, returned to their homes.
Book 9 - Epilogue
Thus spake the master programmer:
``It is time for you to leave.''
]]>
]]>
1) 抽象构g角色Q?/span>ComponentQ：定义一个抽象接口，以规范准备接攉加责ȝ对象?/span>
2) 具体构g角色(Concrete Component)Q这是被装饰者，定义一个将要被装饰增加功能的类?/span>
3) 装饰角色(Decorator)Q持有一个构件对象的实例Qƈ定义了抽象构件定义的接口?/span>
4) 具体装饰角色(Concrete Decorator)Q负责给构gd增加的功能?/span>
JAVA?/span>IO的设计大量运用了装饰模式。看看我们熟悉的代码:
Q?Q?装饰对象和真实对象有相同的接口。这样客L对象可以以和真实对象相同的方式和装饰对象交互?br /> Q?Q?装饰对象包含一个真实对象的索引QreferenceQ?br /> Q?Q?装饰对象接受所有的来自客户端的h。它把这些请求{发给真实的对象?br /> Q?Q?装饰对象可以在{发这些请求以前或以后增加一些附加功能。这样就保了在q行Ӟ不用修改l定对象的结构就可以在外部增加附加的功能。在面向对象的设计中Q通常是通过l箋来实现对l定cȝ功能扩展?br />
BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream("..")));
层层包装Q增强功能。这是装饰模式的要旨?/font>
]]>
本文是本人对q三U模式学习后的一个小l以及对他们之间的区别的理解?/p>
单工?/strong>
单工厂模式的工厂cM般是使用静态方法，通过接收的参数的不同来返回不同的对象实例?/p>
不修改代码的话，是无法扩展的?/p>
抽象工厂
抽象工厂是应对品族概念的。比如说Q每个汽车公司可能要同时生轿RQ货车，客RQ那么每一个工厂都要有创徏轿RQ货车和客R的方法?/p>
应对产品族概念而生Q增加新的品线很容易，但是无法增加新的产品?/p>
结
★工厂模式中Q重要的是工厂类Q而不是品类。品类可以是多UŞ式，多层l承或者是单个c都是可以的。但要明的Q工厂模式的接口只会q回一U类型的实例Q这是在设计产品cȝ时候需要注意的Q最好是有父cL者共同实现的接口?/p>
★用工厂模式，q回的实例一定是工厂创徏的，而不是从其他对象中获取的?/p>
★工厂模式返回的实例可以不是新创建的Q返回由工厂创徏好的实例也是可以的?/p>
区别
单工?/span> Q?/span> 用来生同一{l构中的L产品。（对于增加新的产品Q无能ؓ力）
工厂模式 Q用来生产同一{l构中的固定产品。（支持增加L产品Q?
抽象工厂
Q用来生产不同品族的全部品。（对于增加新的产品Q无能ؓ力；支持增加产品族）
以上三种工厂 Ҏ在等U结构和产品族这两个方向上的支持E度不同。所以要Ҏ情况考虑应该使用哪种Ҏ?
]]>
(2)兌(association)是一U结构关p，q接模型元素及链接实例，用一条实U来表示?
(3)泛化(generalization)是一U特D／一般关p，Ҏ元素(子元?的对象可替代一般元?父元?的对象，用这U方法，子元素共享了 父元素的l构和行为。在囑Ş上，把一个泛化关pȝ成一条带有空心箭头的实线Q它指向父元素?
(4)实现(realization)是类元之间的语义关系Q其中一个类元指定了由另一个类元保证执行的契约。在两种地方要遇到实现关p：一U是在接口和 实现它们的类或构件之_另一U是在用例和实现它们的协作之间。在囑Ş上，把一个实现关pȝ成一条带有空心箭头的虚线?nbsp;
(5)聚集(aggregation)表示整体与部分的关系Q用一条实U加I心菱Ş来表C；
(6)l成(Composition)表示整体与部分的有一关系Q用一条实U加实心菱Ş来表C；
UML中几U类间关p：l承、实现、依赖、关联、聚合、组合的联系与区?/p>
l承
指的是一个类Q称为子cR子接口Q承另外的一个类Q称为父cR父接口Q的功能Qƈ可以增加它自q新功能的能力Q承是cMcL者接口与接口之间最常见的关p；在Java中此cdp通过关键字extends明确标识Q在设计时一般没有争议性；
实现
指的是一个classcd现interface接口Q可以是多个Q的功能Q实现是cM接口之间最常见的关p；在Java中此cdp通过关键字implements明确标识Q在设计时一般没有争议性；
依赖
可以单的理解Q就是一个类A使用C另一个类BQ而这U用关pLh偶然性的、、时性的、非常弱的，但是Bcȝ变化会媄响到AQ比如某q河Q需要借用一条船Q此时h与船之间的关pd是依赖；表现在代码层面，为类B作ؓ参数被类A在某个methodҎ中用；
兌
他体现的是两个类、或者类与接口之间语义别的一U强依赖关系Q比如我和我的朋友；q种关系比依赖更强、不存在依赖关系的偶然性、关pM不是临时?
的，一般是长期性的Q而且双方的关pM般是q等的、关联可以是单向、双向的Q表现在代码层面Qؓ被关联类B以类属性的形式出现在关联类A中，也可能是兌
cA引用了一个类型ؓ被关联类B的全局变量Q?br />
聚合
聚合是关联关pȝ一U特例，他体现的是整体与部分、拥有的关系Q即has-a的关p，此时整体与部分之间是可分ȝQ他们可以具有各自的生命周期Q?
部分可以属于多个整体对象Q也可以为多个整体对象共享；比如计算ZCPU、公怸员工的关pȝQ表现在代码层面Q和兌关系是一致的Q只能从语义U别?
区分Q?br />
l合
l合也是兌关系的一U特例，他体现的是一Ucontains-a的关p，q种关系比聚合更强，也称为强聚合Q他同样体现整体与部分间的关p，但此
时整体与部分是不可分的，整体的生命周期结束也意味着部分的生命周期结束；比如你和你的大脑Q表现在代码层面Q和兌关系是一致的Q只能从语义U别来区
分；
对于l承、实现这两种关系没多疑问，他们体现的是一U类与类、或者类与接口间的纵向关p；其他的四者关pd体现的是cMcR或者类与接口间的引
用、横向关p，是比较难区分的，有很多事物间的关p要惛_备定位是很难的，前面也提刎ͼq几U关p都是语义别的Q所以从代码层面q不能完全区分各U关
p；但ȝ来说Q后几种关系所表现的强q度依ơؓQ组?gt;聚合>兌>依赖Q?/p>
? 水木上看C分析DCLQ双锁?Double Checked LockQ安全性的文章。记得以前也讨论q这个问题，但是Z么DCL也存在隐患，至今没弄明白Q这分析做了比较详的解释Q概括v来原因有两点Q一? 因ؓ~译器或者处理器q不是严格按照程序顺序进行指令调度。二是java中同步机制的存在?/p>
原文来自Q?/p>
发信? wyxzellux (I still believe...), 信区: Java
? ? Singleton模式与双锁?DCL)
发信? 水木C (Mon Apr 7 23:42:14 2008), 站内
看OOP教材Ӟ提到了一个双锁?Double-Checked Lock, DCL)的问题，但是书上没有多介l，只是说这是一个和底层内存机制有关的漏z。查阅了下相兌料，对这个问题大致有了点了解?br />
从头开始说吧?br />
在多U程的情况下Singleton模式会遇C问题，一个简单的例子
1: class Singleton {
2: private static Singleton instance = null;
3:
4: public static Singleton instance() {
5: if (instance == null) {
6: instance = new Singleton();
7: }
8: return instance;
9: }
10: }
?
设这样一个场景，有两个线E调用Singleton.instance()Q首先线E一判断instance是否{于nullQ判断完后一瞬间虚拟机把U?
E二调度行线E，U程二再ơ判断instance是否为nullQ然后创Z个Singleton实例Q线E二的时间片用完后，U程一被唤醒，接下?
它执行的代码依然是instance = new Singleton();
两次调用q回了不同的对象Q出现问题了?br />
最单的Ҏ自然是在c被载入时就初始化这个对象：private static Singleton instance = new Singleton();
JLS(Java Language Specification)中规定了一个类只会被初始化一ơ，所以这样做肯定是没问题的?br />
但是如果要实现gq初始化(Lazy initialization)Q比如这个实例初始化时的参数要在q行期才能确定，应该怎么做呢Q?br />
依然有最单的ҎQ用synchronized关键字修饰初始化ҎQ?br />
public synchronized static Singleton instance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
q里有一个性能问题Q多个线E同时访问这个方法时Q会因ؓ同步而导致每ơ只有一个线E运行，影响E序性能。而事实上初始化完毕后只需要简单的q回instance的引用就行了?br />
DCL是一?#8220;看似”有效的解x法，先把对应代码放上来吧Q?br />
1 : class Singleton {
2 : private static Singleton instance = null ;
3 :
4 : public static Singleton instance() {
5 : if (instance == null ) {
6 : synchronized (this) {
7 : if (instance == null)
8 : instance = new Singleton();
9 : }
10 : }
11 : return instance;
12 : }
13 : }
用JavaWorld上对应文章的标题来评U做法就是smart, but broken。来看原因：
Java
~译器ؓ了提高程序性能会进行指令调度，CPU在执行指令时同样Z性能会ؕ序执行（臛_现在用的大多数通用处理器都是out-of-order的）Q另
外cache的存在也会改变数据回写内存时的顺序[2]。JMM(Java Memory Model,
见[1])指出所有的q些优化都是允许的，只要q行l果和严格按序执行所得的l果一样即可?br />
Java假设每个U程都跑在自q处理?
上，享有自己的内存，和共享的d交互。注意即使在单核上这U模型也是有意义的，考虑到cache和寄存器会保存部分时变量。理Z每个U程修改自己?
内存后，必须立即更新对应的主存内宏V但是Java设计师们认ؓq种U束会媄响程序性能Q他们试着创造了一套让E序跑得更快、但又保证线E之间的交互与预
期一致的内存模型?br />
synchronized关键字便是其中一把利器。事实上Qsynchronized块的实现和Linux中的信号?
(semaphore)q是有区别的Q前者过E中锁的获得和释N会都会引发一ơMemory
Barrier来强制线E本地内存和d之间的同步。通过q个机制QJava中的同步机制保证了synchronized块中指o的原子?
(atomic)?br />
好了Q回q头来看DCL问题。看h讉K一个未同步的instance字段不会产生什么问题，我们再次来假设一个场景：
U程一q入同步块，执行instance = new Singleton(); U程二刚开始执行getResource();
按照序的话Q接下来应该执行的步骤是 1) 分配新的Singleton对象的内?2) 调用Singleton的构造器Q初始化成员字段 3) instance被赋为指向新的对象的引用?br />
?
面说q，~译器或处理器都Z提高性能都有可能q行指o的ؕ序执行，U程一的真正执行步骤可能是1) 分配内存 2) instance指向新对?
3)
初始化新实例。如果线E二?完成?执行前被唤醒Q它看到了一个不为null的instanceQ蟩出方法体CQ带着一个还没初始化?
Singleton对象?br />
错误发生的一U情形就是这P关于更详l的~译器指令调度导致的问题Q可以参看这个网?[4]?br />
[3] 中提供了一个编译器指o调度的证?br />
instance = new Singleton(); q条命o在Symantec JIT中被~译?br />
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; 分配I间
02061074 mov dword ptr [ebp],eax ; EBP中保存了instance的地址
02061077 mov ecx,dword ptr [eax] ; 解引用，获得新的指针地址
02061079 mov dword ptr [ecx],100h ; 接下来四行是inline后的构造器
0206107F mov dword ptr [ecx+4],200h
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
可以看到Q赋值完成在初始化之前，而这是JLS允许的?br />
?
一U情形是Q假讄E一安稳地完成Singleton对象的初始化Q退Z同步块，q同步了和本地内存和d。线E二来了Q看C个非I的引用Q拿走。注
意线E二没有执行一个Read BarrierQ因为它Ҏ没q后面的同步块。所以很有可能此时它看到的数据是陈旧的?br />
q有很多人根据已知的几种提出了一个又一个fix的方法，但最l还是出C更多的问题。可以参阅[3]中的介绍?br />
[5]中还说明了即使把instance字段声明为volatileq是无法避免错误的原因?br />
由此可见Q安全的Singleton的构造一般只有两U方法，一是在c蝲入时创实例Q二是用性能较差的synchronizedҎ?br />
(by ZelluX http://www.aygfsteel.com/zellux )
参考资料：
[1] Java Language Specification, Second Edition, W?7章介l了Java中线E和内存交互关系的具体细节?br />
[2] out-of-order与cache的介l可以参阅Computer System, A Programmer's Perspective的第四、五章?br />
[3] The "Double-Checked Locking is Broken" Declaration, http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
[4] Synchronization and the Java Memory Model, http://gee.cs.oswego.edu/dl/cpj/jmm.html
[5] Double-checked locking: Clever, but broken, http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html?page=1
[6] Holub on Patterns, Learning Design Patterns by Looking at Code
]]>
也许有h会问Qؓ什么不在项目开始时多花些时间把设计做好Q而要以后花时间来重构呢？要知道一个完 得可以预见未来M变化的设计，或一个灵zd可以容纳M扩展的设计是不存在的。系l设计h员对卛_着手的目往往只能从大方向予以把控Q而无法知道每 个细枝末节，其次永远不变的就是变化，提出需?/a>的用户往往要在软g成型后，始才开?品头"Q系l设计h员毕竟不是先知先觉的仙Q功能的变化D设计的调整再所隑օ。所?试为先Q持l重?作ؓ良好开发习惯被来多的h所采纳Q测试和重构像黄河的护堤Q成Z证Y件质量的法宝?/font>
一、ؓ什么要重构QRefactoringQ?/strong>
在不改变pȝ功能的情况下Q改变系l的实现方式。ؓ什么要q么做？投入_֊不用来满_户关心的需求，而是仅仅改变了Y件的实现方式Q这是否是在费客户的投资呢Q?/font>
重构的重要性要从Y件的生命周期说v。Y件不同与普通的产品Q他是一U智力品，没有具体的物理Ş态。一个Y件不可能发生物理损耗，界面上的按钮永远不会因ؓ按动ơ数太多而发生接触不良。那么ؓ什么一个Y件制造出来以后，却不能永q用下dQ?/font>
对Y件的生命造成威胁的因素只有一个：需求的变更。一个Y件LxU特定的需求而生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一 些，有的需求变化的比较剧烈Q还有的需求已l消׃Q或者{化成了别的需求。在q种情况下，软g必须相应的改变?/font>
考虑到成本和旉{因素，当然不是所有的需求变化都要在软gpȝ中实现。但是ȝ说来QY件要适应需求的变化Q以保持自己的生命力?/font>
q就产生了一U糟p的现象QY件品最初制造出来，是经q精心的设计Q具有良好架构的。但是随着旉的发展、需求的变化Q必M断的修改原有的功能、追? 新的功能Q还免不了有一些缺陷需要修攏Vؓ了实现变_不可避免的要q反最初的设计构架。经q一D|间以后，软g的架构就千疮癑֭了。bug来多Q越 来越隄护，新的需求越来越隑֮玎ͼ软g的构架对新的需求渐渐的失去支持能力Q而是成ؓ一U制U。最后新需求的开发成本会过开发一个新的Y件的成本Q这 是q个软gpȝ的生命走到尽头的时候?/font>
重构p够最大限度的避免q样一U现象。系l发展到一定阶D后Q用重构的方式Q不改变pȝ的外部功能，只对内部的结构进行重新的整理。通过重构Q不断的调整pȝ的结构，使系l对于需求的变更始终h较强的适应能力?/font>
通过重构可以辑ֈ以下的目标：
·持箋偏纠和改qY件设?/font>
重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必d预先的设计，但是不必是最优的设计Q只需要一个合理的解决Ҏ够了，如果没有重构?a target="_new">E序设计会逐渐腐|变质Q愈来愈像断U的风筝Q脱~的野马无法控制。重构其实就是整理代码，让所有带着发散們的代码回归本位?/font>
·使代码更易ؓ人所理解
Martin Flower在《重构》中有一句经典的话："M一个傻瓜都能写?a target="_new">计算?/a>可以理解的程序，只有写出?a target="_new">c?/a>Ҏ理解的程序才是优U的程序员?ҎQ笔者感触很深，有些E序员L能够快速编写出可运行的代码Q但代码中晦涩的命名使h晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这L代码他会不会惛_逃兵呢？
软g的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来h。ؓ了代码Ҏ被他人理解，需要在实现软g功能时做许多额外的事Ӟ如清晰的排版布局Q简明扼要的注释Q其中命名也是一个重要的斚w。一个很好的办法是采用暗喻命名Q即?a target="_new">对象实现的功能的依据Q用形象化或拟h化的手法q行命名Q一个很好的态度是每个代码元素像新生儿一样命名，也许W者有点命名偏执狂的們Q如能荣此雅P深以此为幸?/font>
对于那些让h充满q感甚臌导性的命名Q需要果军_、大刀阔斧地整容，永远不要手下留情Q?/font>
·帮助发现隐藏的代码缺?/font>
孔子说过Q温故而知新。重构代码时D你加q解原先所写的代码。笔者常有写下程序后Q却发生对自 qE序逻辑不甚理解的情景，曾ؓ此惊悚过Q后来发现这U症状居然是许多E序员常患的"感冒"。当你也发生q样的情形时Q通过重构代码可以加深对原设计? 理解Q发现其中的问题和隐患，构徏出更好的代码?/font>
·从长q来看，有助于提高编E效?/font>
当你发现解决一个问题变得异常复杂时Q往往不是问题本n造成的，而是你用错了ҎQ拙劣的设计往往D臃肿的编码?/font>
改善设计、提高可L、减缺陷都是ؓ了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计Q或怼在当前减~速度Q但它带来的后发优势却是不可低估的?/font>
二、何时着手重构（RefactoringQ?/strong>
新官上Q三把火，开始一个全新的目ӞE序员往往也会燃v三把火：紧锣密鼓、脚不停y、加班加点，一支声势浩大的千军??夹裹着E序员激情和扣击键盘的鸣金奋力前行，势如破竹Q攻城掠圎ͼ直指"黄龙??/font>
开发经理是q支浩汤汤代码队伍的统帅，他负责这支队伍的命运Q当齐恒公站在山上看到仲训练? 队伍整齐划一地前q时Q他感叹?我有q样一支军队哪里还怕没有胜利呢Q?。但很遗憾，你手中的q支队伍原本只是散兵游勇Q在前进中招兵买马，不断壮大Q? 所以队伍变形在所隑օ。当开发经理发觉队伍变形时Q也许就是克制住d前方山头的诱惑，停下脚步整顿队伍的时候了?
Kent Beck提出?代码坏味?的说法，和我们所提出?队伍变Ş"是同L意思，队伍变Ş的信h什么呢Q以下列q的代码症状是"队伍变Ş"的强烈信P
·代码中存在重复的代码
中国?18 家整车生产企业，数量几乎{于、日、欧所有汽车厂家数之和Q但是全国的q量却不及一个外国大汽R公司的量。重复徏讑֏会导致效率的低效和资源的费?/font>
E序代码更是不能搞重复徏设，如果同一个类中有相同的代码块Q请把它提炼成类的一个独立方法，如果不同cMh相同的代码，h它提炼成一个新c，永远不要重复代码?
·q大的类和过长的Ҏ
q大的类往往是类抽象不合理的l果Q类抽象不合理将降低了代码的复用率。方法是cȝ国中的诸侯国Q? 怾国太大势必动摇中央集权。过长的Ҏ׃包含的逻辑q于复杂Q错误机率将直线上升Q而可L则直线下降Q类的健壮性很Ҏ被打破。当看到一个过长的? 法时Q需要想办法其划分为多个小ҎQ以便于分而治之?/font>
·牵一毛而需要动全n的修?/font>
当你发现修改一个小功能Q或增加一个小功能Ӟ引发一ơ代码地震，也许是你的设计抽象度不够理想Q功能代码太q分散所引v的?/font>
·cM间需要过多的通讯
Ac需要调用Bcȝq多Ҏ讉KB的内部数据，在关pMq两个类昑־有点狎昵Q可能这两个cL应该在一P而不应该分家?/font>
·q度耦合的信息链
"计算机是q样一门科学，它相信可以通过d一?a target="_new">中间?/a>解决M问题"Q所以往往中间层会被过多地q加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接Q就象输油管一栯节相q。这往往是因接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法?/font>
·各立山头q革?/font>
如果你发现有两个cL两个Ҏ虽然命名不同但却拥有怼或相同的功能Q你会发现往往是因为开?a target="_new">团队成员协调不够造成的。笔者曾l写了一个颇好用的字W串处理c，但因为没有及旉告团队其他人员Q后来发现项目中居然有三个字W串处理cR革命资源是珍贵的，我们不应各立山头q革命?
·不完的设计
在笔者刚完成的一个比Ҏ警项目中Q曾安排阿朱开发报警模块，即通过Socket向指定的短信q_、语韛_^台及客户?/a>? 警器插g发送报警报文信息，阿朱地完成了q项d。后来用户又提出了实时比对的需求，卌求第三方pȝ以报文Ş式向比对报警pȝ发送请求，比对报警p? l接收ƈ响应q个h。这又需要用到Socket报文通讯Q由于原来的设计没有报文通讯模块独立出来Q所以无法复用阿朱开发的代码。后来我及时调整了这 个设计，新增了一个报文收发模块，使系l所有的对外通讯都复用这个模块，pȝ的整体设计也昑־更加合理?/font>
每个pȝ都或多或存在不完美的设计，刚开始可能注意不刎ͼ到后来才会慢慢凸昑և来，此时唯有勇于更改才是最好的\?/font>
·~少必要的注?/font>
虽然许多软g工程? 书籍常提醒程序员需要防止过多注释，但这个担心好象ƈ没有什么必要。往往E序员更感兴的是功能实现而非代码注释Q因为前者更能带来成感Q所以代码注? 往往不是q多而是q少Q过于简单。h的记忆曲U下降的坡度是陡得吓人的Q当q了一D|间后再回头补注释Ӟ很容易发?提笔忘字Q愈a且止"的情形?/font>
曑֜|上看到q微软的代码注释Q其详尽E度让h叹ؓ观止Q也从中体悟C微Y成功的一个经验?
三、重构（RefactoringQ的N
学习一U可以大q提高生产力的新技术时Q你L难以察觉其不适用的场合。通常你在一个特定场景中学习它，q个场景往往是个目。这U情况下你很隄Z么会造成q种新技术成效不彰或甚至形成危害。十q前Q对象技术（object tech.Q的情况也是如此。那时如果有人问我「何时不要用对象」，我很隑֛{。ƈ非我认ؓ对象十全十美、没有局限??我最反对q种盲目态度Q而是管我知道它的好处，但确实不知道其局限性在哪儿?/font>
现在Q重构的处境也是如此。我们知道重构的好处Q我们知道重构可以给我们的工作带来垂手可得的改变。但是我们还没有获得_的经验，我们q看不到它的局限性?br /> q? 一节比我希望的要短。暂且如此吧。随着更多人学会重构技巧，我们也将对它有更多了解。对你而言q意呻I虽然我坚册Z应该试一下重构，获得它所提供 的利益，但在此同Ӟ你也应该时时监控其过E，注意L重构可能引入的问题。请让我们知道你所遭遇的问题。随着寚w构的了解日益增多Q我们将扑և更多解决 办法Qƈ清楚知道哪些问题是真正难以解决的?/font>
「重构」经常出问题的一个领域就是数据库。绝大多数商用程序都与它们背后的database schemaQ数据库表格l构Q紧密耦合QcoupledQ在一Pq也是database schema如此难以修改的原因之一。另一个原因是数据q移QmigrationQ。就你非常心地将pȝ分层QlayeredQ，database schema和对象模型（object modelQ间的依赖降x低，但database schema的改变还是让你不得不q移所有数据，q可能是件O长而烦琐的工作?/font>
在「非对象数据库」（nonobject databasesQ中Q解册个问题的办法之一是Q在对象模型Qobject modelQ和数据库模型（database modelQ之间插入一个分隔层Qseparate layerQ，q就可以隔离两个模型各自的变化。升U某一模型时无需同时升另一模型Q只需升上述的分隔层卛_。这L分隔层会增加pȝ复杂度，但可? l你很大的灵zd。如果你同时拥有多个数据库，或如果数据库模型较ؓ复杂使你难以控制Q那么即使不q行重构Q这分隔层也是很重要的?/font>
你无需一开始就插入分隔层，可以在发现对象模型变得不E_时再产生它。这样你可以ؓ你的改变扑ֈ最好的杠杆效应?/font>
对开发者而言Q对象数据库既有帮助也有妨碍。某?a target="_new">面向对象? 据库提供不同版本的对象之间的自动q移功能Q这减少了数据迁UL的工作量Q但q是会损׃定时间。如果各数据库之间的数据q移q自动q行Q你必自? 完成q移工作Q这个工作量可是很大的。这U情况下你必L加留classes内的数据l构变化。你仍然可以攑ֿclasses的行{U过去，但{U? 值域QfieldQ时必L外小心。数据尚未被转移前你得先运用访问函敎ͼaccessorsQ造成「数据已l{UR的假象。一旦你定知道「数据应 该在何处」时Q就可以一ơ性地数据迁U过厅R这时惟一需要修改的只有讉K函数QaccessorsQ，q也降低了错误风险?/font>
修改接口QChanging InterfacesQ?/font>
关于对象Q另一仉要事情是Q它们允怽分开修改软g模块的实玎ͼimplementationQ和接口QinterfaceQ。你可以安全CҎ对象内部而不影响他hQ但对于接口要特别}??如果接口被修改了QQ何事情都有可能发生?/font>
一直对重构带来困扰的一件事是Q许多重构手法的会修改接口。像Rename MethodQ?73Q这么简单的重构手法所做的一切就是修Ҏ口。这Ҏ为珍늚装概念会带来什么媄响呢Q?/font>
如果某个函数的所有调用动作都在你的控制之下，那么即修改函数名称也不会有M问题。哪怕面对一个public函数Q只要能取得q修改其所有调用者，? 也可以安心地这个函数易名。只有当需要修改的接口p被那些「找不到Q即使找C不能修改」的代码使用Ӟ接口的修Ҏ会成为问题。如果情늜是如此，? ׃_q个接口是个「已发布接口」（published interfaceQ?比公开接口Qpublic interfaceQ更q一步。接口一旦发行，你就再也无法仅仅修改调用者而能够安全地修改接口了。你需要一个略为复杂的E序?/font>
q个x改变了我们的问题。如今的问题是：该如何面寚w些必M攏V已发布接口」的重构手法Q?/font>
a之，如果重构手法改变了已发布接口Qpublished interfaceQ，你必d时维护新旧两个接口，直到你的所有用户都有时间对q个变化做出反应。幸q的是这不太困难。你通常都有办法把事情组l好Q让 旧接口l工作。请量q么做：让旧接口调用新接口。当你要修改某个函数名称ӞL下旧函数Q让它调用新函数。千万不要拷贝函数实现码Q那会让你陷? 「重复代码」（duplicated codeQ的泥淖中难以自拔。你q应该用Java提供?deprecationQ反对）设施Q将旧接口标Cؓ "deprecated"。这么一来你的调用者就会注意到它了?/font>
q个q程的一个好例子是Java容器c（collection classesQ。Java 2的新容器取代了原先一些容器。当Java 2容器发布ӞJavaSoft׃很大力气来ؓ开发者提供一条顺利迁徙之路?/font>
「保留旧接口」的办法通常可行Q但很烦人。v码在一D|间里你必d造（buildQƈl护一些额外的函数。它们会使接口变得复杂，使接口难以用。还? 我们有另一个选择Q不要发布（publishQ接口。当然我不是说要完全止Q因为很明显你必得发布一些接口。如果你正在建造供外部使用的APIsQ像 Sun所做的那样Q肯定你必得发布接口。我之所以说量不要发布Q是因ؓ我常常看C些开发团队公开了太多接口。我曄看到一支三人团队这么工作：每个? 都向另外两h公开发布接口。这使他们不得不l常来回l护接口Q而其实他们原本可以直接进入程序库Q径行修改自q理的那一部分Q那会轻松许多。过度强? 「代码拥有权」的团队常常会犯q种错误。发布接口很有用Q但也有代h。所以除非真有必要，别发布接口。这可能意味需要改变你的代码拥有权观念Q让每个人都 可以修改别h的代码，以运应接口的改动。以搭档Q成对）~程QPair ProgrammingQ完成这一切通常是个好主意?/font>
不要q早发布QpublishedQ接口。请修改你的代码拥有权政{，佉K构更畅?/font>
Java之中q有一个特别关于「修Ҏ口」的问题Q在throws子句中增加一个异常。这q不是对{式（signatureQ的修改Q所以你无法? delegationQ委托手法）隐藏它。但如果用户代码不作出相应修改，~译器不会让它通过。这个问题很难解冟뀂你可以个函数选择一个新名字Q让? 函数调用它，q将q个新增的checked exceptionQ可控式异常Q{换成一个unchecked exceptionQ不可控异常Q。你也可以拋Z个unchecked异常Q不q这样你׃失去验能力。如果你那么做，你可以警告调用者：q个 unchecked异常日后会变成一个checked异常。这样他们就有时间在自己的代码中加上Ҏ异常的处理。出于这个原因，我L喜欢为整? package定义一个superclass异常Q就像java.sql的SQLExceptionQ，q确保所有public函数只在自己的throws子句中声明这个异常。这h可以随心所Ʋ地定义subclass异常Q不会媄响调用者，因ؓ调用者永q只知道那个更具一般性的superclass异常?/font>
难以通过重构手法完成的设计改?/font>
通过重构Q可以排除所有设计错误吗Q是否存在某些核心设计决{，无法以重构手法修改？在这个领域里Q我们的l计数据不完整。当然某些情况下我们可以很有 效地重构Q这常常令我们倍感惊讶Q但的确也有难以重构的地斏V比如说在一个项目中Q我们很难（但还是有可能Q将「无安全需求（no security requirementsQ情况下构造v来的pȝ」重构ؓ「安全性良好的Qgood securityQ系l」?/font>
q种情况下我的办法就是「先惌重构的情c。考虑候选设计方案时Q我会问自己Q将某个设计重构为另一个设计的隑ֺ有多大？如果看上d单，我就不必? 担心选择是否得当Q于是我׃选最单的设计Q哪怕它不能覆盖所有潜在需求也没关pR但如果预先看不到简单的重构办法Q我׃在设计上投入更多力气。不q? 我发玎ͼq种情况很少出现?/font>
何时不该重构Q?/font>
有时候你Ҏ不应该重??例如当你应该重新~写所有代码的时候。有时候既有代码实在太混ؕQ重构它q不如从新写一个来得简单。作U决定很困难Q我承认我也没有什么好准则可以判断何时应该攑ּ重构?/font>
重写Q而非重构Q的一个清楚讯号就是：现有代码Ҏ不能正常q作。你可能只是试着做点试Q然后就发现代码中满是错误，Ҏ无法E_q作。记住，重构之前Q代码必v码能够在大部分情况下正常q作?/font>
一个折衷办法就是：「大块头软g」重构ؓ「封装良好的型lg」。然后你可以逐一对组件作出「重构或重徏」的军_。这是一个颇具希望的办法Q但我还没有_数据Q所以也无法写出优秀的指导原则。对于一个重要的古老系l，q肯定会是一个很好的方向?/font>
另外Q如果项目已q最后期限，你也应该避免重构。在此时机，从重构过E赢得的生力只有在最后期限过后才能体现出来，而那个时候已l时不我予。Ward CunninghamҎ有一个很好的看法。他把未完成的重构工作Ş容ؓ「债务」。很多公叔R需要借债来使自己更有效地运转。但是借债就得付利息Q过于复 杂的代码所造成的「维护和扩展的额外开销」就是利息。你可以承受一定程度的利息Q但如果利息太高你就会被压垮。把债务理好是很重要的Q你应该随时通过? 构来偿还一部分债务?/font>
如果目已经非常接近最后期限，你不应该再分心于重构Q因为已l没有时间了。不q多个项目经验显C：重构的确能够提高生力。如果最后你没有_旉Q通常pCZ其实早该q行重构?/font>
四、重构（RefactoringQ与设计
「重构」肩负一特别Q务：它和设计彼此互补。初学编E的时候，我埋头就写程序，浑噩噩地进行开发。然而很快我便发玎ͼ「事先设计」（upfront designQ可以助我节省回头工的高昂成本。于是我很快加强q种「预先设计」风根{许多h都把设计看作软g开?/a>? 关键环节Q而把~程QprogrammingQ看作只是机械式的低U劳动。他们认计就像画工程图而编码就像施工。但是你要知道，软g和真实器械有着? 大的差异。Y件的可塑性更强，而且完全是思想产品。正如Alistair Cockburn所_『有了设计，我可以思考更快，但是其中充满漏z。?/font>
有一U观点认为：重构可以成ؓ「预先设计」的替代品。这意思是你根本不必做M设计Q只按照最初想法开始编码，让代码有效运作，然后再将它重构成型。事实上q种办法真的可行。我的确看过有hq么做，最后获得设计良好的软g?a target="_new">极限~程Q?a target="_new">Extreme ProgrammingQ[Beck, XP] 的支持者极力提倡这U办法?/font>
管如上所aQ只q用重构也能收到效果Q但qƈ不是最有效的途径。是的，即极限~程QExtreme ProgrammingQ爱好者也会进行预先设计。他们会使用CRC卡或cM的东西来验各U不同想法，然后才得到第一个可被接受的解决ҎQ然后才能开 始编码，然后才能重构。关键在于：重构改变了「预先设计」的角色。如果没有重构，你就必须保证「预先设计」正无误，q个压力太大了。这意味如果来需? 对原始设计做M修改Q代价都非帔R昂。因此你需要把更多旉和精力放在预先设计上Q以避免日后修改?/font>
如果你选择重构Q问题的重点p{变了。你仍然做预先设计，但是不必一定找出正的解决Ҏ。此ȝ你只需要得C个够合理的解决Ҏ够了。你很肯定地 知道Q在实现q个初始解决Ҏ的时候，你对问题的理解也会逐渐加深Q你可能会察觉最佌x案和你当初设想的有些不同。只要有重构q项武器在手Q就不成? 题，因ؓ重构让日后的修改成本不再高昂?/font>
q种转变D一个重要结果：软g设计朝向化前q了一大步。过L曾运用重构时Q我L力求得到灉|的解x案。Q何一个需求都让我提心吊胆地猜疑：在系 l寿命期_q个需求会D怎样的变化？׃变更设计的代价非帔R昂，所以我希望建造一个够灵zR够强固的解决ҎQ希望它能承受我所能预见的所有需 求变化。问题在于：要徏造一个灵zȝ解决ҎQ所需的成本难以估。灵zȝ解决Ҏ比简单的解决Ҏ复杂许多Q所以最l得到的软g通常也会更难l护 ? 虽然它在我预先设想的方向上的是更加灉|。就幸q走在预先设想的方向上，你也必须理解如何修改设计。如果变化只出现在一两个地方Q那不算大问题。然? 变化其实可能出现在系l各处。如果在所有可能的变化出现地点都徏立v灉|性，整个pȝ的复杂度和维护难度都会大大提高。当Ӟ如果最后发现所有这些灵zL? 都毫无必要，q才是最大的p|。你知道Q这其中肯定有些灉|性的派不上用场Q但你却无法预测到底是哪些派不上用场。ؓ了获得自己想要的灉|性，你不得不 加入比实际需要更多的灉|性?/font>
有了重构Q你可以通过一条不同的途径来应付变化带来的风险。你仍旧需要思考潜在的变化Q仍旧需要考虑灉|的解x案。但是你不必再逐一实现q些解决? 案，而是应该问问自己Q『把一个简单的解决Ҏ重构成这个灵zȝҎ有多大难度？』如果答案是「相当容易」（大多数时候都如此Q，那么你就只需实现目前? 单方案就行了?br /> 重构可以带来更简单的设计Q同时又不损qzL，q也降低了设计过E的隑ֺQ减M设计压力。一旦对重构带来的简单性有更多? 受，你甚臛_以不必再预先思考前q所谓的灉|Ҏ ? 一旦需要它Q你L_的信心去重构。是的，当下只管建造可q行的最化系l，至于灉|而复杂的设计Q唔Q多数时候你都不会需要它?/font>
劌无获?Ron Jeffries
Chrysler Comprehensive CompensationQ克莱斯勒综合薪资系l）的支付过E太慢了。虽然我们的开发还没结束，q个问题却已l开始困扰我们，因ؓ它已l拖累了试速度?/font>
Kent Beck、Martin Fowler和我军_解决q个问题。等待大伙儿会合的时间里Q凭着我对q个pȝ的全盘了解，我开始推：到底是什么让pȝ变慢了？我想到数U可能，然后? 伙伴们谈了几U可能的修改Ҏ。最后，关于「如何让q个pȝq行更快」，我们提出了一些真正的好点子?/font>
然后Q我们拿Kent的量工?a target="_new">度量了系l性能。我一开始所想的可能性竟然全都不是问题肇因。我们发玎ͼpȝ把一半时间用来创建「日期」实体（instanceQ。更有趣的是Q所有这些实体都有相同的倹{?/font>
于是我们观察日期的创建逻辑Q发现有Z它优化。日期原本是由字W串转换而生Q即使无外部输入也是如此。之所以用字W串转换方式Q完全是Z方便键盘输入。好Q也许我们可以将它优化?/font>
于是我们观察日期怎样被这个程序运用。我们发玎ͼ很多日期对象都被用来产生「日期区间」实体（instanceQ。「日期区间」是个对象，׃个v始日期和一个结束日期组成。仔l追t下去，我们发现l大多数日期区间是空的！
处理日期区间时我们遵循这样一个规则：如果l束日期在v始日期之前，q个日期区间p是空的。这是一条很好的规则Q完全符合这?a target="_new">class的需要。采用此一规则后不久，我们意识刎ͼ创徏一个「v始日期在l束日期之后」的日期区间Q仍然不是清晰的代码，于是我们把这个行为提炼到一个factory methodQ译注：一个著名的设计模式Q见?a target="_new">Design Patterns》）Q由它专门创建「空的日期区间」?/font>
我们做了上述修改Q代码更加清晰Q却意外得到了一个惊喜。我们创Z个固定不变的「空日期区间」对象，q让上述调整后的factory method每次都返回该对象Q而不再每ơ都创徏新对象。这一修改把系l速度提升了几乎一倍，以让测试速度辑ֈ可接受程度。这只花了我们大U五分钟?/font>
我和团队成员QKent和Martin谢绝参加Q认真推过Q我们了若指掌的q个E序中可能有什么错误？我们甚至凭空做了些改q设计，却没有先对系l的真实情况q行量测?/font>
我们完全错了。除了一场很有趣的交谈，我们什么好事都没做?/font>
教训Q哪怕你完全了解pȝQ也请实际量它的性能Q不要臆。臆会让你学到一些东西，但十有八九你是错的?/font>
五、重构与性能QPerformanceQ?/strong>
译注Q在我的接触l验中，performance一词被不同的h予以不同的解释和认知Q效率、性能、效能。不同地区（例如台湾和大陆）的习惯用法亦不相 同。本书一遇performance我便译ؓ性能。efficient译ؓ高效Qeffective译ؓ有效?/font>
关于重构Q有一个常被提出的问题Q它对程序的性能造成怎样的媄响？Z让Y件易于理解，你常会作Z些ɽE序q行变慢的修攏V这是个重要的问题。我q不 赞成Z提高设计的纯z性或把希望寄托于更快的硬件n上，而忽略了E序性能。已l有很多软g因ؓ速度太慢而被用户拒绝Q日益提高的机器速度亦只不过略微? 宽了速度斚w的限制而已。但是，换个角度_虽然重构必然会软gq行更慢Q但它也使Y件的性能优化更易q行。除了对性能有严D求的实时Qreal timeQ系l，其它M情况下「编写快速Y件」的U密是Q首先写出可调（tunableQYӞ然后调整它以求获得够速度?/font>
我看q三U「编写快速Y件」的Ҏ。其中最严格的是「时间预法」（time budgetingQ，q通常只用于性能要求极高的实时系l。如果用这U方法，分解你的设计时就要做好预，l每个组仉先分配一定资?? 包括旉和执行轨q（footprintQ。每个组件绝对不能超q预算Q就拥有「可在不同组件之间调度预配时间」的机制也不行。这U方法高度重? 性能Q对于心律调节器一cȝpȝ是必ȝQ因为在q样的系l中q来的数据就是错误的数据。但对其他类pȝQ例如我l常开发的企业信息pȝQ而言Q如此追求高性能有点过份了?/font>
W二U方法是「持l关切法」（constant attentionQ。这U方法要求Q何程序员在Q何时间做M事时Q都要设法保持系l的高性能。这U方式很常见Q感觉上很有吸引力，但通常不会起太大作 用。Q何修改如果是Z提高性能Q通常会ɽE序难以l护Q因而减~开发速度。如果最l得到的软g的确更快了，那么q点损失有所|可惜通常事与愿违Q因 为性能改善一旦被分散到程序各角落Q每ơ改善都只不q是从「对E序行ؓ的一个狭隘视角」出发而已?/font>
关于性能Q一件很有趣的事情是Q如果你对大多数E序q行分析Q你会发现它把大半时间都耗费在一半代码w上。如果你一视同仁地优化所有代码，90% 的优化工作都是白费劲儿，因ؓ被你优化的代码有许多隑־被执行v来。你花时间做优化是ؓ了让E序q行更快Q但如果因ؓ~Z对程序的清楚认识而花Ҏ_? 些时间都是被费掉了?/font>
W三U性能提升法系利用上述?"90%" l计数据。采用这U方法时Q你以一U「良好的分解方式」（well-factored mannerQ来建造自qE序Q不Ҏ能投以M兛_Q直臌入性能优化阶段 ? 那通常是在开发后期。一旦进入该阶段Q你再按照某个特定程序来调整E序性能?/font>
在性能优化阶段中，你首先应该以一个量工L控程序的q行Q让它告诉你E序中哪些地方大量消耗时间和I间。这样你可以找出性能热点Qhot spotQ所在的一段代码。然后你应该集中兛_q些性能热点Qƈ使用前述「持l关切法」中的优化手D|优化它们。由于你把注意力都集中在热点上，较少? 工作量便可显现较好的成果。即便如此你q是必须保持谨慎。和重构一P你应该小q度q行修改。每C步都需要编译、测试、再ơ量。如果没能提高性能Q就 应该撤销此次修改。你应该l箋q个「发现热炏V去除热炏V的q程Q直到获得客h意的性能为止。关于这Ҏ术，McConnell [McConnell] 为我们提供了更多信息?/font>
一个被良好分解Qwell-factoredQ的E序可从两方面帮助此U优化Ş式。首先，它让你有比较充裕的时间进行性能调整Qperformance tuningQ，因ؓ有分解良好的代码在手Q你p够更快速地d功能Q也有更多旉用在性能问题上（准确的量则保证你把q些旉投资在恰当地点）? 其次Q面对分解良好的E序Q你在进行性能分析时便有较l的_度QgranularityQ，于是量测工具把你带入范围较小的程序段落中Q而性能的调整也? 较容易些。由于代码更加清晎ͼ因此你能够更好地理解自己的选择Q更清楚哪种调整起关键作用?/font>
我发现重构可以帮助我写出更快的Y件。短E看来，重构的确会软g变慢Q但它优化阶段中的软g性能调整更容易。最l我q是有赚头?/font>
六、重构v源何处？
我曾l努力想扑և重构QrefactoringQ一词的真正hQ但最l失败了。优UE序员肯定至会׃些时间来清理自己的代码。这么做是因为，他们知道z的代码比杂乱无章的代码更容易修改，而且他们知道自己几乎无法一开始就写出z的代码?/font>
重构不止如此。本书中我把重构看作整个软g开发过E的一个关键环节。最早认识重构重要性的两个人是Ward Cunningham和Kent BeckQ他们早?980s之前开始用SmalltalkQ那是个特别适合重构的环境。Smalltalk是一个十分动态的环境Q你可以很快写出? 具功能的软g。Smalltalk的「编?q结/执行」周期非常短Q因此很Ҏ快速修改代码。它是面向对象，所以也能够提供强大工具Q最大限度地修? 的媄响隐藏于定义良好的接口背后。Ward和Kent努力发展Z套适合q类环境的Y件开发过E（如今Kent把这U风格叫作极限编E?[Beck, XP]Q。他们意识到Q重构对于提高他们的生力非帔R要。从那时起他们就一直在工作中运用重构技术，在严肃而认真的软g目中用它Qƈ不断_q个E? 序?/font>
Ward和Kent的思想对SmalltalkC产生了极大媄响，重构概念也成为Smalltalk文化中的一个重要元素。SmalltalkC的另 一位领袖是Ralph JohnsonQ伊利诺斯大学乌班U_校教授，著名的「四巨头?[Gang of Four] 之一。Ralph最大的兴趣之一是开发Y?a target="_new">框架Q?a target="_new">frameworkQ。他揭示了重构对于灵z高效框架的开发帮助?/font>
Bill Opdyke是Ralph的博士研I生Q对框架也很感兴。他看到重构的潜在h|q看到重构应用于Smalltalk之外的其它语a的可能性。他的技? 背景是电话交换系l的开发。在q种pȝ中，大量的复杂情况与时俱增，而且非常难以修改。Bill的博士研I就是从工具构筑者的角度来看待重构。通过研究Q? Bill发现Q在C++ framework开发项目中Q重构很有用。他也研I了极有必要的「语义保持性（semantics-preservingQ重构」及其证明方式，以及? 何以工具实现重构。时至今日，Bill的博士论?[Opdyke] 仍然是重构领域中最有h倹{最丰硕的研I成果。此外他为本书撰写了W?3章?/font>
我还记得1992qOOPSLA大会上见到Bill的情景。我们坐在一间咖啡厅里，讨论当时我正Z健业务构{的一个概忉|Ӟconceptual frameworkQ中的某些工作。Bill跟我谈v他的研究成果Q我q记得自己当时的xQ『有，但ƈ非真的那么重要』。唉Q我完全错了?/font>
John Brant和Don Roberts重构中的「工兗构惛_扬光大，开发了一个名为「重构浏览器」（Refactoring BrowserQ的Smalltalk重构工具。他们撰写了本书W?4章，其中寚w构工具做了更多介l?/font>
那么Q我呢？我一直有清理代码的們Q但从来没有惛_q会有那么重要。后来我和Kent一起做了个目Q看C使用重构手法Q也看到重构对生产性能和? 质量带来的媄响。这份体验让我相信：重构是一门非帔R要的技术。但是，在重构的学习和推q过E中我遇C挫折Q因为我拿不ZQ何一本书l程序员看，也没? M一位专家打写样一本书。所以，在这些专家的帮助下，我写下了q本书?/font>
优化一个薪资系l?Rich Garzaniti
Chrysler Comprehensive
CompensationQ克莱斯勒综合薪资系l）交给GemStone公司之前Q我们用了相当长的时间开发它。开发过E中我们无可避免地发现程序不?
快，于是找了Jim Haungs ?GemSmith中的一位好??请他帮我们优化这个系l?/font>
Jim先用一Ҏ间让他的团队了解pȝq作方式Q然后以GemStone的ProfMonitorҎ编写出一个性能量测工具Q将它插入我们的功能试中。这个工具可以显C系l生的对象数量Q以及这些对象的诞生炏V?/font>
令我们吃惊的是：创徏量最大的对象竟是字符丌Ӏ其中最大的工作量则是反复?2,000-bytes的字W串。这很特别，因ؓq字W串实在太大了，q? GemStone惯用的垃圑֛收设施都无法处理它。由于它是如此巨大，每当被创建出来，GemStone都会它分页QpagingQ至盘上。也是? 字符串的创徏竟然用上了I/O子系l?/a>Q译注：分页机制会动用I/OQ，而每ơ输录时都要产生q样的字W串三次H?/font>
我们的第一个解军_法是把一?2,000-bytes字符串缓存（cachedQv来，q可解决一大半问题。后来我们又加以修改Q将它直接写入一个file streamQ从而避免生字W串?/font>
解决了「巨大字W串」问题后QJim的量工具又发现了一些类似问题，只不q字W串E微一些：800-bytes?00-bytes……{等Q我们也都对它们改用file streamQ于是问题都解决了?/font>
使用q些技术，我们Ex提高了系l性能。开发过E中原本g需?,000时以上才能完成的薪资计，实际q作时只?0时。一个月后我们把旉~短?8时。正式投入运转时只花12时。经q一q的q行和改善后Q全部计只需9时?/font>
我们的最大改q就是：程序放在多处理器（multi-processorQ计器上，以多U程Qmultiple threadsQ方式运行。最初这个系lƈ非按照多U程思维来设计，但由于代码有良好分解Qwell factoredQ，所以我们只׃天时间就让它得以同时q行多个U程了。现在，薪资的计只需2时?/font>
在Jim提供工具使我们得以在实际操作中量度系l性能之前Q我们也猜测q问题所在。但如果只靠猜测Q我们需要很长的旉才能试出真正的解法。真实的量测指出了一个完全不同的方向Qƈ大大加快了我们的q度?br />
]]>