3 ms·

If you're just working by yourself, then by all means use whatever you want. If you're working on a multi-developer team, or someone else might have to work on

by modoc 18y ago

If you're just working by yourself, then by all means use whatever you want. If you're working on a multi-developer team, or someone else might have to work on or try to fix your code later, please use structured objects, not Maps. The point of having named and typed member variables is that I actually know what's in there. I know that a User object has a displayName property, so I can use that. I know that the address property is actually a List of Address objects, not a string, and not a Map. And I can know this instantly using my IDE's auto-complete and tool-tips. It's also exposed via Javadoc, which means if your front-end team is writing the JSPs, they can just look at the Javadoc to know what they have access to, without bugging me every 10 seconds. Not only do I know, but the compiler knows, and can let me know if I'm trying to access something that doesn't exist, or I typo'ed the name, or if I'm trying to treat a String like a Date. If you're using a good IDE, creating the members and even getters and setters shouldn't take you much time at all, and will be well worth it in maintainability, compile-time checking, debugging, extensibility, etc...

jimbokun 18y ago
"If you're using a good IDE, creating the members and even getters and setters shouldn't take you much time at all" I don't totally disagree with what you say, but having your IDE auto-generate lots of code automatically for you gives me the heebie-jeebies. The problem is that with a language as verbose as Java, you quickly have a bajillion files filled with far more characters than it should take just to define some property names and their types. Especially considering how having a public field in an object is a Java Mortal Sin. I could go on, but Yegge has summed up the problems with generating mountains of code with an IDE, that then requires an IDE to move around, here: http://steve-yegge.blogspot.com/2007_12_01_archive.html http://steve-yegge.blogspot.com/2007_12_01_archive.html
Daniel_Newby 18y ago
"If you're working on a multi-developer team, or someone else might have to work on or try to fix your code later, please use structured objects, not Maps." Or pick a language in which the difference is an implementation detail, where an object defaults to a bag of data, but getters and setters can be transparently substituted when it becomes necessary.

by modoc 18y ago

jimbokun 18y ago

"If you're using a good IDE, creating the members and even getters and setters shouldn't take you much time at all" I don't totally disagree with what you say, but having your IDE auto-generate lots of code automatically for you gives me the heebie-jeebies. The problem is that with a language as verbose as Java, you quickly have a bajillion files filled with far more characters than it should take just to define some property names and their types. Especially considering how having a public field in an object is a Java Mortal Sin. I could go on, but Yegge has summed up the problems with generating mountains of code with an IDE, that then requires an IDE to move around, here: http://steve-yegge.blogspot.com/2007_12_01_archive.html http://steve-yegge.blogspot.com/2007_12_01_archive.html

Daniel_Newby 18y ago

"If you're working on a multi-developer team, or someone else might have to work on or try to fix your code later, please use structured objects, not Maps." Or pick a language in which the difference is an implementation detail, where an object defaults to a bag of data, but getters and setters can be transparently substituted when it becomes necessary.