Forums Register Login

Never never never use a String in Java

2
+Pie Number of slices to send: Send
This goes out to all the experienced developers out there with a good grasp of OOP. I found the following article http://codemonkeyism.com/never-never-never-use-string-in-java-or-at-least-less-often/ and I must say the author has a very valid point.

I'm currently working on a personal project and I have Strings and ArrayList<String(s)> galore. Now it made me completely rethink my design, but what does it all look like in the real world?





+Pie Number of slices to send: Send
Interesting article, thanks for the link.

I don't know about the practicality of the approach though. Seems like it could get tedious to define types for potentially hundreds of different attributes. I immediately start thinking of base classes for StringWrapper, IntegerWrapper (redundant?), etc. Then you'll get into having to decide on overriding equals() and hashCode(), delegating built-in String methods like substr, split, contains, etc. and other things you tend to take for granted when you deal with native/standard types. I don't know if it's going to be more trouble than it's worth. The other thing too is that it's not a very common approach and you'd have to explain it to the rest of your team and leave documentation for others coming in after you to explain the design choices. Without that documentation, "WTF?!" can certainly be an understandable reaction from anyone who sees the code for the first time.

Give it a try and let us know how it works out for you.
+Pie Number of slices to send: Send
It seemed like an interesting idea to me, but then it occurred to me that if you were using an ORM like Hibernate to persist your data, it would complicate your setup quite a bit.
2
+Pie Number of slices to send: Send
It reminds me the issue with Hungarian notation. Given two data types which are technically equivalent, might be different in their usage. A String if identifies a person is of different use from a String identifying, say, a flight and it is not good to intermix them. Whether this issue should be addressed by using different types, a naming convention or meticulous care to the parameter names, depends on the very situation.

Never say "never ever" ;-)
2
+Pie Number of slices to send: Send
I thought it was “never say never again”. This sounds similar to what we have inone of our FAQ, which quotes Joshua Bloch’s Effective Java™ page 224.
+Pie Number of slices to send: Send
 

Junilu Lacar wrote:Without that documentation, "WTF?!" can certainly be an understandable reaction from anyone who sees the code for the first time.

Give it a try and let us know how it works out for you.



And the WTF is what I was afraid of. I suppose a logical balance would make sense, but then there will always be people who will question my logic. :-)
+Pie Number of slices to send: Send
 

Campbell Ritchie wrote:I thought it was “never say never again”. This sounds similar to what we have inone of our FAQ, which quotes Joshua Bloch’s Effective Java™ page 224.



Similar indeed. Stephan Schmidt seems to be religious about it though, saying "Never, never, never use (unwrapped) String or long or int. Why? Those primitive types have no semantic meaning."



2
+Pie Number of slices to send: Send
 

Paul Mrozik wrote:Those primitive types have no semantic meaning."


I think I'll stick with using well-chosen names and well-placed responsibilities to provide the necessary semantics. Life is too short to be fighting the language on the level of primitive types.
They gave me pumpkin ice cream. It was not pumpkin pie ice cream. Wiping my tongue on this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1261 times.
Similar Threads
Java Projects Book for OCJP certified people - Suggestions ?
About Getters & Setters
Value of the SCJD?
Is null check really essential for each and every object
First Classes
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 08:00:05.