考慮設計中什麼應該是可變的。這種方法與關注引起重新設計的原因剛好相反。它不是考慮什麼會迫使設計發生改變，而是考慮什麼能夠在不引起重新設計的前提下改變。這時主要關注的就是對變化的概念進行封裝，這時許多設計模式的主題。
如何在問題領域中找到不同變化，如何找到不同領域中的共同點。找到變化的地點，稱為「共性分析」，找出如何變化，稱為「變性分析」。
共性分析就是尋找一些共同的要素，它們能夠幫助我們理解系列成員的共同之處在**。可變分析揭示了系列成員之間的不同，可變性只有在給定了共性之後才有意義。
共性分析尋找的是不可能隨時間而改變的結構，而可變分析則要找到可能變化的結構。可變性分析只在相關聯的共性分析定義的上下文中才有意義。從架構的視角來看，共性分析為架構提供長效的要素，而可變分析則促進他適應實際使用所需。也就是說，如果變化是問題領域中各個特定的具體情況，共性就定義了問題領域中將這些情況聯絡起來的概念。共通的概念將用抽象類表示。可變性分析所發現的變化將通過具體類（也就是從抽象類派生而來的具有特定實現的類）實現。
共性和可變性分析、三種視角與抽象類之間的關係
共性分體與問題領域的概念視角互相關聯，可變性分析與特定情況的實現互相關聯。
規約視角處於在中間，共同點與變化點都與這個視角有關。規約描述了如何與一組概念上相似的物件溝通，這些物件的每乙個都表現出共有概念的變化情況。規約將稱為實現層次上的抽象類或介面。
在物件導向設計的新視野中，我們可以這樣說：
與抽象類的對映
討論
抽象類 —> 核心概念
抽象類代表了將所有派生類聯絡起來的核心概念，這個核心概念定義了派生類的共同點。
共同點 —> 抽象類
共同點定義了我們需要使用的抽象類
變化點 —> 抽象類的派生類
從共同點中識別出的變化點成為抽象類的派生類
規約 —> 抽象類的介面
這些類的介面對應於規約層次
將類的設計過程簡化成乙個含有兩個步驟的程式：
當你定義……
你必須問自己……
抽象類（共性）
需要用什麼介面來處理這個類的所有責任
派生類（可變性）
對於這個給定的特定的實現（這個變化），應該怎樣根據給定的規約來實現它。
規約視角和概念視角之間的關聯：規約標識了用來處理此概念所有情況（即概念視角所定義的共性）所需的介面。
規約視角和實現視角之間的關聯：對於給定的規約，怎樣實現這個特定的情況（變化點）。
Rust RefCell和內部可變性
rust在編譯階段會進行嚴格的借用規則檢查，規則如下 即在編譯階段，當有乙個不可變值時，不能可變的借用它。如下 所示 fn main 會產生編譯錯誤 error e0596 cannot borrow immutable local variable x as mutable src main.rs...
關於不可變性與可變性的「巢狀」聯想
先給出定義 先申述乙個概念 變數 引用 值 也就是 該變數初始化的記憶體 可變性與不可變性 引用可變與否，值可變與否。值的可變性取決於 值的型別是否是可變的，這取決於建立該值的類是否可變。而引用的可變性取決於 該變數命名時是否字首有 final 那麼對於乙個物件而言，其不可變性的程度 是什麼？乙個物...
支援非可變性
概念 乙個非可變性的類是乙個簡單的類，每個例項包括的資訊都是他在被建立的時候就提供出來的，並且在物件的生命週期內不是不能更改的。這樣的類如 string,biginteger等等。為什麼會有這樣的類呢？他們包含了優雅的設計思想 簡單，不可變，穩定。其實有點很提倡使用非可變類，但是不一定非要使用。下面...