這往往是情況，但這裏是最新的一個例子：你如何處理特殊情況下
公司有不同的聯繫人數據（地址，電話號碼，電子郵件......），當他們做招聘廣告，他們有複選框，他們在哪裏選擇他們想要如何聯繫。它基本上是描述性數據。用戶在閱讀廣告時看到類似「您可以通過郵件申請...」，，除了，如果它是「通過門戶網站」或「通過電子郵件」，則會出現相應的按鈕。這些選項存儲在數據庫中，客戶（網站所有者，不是製作廣告的公司）可以更改它們（例如，他們可以通過「心靈感應」或其他方式添加），但如果他們篡改「電子郵件」和「網頁門戶「選項，他們擰他們的網站。
那麼我該如何處理數據，其中一切行爲都是相同的方式，除了以這種方式行事的「這件事」之外，其他方式行爲的「事物」以及數據本身是活的都應該由客戶端編輯。
您已將您的問題標記爲「與語言無關」，並非所有語言都乾淨地支持多態，但這是我處理此問題的方式。
每個選項都有一些類型，不同的類型需要設置不同的屬性。但是，每種類型都支持某種可以根據需要顯示聯繫方式的「呈現」方法。由於屬性（電話號碼或Web地址等）是特定於類型的，因此可以在創建這些「對象」時驗證管理員的輸入，以確保提供了必要的數據並使其有效。既然你實現了渲染方法，而不是吐出用戶提供的HTML，你可以確保呈現的頁面是正確的。它不夠靈活，但更安全，更方便用戶使用。
在數據庫中，您可以擁有一個用於保存所有類型聯繫人數據的稀疏填充表，或者具有常見屬性的「父」表和具有特定於類型屬性的子表。這取決於你有多少類型以及它們有多不同。無論哪種情況，都會有某種類型的指示符，以便知道數據應該綁定到的對象的類型。
首先，三思，你真的需要它。原因很簡單。你應該服務於特定的需求和輸入數據是提供該服務的一種手段。如果數據與現有服務不符，那麼它的價值和消費者是什麼？
有兩種可能的答案：您正在擴大您的客戶羣，或者您需要更改現有服務，因爲需求發生變化。在這兩種情況下，您都需要從商業模式的發展中脫穎而出。如果你描述你需要什麼樣的服務以及它應該提供什麼信息，你將會避免很多特定的數據，並且有明確的要求可以很容易地在軟件中實現。
那麼，如果一切是是，你必須是特殊的，並且兩個選項，然後什麼都以同樣的方式被處理，然後儲存您的選項字符串，如果任一兩個特殊的人的出現在該列表，然後顯示該特殊項目的適當內容。
只需檢查兩個特殊項目的物品清單。沒有什麼花哨。
通過編寫一個非常簡單的Rules Engine。你可以使用一個開箱即用的實現，或者你可以推出你自己的。由於你的情況似乎很簡單，我傾向於自己推出，因爲它意味着更少的依賴性（YMMV）。
爲此，我建議爲resolution pattern，基於提到的數據庫。上面的鏈接描述了它，但實際上它比聽起來簡單得多。您編寫一個數據庫查詢，返回所有可能的選項（例如，您可以根據模式使用UNION或JOIN一起讀取標準選項和自定義選項） - 然後，COALESCE SQL關鍵字可用於查找第一個「分辨率「不是NULL的選項值。