This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Well, structures are something that don't exist in Java. So one answer to "when would you use a structure" would be "when you're using a language that has them" .
Exactly what it means probably varies a bit from language to language. In C, which is the main language I'd associate with structs, a struct is a type that has fields made up of other types. It's similar to a class in that respect, but it doesn't have methods or the idea of private state.
I agree , but what about the idea of actually coding a structure implementation in Java via class . Would that be feasible ? As far as the possibility is concerned , I dont think we would we able to get a 100% implementation of a strucuture in Java
Saif Asif wrote:I agree , but what about the idea of actually coding a structure implementation in Java via class . Would that be feasible ? As far as the possibility is concerned , I dont think we would we able to get a 100% implementation of a strucuture in Java
And why would you want one? A Java class is more that a struct will ever be, so why would you want an inferior construct simply because it exists in another language?
In Java you could only build it out of a class. So you're right, you couldn't get it to reside on the stack. Not changing it after creation is easy - if you want an immutable class just make the state private and don't give it mutators. I'm not sure why preventing casting would be relevant, but I'm probably missing something.
Saif Asif wrote:Well at the moment, the things coming to my mind are ...
Like Matthew, other than (possibly) being stack-based, I don't see what any of the other things buy you (and in fact most of them don't apply to C structs anyway): memory is cheap, mutability is up to you, CRUD wouldn't appear to be an issue since you don't want it to be updatable anyway, and you're not supposed to be worried about memory - that's the JVM's job. Not to mention how some of the Java keywords would apply:
for example: what would a volatile struct mean?
Saif Asif wrote:Well at the moment, the things coming to my mind are
having a light data type that resides in the stack
will not be changed after its creation
since it resides in stack , then relatively faster CRUD operations on it
1. In Java, objects (instances of classes) are always created on the heap, and not on the stack*. There is no way to create an object-like thing on the stack explicitly.
2. You can make your classes immutable, and very often it's a good idea to do so.
3. The JVM is very good at optimizing code. One of the things it does is inlining. Calling a getter or setter on an object is most of the time just as cheap as accessing the field directly.
4. There's no way you can prevent casting.
* except in special circumstances, when the JVM does escape analysis - a sophisticated optimization technique.
It sounds like you have a C++ mindset, where you're worrying about low-level optimization of your code. In Java, you normally don't need to think about these things. The JVM does a lot of sophisticated optimization for you to make your code run fast.