※ 引述《tomex (tomex_ou)》之铭言： : 平心而论，.Net的Framework在布局上比Java的JSDK直觉许多，例如java的转型别写法: : int i = Integer.parseInt(string) : String s = String.valueOf(int); : 然後记诵8种不一样的java资料型别转换method名称.. @@" ?? ToChar ToByte ToDecimal ???Conver class也很多型别转换method呢:) 重点是在於primitive type非object 你也可以new Integer("3").toString(); 因为每个Object都有toString method. : 而.Net的型别都是继承自object，而object本身就拥有ToString()等内建型别 : 因此只要把 int.ToString()即可转换成字串，很直觉。 : 不过，我不会拿新架构跟旧体系来比较，因为本身并不公平， : 然後在用类别转换命名而言，.Net就提供一个统一的Convert物件， : 专门来做型别转换的工作. : int i = Convert.ToInt32(string) : string s = Convert.ToString(int) : 现在JDK 1.5出来了，增加许多功能，但在物件合名的舖陈及统一上仍不重视 : 我想主要原因是为了要能相容旧式写法， : 例如foreach语法在jdk 1.5终於支援了，却不内建在compiler里头， : 而是另用一个类别来format模拟它。绕了一些不必要的路， : 这就是java程式语言本身的历史包袱。 这边应该是说他把功能做在compiler等级 而非vm等级 外加不太懂您的意思 实际上的foreach code也只是变成 list.GetEnumerator(); 然後透过 enumerator1.Current去做事 依我透过工具decompile的结果是如上 在java的foreach中则是使用Iterator罢了. Java也有Enumeration 如:Vector.elements(); 只是sun好像都使用Iterator : .Net再怎麽贴心及创新，微软仍坚守在win32平台，因此在跨平台上仍得用java : 尽管在语法上较不直觉，但冲着「跨平台」三个字，忍了... 是为了与之前版本相容才"忍"了 跨平台只要每个os上的vm都实作的出来 那麽便不用担心呀!! 如果整个VM可以翻新 从VM去支援 那麽以前的程式都得拿回来重新compile过才行 我想JAVA暂时应该不会这麽做 外加拖越久感觉就越难实施 如果真可以大刀阔斧 何必用compiler来支援generic 害我实在很羡慕C# user 用generic可以增进效率 在JAVA却是.. : 最近，我对於物件的包装及布署有些心得，於是自己实作一个Java Bean, : 尽量让java在写法上直觉一些，例如要执行sql，一行指令就行: : obj.executeQuery(sql); : 为何我不把method的名字也取像.Net Framework里头的命名呢? : 因为method回传的型别仍是不一样，java就没有DataTable那样易用的物件 确实,没有ADO.NET这麽好用整合好的API 用jdbc也是够麻烦的 外加也只能用於资料库 ADO.NET就通吃各种东西 : 而mthod的命名常常取决回传的类别名称，so...先保留，也方便我记忆转换， : 也避免我一直记起.Net的方便性。 : 我也另实作Java物件的统一命名，例如要转换型别就用: : obj.Convert.ToInt32(string) : obj.Convert.ToString(int) : 其实它只是呼叫java既有的method而己， : sun不做这贴心事，我自己来。 : 我现在写程式，境界上不仅仅只是要完成程式功能及专案， : 甚至想重新创造语言本身的表达能力， : 所以写程式有没有趣，其实看个人想做到什麽地步而己。 确实 我在专案中也喜欢利用其他程式的API 有时在写C#看看他的原始码 哪个API好用 改写成JAVA的 反过来JAVA有的 C#找不到时 便从JAVA的class library抄 有时把API包的很general 可是非常爽的!!! 像我就偶尔看看有没有新DP,修修改改自己使用来操作Hibernate Session (.Net也有仿造的NHibernate,着名的O/R mapping工具)的API 方便自己日後使用 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.130.38.77