創建類型作爲原始類型的包裝器

很多時候我們有很多實體類型的項目（Hibernate/JPA，...）。實體類型具有類似int的基本類型，long或字符串作爲ID。我們有DAO和服務來獲取並返回這些原語。創建類型作爲原始類型的包裝器

long doSomething(long blubId, long blabId, long fooId, long barId, ...)

正如你所看到的，它可以非常混亂。我想從靜態類型檢查中獲得優勢，併爲其提供類型。

long doSomething(BlubId blubId, BlabId blabId, FooId fooId, BarId barId, ...)

但是這似乎是低效的。你有什麼想法如何解決這個問題？

注意，與原語的處理有時需要在JEE上下文（JSF的bean，持久性，...）

來源

2016-03-03 kalamar

「但是這似乎效率低下 - 」在您進行數據庫調用的情況下，您認爲效率會有多高？ –

在Java中沒有特殊的方法來做到這一點。你只需要用'long'字段，一個getter和一個equals/hash/toString創建一個普通的類BlubId。它會像任何其他班級一樣工作。（其他語言有特殊的處理方式，但不是Java。） – yshavit

@JonSkeet它在內存方面效率可能很低。想象一下許多複雜對象的集合。這些複雜的對象依次具有blubId，blabId ......作爲成員。在內存方面，以ID爲基元而不是使用至少BLOCKSIZE（通常= 512b）在堆上分配內存的對象（包裝器）是一種低成本。也不要忘記GC，... – kalamar

-1

據我瞭解，你可能有興趣到尋找已經編寫的Java包裝類Java Primitive Wrapper class

來源

2016-03-03 14:53:56 n0xew

不是，重點在於'BlubId'和'BlabId'都是'long'的封裝，但是對於不同的表格。我不明白'龍'會對此有所幫助。 –

這看起來像是構建器模式的主要候選者，其中您有一個DoSomethingOptions類和DoSomethingOptionsBuilder類，它通過命名方法顯式創建選項以避免混淆參數順序。老實說，我沒有看到你的初始方法非常低效，但這取決於你調用方法的頻率以及方法的實際邏輯需要多長時間。很顯然，使用包裝來構建原語需要更多的空間和時間，但與任何實際計算相比，這幾乎是無關緊要的。

來源

2016-03-03 14:54:36

構建器對象與原始方法具有相同的問題。每個構建器方法都會使用'long'，所以你仍然可以使用錯誤的表ID – flakes

我認爲包裝原語和構建器模式的組合將是一個聰明的解決方案......只要調用' doSomething'需要足夠的時間來忽略創建一些對象的成本。 – flakes

您從構建器方法中獲得的好處是，您有一條明確的行，指出'builder.withBlubId（123）.withOtherSpecificId（234）'，它爲您提供了命名參數，因此很難將訂單搞亂。聽起來這是他首先想避免的問題。你如何看待有人誤用這個範例的錯誤tableId？ –

創建類型作爲原始類型的包裝器

回答

相關問題