溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

design pattern in ruby

發(fā)布時(shí)間:2020-04-09 18:32:25 來(lái)源:網(wǎng)絡(luò) 閱讀:594 作者:fsjoy1983 欄目:編程語(yǔ)言
 general principles, to four points:
• Separate out the things that change from those that stay the same.
• Program to an interface, not an implementation.
• Prefer composition over inheritance.
• Delegate, delegate, delegate.
following sections, we will look at each of these principles in turn, to see
what they can tell us about building software.
Separate Out the Things That Change from Those
That Stay the Same
Software engineering would be a lot easier if only things would stay the same. We
could build our classes serene in the knowledge that, once finished, they would continue to do exactly what we built them to do. Of course, things never stay the same,
not in the wider world and certainly not in software engineering. Changes in com-
puting hardware, operating systems, and compilers, combined with ongoing bug fixes and ever-migrating requirements, all take their toll.
A key goal of software engineering is to build systems that allow us to contain the
damage. In an ideal system, all changes are local: You should never have to comb
through all of the code because A changed, which required you to change B, which
triggered a change in C, which rippled all the way down to Z. So how do you achieve— or at least get closer to—that ideal system, the one where all changes are local?
You get there by separating the things that are likely to change from the things
that are likely to stay the same. If you can identify which aspects of your system design
are likely to change, you can isolate those bits from the more stable parts. When
requirements change or a bug fix comes along, you will still have to modify your code,
but perhaps, just perhaps, the changes can be confined to those walled-off, change-prone areas and the rest of your code can live on in stable peace.
But how do you effect this quarantine? How do you keep the changing parts from
infecting the stable parts?
Program to an Interface, Not an Implementation
A good start is to write code that is less tightly coupled to itself in the first place. If our
classes are to do anything significant, they need to know about each other. But what
向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI