新的函數將被加入到函數庫中，新的重載將發生，於是要注意那些含糊的函數調用行為的結果；新的類將會加入繼承層次，現在的派生類將會是以後的基類，並已為此作好准備；將會編制新的應用軟件，函數將在新的運行環境下被調用，它們應該被寫得在新平台上運行正確；程序的維護人員通常不是原來編寫它們的人，因此應該被設計得易於被別人理解、維護和擴充。
這麼做的一種方法是：用C++語言自己來表達設計上的約束條件，而不是用注釋或文檔。例如，如果一個類被設計得不會被繼承，不要只是在其頭文件中加個注釋，用C++的方法來阻止繼承。
如果一個類需要其實例全部創建在堆中，不要只是對用戶說了這麼一句，用以前介紹過的方法來強迫這一點。
如果拷貝構造和賦值對一個類是沒有意義的，通過申明它們為私有來阻止這些操作。
應該判斷一個函數的含意，以及它被派生類重定義的話是否有意義。如果是有意義的，申明它為虛，即使沒有人立即重定義它。如果不是的話，申明它為非虛，並且不要在以後為了便於某人而更改；確保更改是對整個類的運行環境和類所表示的抽象是有意義的。
處理每個類的賦值和拷貝構造函數，即使“從沒人這樣做過”。他們現在沒有這麼做並不意味著他們以後不這麼做。如果這些函數是難以實現的，那麼申明它們為私有。這樣，不會有人誤調編譯器提供的默認版本而做錯事（這在默認賦值和拷貝構造函數上經常發生）。
基於最小驚訝法則：努力提供這樣的類，它們的操作和函數有自然的語法和直觀的語義。和內建數據類型的行為保持一致：拿不定主意時，仿照int來做。
要承認：只要是能被人做的，就有人這麼做（WQ：莫菲法則）。他們會拋異常；會用自己給自己賦值；在沒有賦初值前就使用對象；給對象賦了值而沒有使用；會賦過大的值、過小的值或空值。一般而言，只要能編譯通過，就有人會這麼做。所以，要使得自己的類易於被正確使用而難以誤用。要承認用戶可能犯錯誤，所以要將你的類設計得可以防止、檢測或修正這些錯誤。
努力於可移植的代碼。寫可移植的代碼並不比不可移植的代碼難太多，只有在性能極其重要時采用不可移植的結構才是可取的。即使是為特定的硬件設計的程序也經常被移植，因為這些平台在幾年內就會有一個數量級的性能提升。可移植的代碼使得你在更換平台是比較容易，擴大你的用戶基礎，吹噓支持開放平台。這也使得你賭錯了操作系統時比較容易補救。 將你的代碼設計得當需要變化時，影響是局部的。盡可能地封裝；將實現細節申明為私有。只要可能，使用無名的命名空間和文件內的靜態對象或函數。避免導致虛基類的設計，因為這種類需要每個派生類都直接初始化它－－即使是那些間接派生類。避免需要RTTI的設計，它需要if...then...else型的瀑布結構。每次，類的繼承層次變了，每組if...then...else語句都需要更新，如果你忘掉了一個，你不會從編譯器得到任何告警。
未來時態的考慮只是簡單地增加了一些額外約束：
·提供完備的類，即使某些部分現在還沒有被使用。如果有了新的需求，你不用回過頭去改它們。
·將你的接口設計得便於常見操作並防止常見錯誤。使得類容易正確使用而不易用錯。例如，阻止拷貝構造和賦值操作，如果它們對這個類沒有意義的話。防止部分賦值。
·如果沒有限制你不能通用化你的代碼，那麼通用化它。例如，如果在寫樹的遍歷算法，考慮將它通用得可以處理任何有向不循環圖。
未來時態的考慮增加了你的代碼的可重用性、可維護性、健壯性，已及在環境發生改變時易於修改。它必須與進行時態的約束條件進行取捨。太多的程序員們只關注於現在的需要，然而這麼做犧牲了其軟件的長期生存能力。是與眾不同的，是離經叛道的，在未來時態下開發程序。
