《古文觀止》‧卷十 ‧ 心術論 蘇洵
為將之道，當先治心。泰山崩於前而色不變，麋鹿興於左而目不瞬 ，然後可以制利害，可以待敵。
凡兵上義，不義，雖利勿動。非一動之為害，而他日將有所不可措手足也。夫惟義可以怒士，士以義怒，可與百戰。
凡戰之道，未戰養其財，將戰養其力，既戰養其氣，既勝養其心 。謹烽燧，嚴斥堠，使耕者無所顧忌，所以養其財；豐犒而優游之，所以養其力；小勝益急，小挫益厲，所以養其氣；用人不盡其所欲為，所以養其心。故士常蓄其怒，懷其欲而不盡。怒不盡則有餘勇 ，欲不盡則有餘貪。故雖并天下，而士不厭兵。此黃帝之所以七十戰而兵不殆也。不養其心，一戰而勝，不可用矣。
凡將欲智而嚴，凡士欲愚。智則不可測，嚴則不可犯，故士皆委己而聽命，夫安得不愚？夫惟士愚，而後可與之皆死。
凡兵之動，知敵之主，知敵之將，而後可與動於險。鄧艾縋兵於蜀中，非劉禪之庸，則百萬之師可以坐縛，彼固有所侮而動也。故古之賢將，能以兵嘗敵，而又以敵自嘗，故去就可以決。
凡主將之道，知理而後可以舉兵，知勢而後可以加兵，知節而後可以用兵。知理則不屈，知勢則不沮，知節則不窮。見小利不動 ，見小患不避，小利小患，不足以辱吾技也，夫然後有以支大利大患。夫惟養技而自愛者，無敵於天下。故一忍可以支百勇，一靜可以制百動。
兵有長短，敵我一也。敢問：「吾之所長，吾出而用之，彼將不與吾校；吾之所短，吾蔽而置之，彼將強與吾角。奈何？」曰：「吾之所短，吾抗而暴之，使之疑而卻；吾之所長，吾陰而養之 ，使之狎而墮其中。此用長短之術也。」
善用兵者，使之無所顧，有所恃。無所顧，則知死之不足惜；有所恃，則知不至於必敗。尺箠當猛虎，奮呼而操擊；徒手遇蜥蜴 ，變色而卻步，人之情也。知此者，可以將矣。袒裼而按劍，則烏獲不敢逼；冠冑衣甲，據兵而寢，則童子彎弓殺之矣。故善用兵者，以形固。夫能以形固，則力有餘矣。
『泰山崩於前』且『麋鹿興於左』，眼見目睹可以置若無聞，可以觸而不動，此『定功』之強，可與『言兵』矣！若夫眼耳鼻舌身意常為『外物』所『觸動』而不得定靜，『事件』川流不斷，目眩而神迷，終將淹沒於『萬象』中，不知其所止耶？
『事件驅動』會意容易，鉤深索隱困難，因為萬象駁雜隨機而發 ，所以『事件』繁亂無序自來。在此就從如何知道『發生了一件事』說起，略探『事件驅動』的基本想法，講講『中斷服務程序』 ISR interrupt service routine 的概念。維基百科『中斷處理』詞條講︰
In computer systems programming, an interrupt handler, also known as an interrupt service routine or ISR, is a callback function in microcontroller firmware, an operating system or a device driver, whose execution is triggered by the reception of an interrupt. In general, interrupts and their handlers are used to handle high-priority conditions that require the interruption of the current code the processor is executing.[1][2]
Interrupt handlers have a multitude of functions, which vary based on the reason the interrupt was generated and the speed at which the interrupt handler completes its task. For example, pressing a key on a computer keyboard,[1] or moving the mouse, triggers interrupts that call interrupt handlers which read the key, or the mouse’s position, and copy the associated information into the computer’s memory.[2]
An interrupt handler is a low-level counterpart of event handlers. These handlers are initiated by either hardware interrupts or interrupt instructions in software, and are used for servicing hardware devices and transitions between protected modes of operation such as system calls.
─── 《勇闖新世界︰ 《 KERNEL 4.X 》之整裝蓄勢‧事件驅動‧一》
從 ISR 到
事件驅動程式設計
事件驅動程式設計（英語：Event-driven programming）是一種電腦程式設計模型。這種模型的程式執行流程是由使用者的動作（如滑鼠的按鍵，鍵盤的按鍵動作）或者是由其他程式的訊息來決定的。相對於批次程式設計（batch programming）而言，程式執行的流程是由程式設計師來決定。批次的程式設計在初級程式設計教學課程上是一種方式。然而，事件驅動程式設計這種設計模型是在互動程式（Interactive program）的情況下孕育而生的。
事件驅動程式可以由任何程式語言來實作，然而使用某些語言來撰寫會比其他的語言來的簡單。有些整合開發環境（簡稱IDE）也會影響實作事件驅動程式設計的難易程度。有的 IDE 會使的開發工作變的很簡單，有的則否。
概觀
取代傳統上一次等待一個完整的指令然後再做執行的方式，事件驅動程式模型下的系統，基本上的架構是預先設計一個事件迴圈所形成的程式，這個事件迴圈程式不斷地檢查目前要處理的資訊 ，根據要處理的資訊執行一個觸發函式進行必要的處理。其中這個外部資訊可能來自一個目錄夾中的檔案，可能來自鍵盤或滑鼠的動作，或者是一個時間事件。
對一個事件驅動（event driven）系統進行程式設計，因此可以視為改寫系統預設觸發函式的行為，來符合自己需要的一種動作。輸入的事件可以放進事件迴圈或者是經由已經註冊的中斷處理器來與硬體事件互動；而許多的軟體系統使用了混和這兩種技術的處理。預先設計好的演算法確定了一件事，那就是當他們被需要的時候，就會在適當的時機被觸發。也因此提供了一個模擬中斷驅動環境（interrupt driven environment）的軟體抽象架構。事件驅動程式設計基本上包含了許多小程式片段，這些小程式片段被稱為事件處理器並且被用來回應外部的事件與分發事件。通常尚未被事件處理器處理的事件，都會被系統放在一個稱為事件佇列的資料結構中，等待被處理。
許多情況下，事件處理器可以自己觸發事件，因此也可能形成一個事件串。 事件驅動程式設計的著重於彈性以及非同步化上面，並且企圖盡可能的 modeless 。 圖形化使用者介面這類程式就是典型的事件驅動設計方式。
電腦作業系統是事件驅動程式的典型範例。在作業系統的最底層 ，中斷處理器的動作就像是硬體事件的直接處理器，搭配著 CPU 執行分配事件規則動作。對軟體處理程式而言，基本上作業系統可視為一個事件分配器，傳送資料和軟體中斷給使用者自己寫的軟體處理程式。
典範，不知幾里路遙也？
倘以
DOM events
DOM (Document Object Model) events allow event-driven programming languages like JavaScript, JScript, ECMAScript, VBScript and Java to register various event handlers or listeners on the element nodes inside a DOM tree, such as in HTML, XHTML, XUL and SVG documents.
Historically, like DOM, the event models used by various web browsers had some significant differences. This caused compatibility problems. To combat this, the event model was standardized by the World Wide Web Consortium (W3C) in DOM Level 2.
Events
HTML events
Common events
There is a huge collection of events that can be generated by most element nodes:
- Mouse events [1][2]
- Keyboard events
- HTML frame/object events
- HTML form events
- User interface events
- Mutation events (notification of any changes to the structure of a document)
- Progress events[3] (used by XMLHttpRequest, File API,[4] …)
Note that the event classification above is not exactly the same as W3C’s classification.
數量考察之，果然繁且重矣！
幸而 ipywidgets 藉著特徵小程式
/traitlets
A lightweight Traits like module https://traitlets.readthedocs.io/
Traitlets
| home | https://github.com/ipython/traitlets |
| pypi-repo | https://pypi.org/project/traitlets/ |
| docs | https://traitlets.readthedocs.io/ |
| license | Modified BSD License |
Traitlets is a pure Python library enabling:
- the enforcement of strong typing for attributes of Python objects (typed attributes are called “traits”);
- dynamically calculated default values;
- automatic validation and coercion of trait attributes when attempting a change;
- registering for receiving notifications when trait values change;
- reading configuring values from files or from command line arguments – a distinct layer on top of traitlets, so you may use traitlets without the configuration machinery.
Its implementation relies on the descriptor pattern, and it is a lightweight pure-python alternative of the traits library.
Traitlets powers the configuration system of IPython and Jupyter and the declarative API of IPython interactive widgets.
……
Using Traitlets
In short, traitlets let the user define classes that have
- Attributes (traits) with type checking and dynamically computed default values
- Traits emit change events when attributes are modified
- Traitlets perform some validation and allow coercion of new trait values on assignment. They also allow the user to define custom validation logic for attributes based on the value of other attributes.
───
將回呼函式 callback 歸納為兩種，方便以簡馭繁呦◎
※ 註
Observer pattern
The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.
It is mainly used to implement distributed event handling systems, in “event driven” software. Most modern languages such as C# have built in “event” constructs which implement the observer pattern components, for easy programming and short code.
The observer pattern is also a key part in the familiar model–view–controller (MVC) architectural pattern.[1] The observer pattern is implemented in numerous programming libraries and systems, including almost all GUI toolkits.
Overview
The Observer [2] design pattern is one of the twenty-three well-known “Gang of Four” design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.
What problems can the Observer design pattern solve?
The Observer pattern addresses the following problems:[3]
- A one-to-many dependency between objects should be defined without making the objects tightly coupled.
- It should be ensured that when one object changes state an open-ended number of dependent objects are updated automatically.
- It should be possible that one object can notify an open-ended number of other objects.
Defining a one-to-many dependency between objects by defining one object (subject) that updates the state of dependent objects directly is inflexible because it commits (tightly couples) the subject to particular dependent objects. Tightly coupled objects are hard to implement, change, test, and reuse because they refer to and know about (how to update) many different objects with different interfaces.
What solution does the Observer design pattern describe?
- Define
SubjectandObserverobjects. - so that when a subject changes state, all registered observers are notified and updated automatically.
The sole responsibility of a subject is to maintain a list of observers and to notify them of state changes by calling their update() operation.
The responsibility of observers is to register (and unregister) themselves on a subject (to get notified of state changes) and to update their state (synchronize their state with subject’s state) when they are notified.
This makes subject and observers loosely coupled. Subject and observers have no explicit knowledge of each other. Observers can be added and removed independently at run-time.
This notification-registration interaction is also known as publish-subscribe.
A sample UML class and sequence diagram for the Observer design pattern. [7]