General Responsibility Assignment Software Patterns  通用職責分配軟件模式

模式名稱	描述（問題/解決方案)
信息專家模式Information Expert	問題：對象設計和職責分配的一般原則是什么？ 解決方案：將職責分配給擁有履行一個職責所必需信息的類－－即信息專家。（也就是將職責分配給一個類，這個類必須擁有履行這個職責所需要的信息。）
創建者模式Creator	問題：誰應該負責產生類的實例（對應于GoF設計模式系列里的“工廠模式”） 解決方案：如果符合下面的一個或多個條件，則將創建類A實例的職責分配給類B. .類B聚合類A的對象。 .類B包含類A的對象。 .類B記錄類A對象的實例。 .類B密切使用類A的對象。 .類B初始化數據并在創建類A的實例時傳遞給類A（類B是創建類A實例的一個專家)。 在以上情況下，類B是類A對象的創建者。
控制器模式 Controller	問題：誰處理一個系統事件？ 解決方案：當類代表下列一種情況時，為它分配處理系統事件消息的職責。 .代表整個系統、設備或子系統（外觀控制器）。 .代表系統事件發生的用例場景（用例或回話控制器）。
低耦合Low Coupling	問題：如何支持低依賴性以及增加重用性？ 解決方案：分配職責時使（不必要的）耦合保持為最低。
高內聚High Cohesion	問題：如何讓復雜性可管理？ 解決方案：分配職責時使內聚保持為最高。
多態模式Polymorphism	問題：當行為隨類型變化而變化時誰來負責處理這些變化？ 解決方案：當類型變化導致另一個行為或導致行為變化時，應用多態操作將行為的職責分配到引起行為變化的類型。
純虛構模式Pure Fabrication	問題：當不想破壞高內聚和低耦合的設計原則時，誰來負責處理這些變化？ 解決方案：將一組高內聚的職責分配給一個虛構的或處理方便的“行為”類，它并不是問題域中的概念，而是虛構的事務，以達到支持高內聚、低耦合和重用的目的。
中介模式Indirection	問題：如何分配職責以避免直接耦合？ 解決方案：分配職責給中間對象以協調組件或服務之間的操作，使得它們不直接耦合。
受保護變化模式Protected Variations	問題：如何分配職責給對象、子系統和系統，使得這些元素中的變化或不穩定的點不會對其他元素產生不利影響？ 解決方案：找出預計有變化或不穩定的元素，為其創建穩定的“接口”而分配職責。

• OCP(Open-Closed Principle)
  
• DIP(Dependency Inversion Principle)
  
• LSP(Liskov Substitution Principle)
• ISP(Interface Insolation Principle)
• SRP(Single Resposibility Principle)
• CARP(Composite/Aggregate Reuse Principle)
• LoD(Law Of Demeter):don't talk to stranger

以JDK中的例子略加改寫如下

How to debug a program
# Track the problem
# Reproduce the failure
# Automate and simplify
# Find infection origins
# Focus on likely origins
# Isolate the infection chain
# Correct the defect.

==Summary==

Chp1 How Failure Comes to Be

In general, a failure comes about in the four stages discussed in the following.

     1.The programmer creates a defect

     2.The defect causes an infection.

     3.The infection propagates.

     4.The infection causes a failure


     Notevery defect results in an infection, and not every infection resultsin a failure. Hence, having no failures does not imply having nodefects. This is the curse of testing, as pointed out by Dijkstra. Testing can only show the presence of defects, but never their absence.

     indeed, debugging is largely a search problem.

Chp 2 Tracking Problems

    one of the key issues of software configuration management: to be able to recreate any given configuration any time

    To separate fixes and features, use a version control system to keep fixes in branches and features in the main trunk.

    Unless you have a problem-tracking system that neatly integrates withyour test suite, I recommend keeping test outcomes separate fromproblem reports.

     problem-trackingsystems “should be usedexclusively as a place to store feedback whenyou cannot immediately modify the code.” Otherwise, you should create areproducible test case.

    Six Stages of Debugging:

     1. That can’t happen.
     2. That doesn’t happen on my machine.
     3. That shouldn’t happen.
     4. Why does that happen?
     5. Oh, I see.
     6. How did that ever work?


Chp 3 Making Program Fail

    A program can be typically decomposed into three layers:presentation layer,functionality layer,unit layer

    The rule of thumb for testing ：the friendlier an interface is to humans, the less friendly it is to automated test.

    the big advantage of testing at the functionality layers is that theresults can be easily accessed and evaluated.Of course, this requiresthe program with a clear separation between presentation andfunctionality.

    Whereas units are amongthe eldest concepts of programming, the concept of automated testing atthe unit level has seen a burst of interest only in the last few years.

    Overall, the general principle of breaking a dependence is known as the dependence inversion principle, which can be summarized as depending on abstractions rather on details.

    Test early,Test first, Test often ,Test enough

    developers are unsuited to testing their own code

Chp 4 Reproducing the problem

     Regarding problem reproduction, data as stored in files and/or databases is seldom an issue.

     To make the test reusable, one should at least aim to automate input at the higher level

    STRACE basicallyworks by diverting the calls to the operating system to wrapperfunctions that log the incoming and outgoing data.On a Linux system,all system calls use one single functionality—a specific interruptroutine that transfers control from the program to the system kernel.STRACE diverts this interrupt routine to do the logging.

    Nondeterminism introduced by thread or process schedules is among the worst problems to face in debugging.

    Some languages are more prone to Heisenbugs effect than others (inparticular, languages, where undefined behavior is part of thesemantics, such as C and C++).

    Executing on a virtual machine gives the best possibilities for recording and replaying interaction.

Chp 5 Simplifing problem

     Oncewe have reproduce a problem, we must simplify it—that is, we must findout which circumstances are not relevant for the problem and can thusbe omitted.

    Our aim is to find a minimal set of circumstances to minimize a failure-inducing configuration.

    ddmin is an instance of delta debugging—a general approach to isolate failure causes by narrowing down differences (deltas) between runs.

    Delta debugging again is an instance of adaptive testing—a series oftests in which each test depends on the results of earlier tests.

Chp 6 Scientic Debugging

     Being explicit is an important means toward understanding the problem at hand, starting with the problem statement.

     Just stating the problem in whateverway makes you rethink your assumptions—and often reveals the essential clues
to the solution.

    The idea of algorithmic debugging (also called declarative debugging) is to have a tool that guides the user along the debugging process interactively.

    algorithmic debugging works best for functional and logical programming languages

    within each iteration of the scientific method we must come up with a new hypothesis. This is the creative part of debugging: thinking about the many ways a failure could have come to be.

    Deductionis reasoning from the general to the particular. It lies at the core ofall reasoning techniques. In program analysis, deduction is used forreasoning from the program code (or other abstractions) to concrete runs
    In this book, we call any technique static analysis if it infers findings without executing the program—that is, the technique is based on deduction alone. In contrast, dynamic analysis techniques use actual executions.
    As Nethercote (2004) points out, this distinction of whether a programis executed or not may be misleading. In particular, this raises theissue of what exactly is meant by “execution.” Instead, he suggeststhat static techniques
predict approximations of a program’s future; dynamic analysis remembersapproximations of a program’s past. Because in debugging we aretypically concerned about the past, most interesting debuggingtechniques fall into
the “dynamic” categories.

    Inductionis reasoning from the particular to the general. In program analysis,induction is used to summarize multiple program runs (e.g.,a test suiteor random testing) to some abstraction that holds for all consideredprogram runs.


Chp 8 Observing Facts

    When observing state, do not interfere. Know what and when to observe, and proceed systematically.

     The"do . . . while" loop makes the macro body a single statement, forhaving code such as "if (debug) LOG(var);" work the intended way.

    Watchpoints areexpensive. Because the debugger must verify the value of the watchedexpression after each instruction, a watchpoint implies a switchbetween the debugged processes and the debugger process for eachinstruction step. This slows down program execution by a factor of1,000 or more.


Chp 9 Tracking Origins


    A common issue with observation tools(such as debuggers) is that theyexecute the program forward in time, whereas the programmer must reasonbackward in time.

    Rather than accessing the program while itis running, an omniscient debuggerfirst executes the program and records its. Once the run is complete,the omniscient debugger loads the recording and makes it available forobservation

    On average, dynamic slices are far more precise than static slices.



Chp 10 Assesrting Expectations

    The basic idea of assertions is to have the computer do the observation
   
    Overall,few techniques are as helpful for debugging as assertions, and no other technique has as many additional benefits.

    Using the GNU C runtime library (default on Linux systems), one canavoid common errors related to heap use simply by setting anenvironment variable called MALLOC_CHECK_.

    VALGRINDis built around an interpreter for x86 machinecode instructions. Itinterprets the machine instructions of the program to be debugged, andkeeps track of the used memory in so-called shadow memory.

    an assertion is not the best way of checking critical results, in that an assertion can be turned off
    an assertion is not the right way to check external conditions.

    the current trend in software development is to trade performance for runtime safety wherever possible.


Chp 11 Detecting anomalies

    code that is executed only in failing runs is more likely to contain the defect than code that is always executed.

    Anomalies are neither defects nor failure causes but can strongly correlate with either.