我正在從事工程數據演示和管理項目。

我們的項目的性質應該是可定制的，因為我們可能有一些相似的實體，幾乎沒有多少屬性。 例如，與產品B相比，產品A具有2個其他屬性，例如productSize和productionDate，并且可能有100種不同的產品。 不同的項目或客戶可以使用任何產品，也可以定義新產品。

是否有任何設計模式可用于將所有內容視為通用類型或動態對象，以便我們沒有所有實際類型的特定實體，而只有諸如Type，BaseType，Property，Feature之類的東西。 我已經看到了諸如動態對象模型之類的一些模式，這些模式旨在解決相同的問題，但是我不確定它們是否確實在現實世界中的項目中起作用。

我們的技術是Java和Spring，以創建we應用程序和3層架構。

您的經理在技術上是否熟練？您可能應該問他們。

您的意思是，將有一個名為" Person"的類型鏈接到兩個與名為" String"的類型鏈接的屬性(分別名為" firstname"和" lastname")的" Person"類型，而不是一個具有" String"字段的Person類。 ？

與其問我們，不如回去找老板澄清一下可能更有意義。

從未聽說過inheritance嗎？

這聽起來像是IMO的一個壞設計想法。

您還沒有聽說過通用數據庫設計嗎？他們試圖使設計盡可能簡單，以便在您想要在系統中添加新功能時不需要添加更多數據庫表或實體。現在，我需要專業的意見或指導。特別是關于應用程序層。當然他不是程序員，但他聽過一些話，他是我的老板！你懂 ：(

也許您可以將所有對象作為XML存儲在數據庫中。有多種工具可用于將對象與XML序列化和反序列化。或者，您可以使用JSON。

@ j.con是什么意思？

我不同意那些將其定為"過于廣泛"的投票。這是一個有關設計模式(或反模式)的問題，@ Kayaman提供了一個很好的答案。我可能看到一個論點，也許它應該屬于程序員而不是這里。

也許我在這里沒有大圖，但是如果他不想使用20-30個不同的類，而想要5或6個泛型類，那就是abstract類與Class< T >一起起作用的地方。閱讀Generic Types docs.oracle.com/javase/tutorial/java/generics/types.html

@SotiriosDelimanolis，不，他不是軟件工程師，但他是一名優秀的工程師，他以這種方式在自己的腦海中對問題進行了建模。實際上看起來不錯，但正如Kayaman所說，這是一種反模式，在大多數情況下應避免使用。

這是一個令人驚訝的普遍現象，并且是一個非常糟糕的主意。 聽起來您正朝著Inner Platform反模式邁進。

初次聽到(或如果您是經理)似乎很不錯，但是結果是一個系統試圖嘗試做所有事情，但最終做不到任何事情。

數據庫變得非常低效，并且容易損壞。 我很不幸看到了這個動作。

感謝Kayaman，這就是他認為這種設計類型會有所幫助的原因，我們可以做我們想做的任何事情。但是我如何證明它不起作用？我從未聽說過并嘗試過類似的方法，但我不想在沒有任何理由的情況下拒絕。我對應用程序層的劣勢更感興趣。

@sina首先向他展示該維基百科頁面。警告他有關維護和性能以及開發困難的問題。

但是我也發現它是一種設計模式"動態對象模型"，這是它的鏈接。鏈接

@sina是的，那么您可以向他展示該論文的"缺點"部分。但它是您的選擇，也許會適合您，也許您就正確了。也許幾年后，您會想到"該死的，Kayaman角色肯定是多么可怕"。無論如何，我建議您即使對這種模式也必須保持謹慎。有優點也有缺點。我只看到了缺點。

@sina那么，它如何結束？ :)

我避免使用"動態對象模型"或任何被稱為"動態對象模型"的東西，而是基于常規模式實現了整個軟件。但是我做到了如此靈活，它的用戶可以定義和更改系統屬性和類型。例如，我有諸如Property，Value，Type之類的實體……也許接近于共享點的想法

例如，用戶沒有定義一個稱為制造商的實體，而是在系統中創建它(創建新的屬性表單)，并將之前創建的屬性分配給該表單，并為每個屬性設置初始值，依此類推。

總結

以上是生活随笔為你收集整理的java动态定义泛型_关于oop：具有动态性质且可完全自定义的Java泛型编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。