毫不在java中用string(或者少用)

不要使用未包裝的String or long or int. 這是爲何呢? 由於這些原始類型沒有語義含義。 他們很難理解，維護以及擴展. 我一直再宣傳這個概念 ，「Object calisthenics」 finally prompted be to write this post. 

假如如今有一個關於電影預訂的系統。

更新:若是你只是丟下一個評論告訴我你找到了反抗個人理由，好吧，只是不要這麼作。我欣賞你的意見，但坐下來，想一想和並去實踐。當你讀別人寫的代碼「String id」，你會疑惑id究竟是什麼，回來讀讀我這篇文章代碼。

.把

public void bookTicket(

  String name, 

  String firstName, 

  String film, 

  int count, 

  String cinema);

和這段比。（我所知面向對象編程）

public void bookTicket(

  Name name, 

  FirstName firstName, 

  Film film, 

  Count count, 

  Cinema cinema);

二是很是容易理解的，尤爲是當你的IDE是完成一個方法調用bookticket（String arg0，String  arg1，String  arg2，int arg3，String arg4）與bookTicket(Name arg0, FirstName arg1, Film arg2, Count arg3, Cinema arg4). 。二是更容易閱讀。

把

void book(String orderId);

和

void book(OrderId order);

對比。

在第一個例子中‘開發’者看着代碼會有兩種疑問

a.) 從哪獲取orderId 同時 b.) orderId 究竟是1212", "ABC-123"或者 "12-34-45-SCHWEINEBACKE"，這三種狀況的哪個. 在第二個例子中，他能夠搜索這個OrderId類的位置，發現關於它的使用，讀javadoc，同時知道驗證，而且應用到項目中.(譯者覺得這就是方便項目合做‘開發’)。 你可能會想 orderId 就是orderId,很容易理解。遺留系統一般不一致的更改id，命名和語義. 我見過的系統把訂單 ID 命名爲「OrderID」，「auftragsid」，「id」等其餘幾個命名，同時它們都表示同一個！

一個有語義類比String更容易理解。‘開發’者們不易陷入混亂。若是你依靠靜態類型和使用startic型語言（對象和引用）而後你最大化效益，創造更多的類。未來OrderId class很容易用long來代替int，而且仍然可使用驗證和id的生成邏輯。可是更難擴展的以字符串爲基礎的版本。

經過優雅的接口實現

類應該被實現爲一個簡單的域類，有時是不可改變的值對象，它只包字符串並將某些語義附加到字符串中。

public class Name {

   public Name(String name) {

      ...

   } 

   public static Name name(String name) {

     return new Name(name);

   }

}

人們會疑問爲何這麼麻煩。假定以下

new Customer(new FirstName("Stephan"), new Name("Schmidt"));

是否是比一個字符串語義更麻煩

new Customer("Stephan", "Schmidt");

儘管這樣，第一個例子很容易理解, 經過本地靜態方法能夠改寫成

new Customer(firstName("Stephan"), name("Schmidt"));

這也解決了許多爭論，‘開發’商從閱讀代碼不理解每一個參數的手段，尤爲是在較長的（重構參數對象！）參數列表。這是另外一種方法，以流利的界面建設者。

個人最後一篇文章是如何使用不可變對象的泛型，也能夠用值對象代替原始的。

new Point(10,10);

 new Point(x(10), y(10));

where x(10) and y(10) create Xpos and Ypos value objects.

面試 域對象與primitivs

一個我常常喜歡問的問題是關於價格搜索. 我一般給他們以下的樣子

... searchByPrice(...)

並讓面試者補全代碼。一些人會這樣寫

Vector searchByPrice(double start, double end)

which is bad code from several points of view (using double for money, no domain objects, untyped Vector).

這個是不好的代碼，從某些方面看。

Others with more domain based thinking write

其餘基於領域考慮的面試者這樣寫

List<Product> searchByPriceRange(Price start, Price end)

or even us the Range pattern by Fowler:

List<Product> searchByPriceRange(PriceRange priceToSearch)

最後的解決方案很容易擴展和理解。這個問題，每每開始於接口設計的一個有趣的討論，架構和領域建模。無論你對這個面試問題有什麼想法，不要忘記一次，對全部的人：不要使用double定義money。

謝謝大家的傾聽，不要使用String，int和long（或double定義money）。

Update:

If you find the usage of Classes instead of Strings repulsive, look at another example, zip code. Most people I’ve seen in lots of code use a primitive for zip code which creates a lot of problems when going i18n.

Customer {

   String name;

   String street;

   String city;

   String zip;

}

(some will have used int for the zip code but get faster into trouble than the String users)

instead of

Customer {

   String name;

   Address address;

} 

 

Address {

   ZipCode code;

}

Still think Strings are a good idea in your code or 「the simplest thing that could possibly work」?

你所謂的簡單，其實對別人來講不簡單。