Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Mimicking a struct in Java

 
Nick St-Peter
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

I was wondering how can I mimick a C struct in Java so that
I could do something similar to this

aStruct = { "Hello", 1, 2.3 }, { "Hi", 2, 6.2 }, { "Thanks", 3, 7.4 } }

My problem comes from the fact that my array contains different types and I want to build it already initialized.

Any suggestion?

Thanks!

Nick
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could get close. See if this does what you want:

Probably won't compile as shown ... since everything is Object you'll have to wrap primitives with objects like Integer and cast everything back to something useful later.
 
Michael Dunn
Ranch Hand
Posts: 4632
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
another way, maybe

 
Nick St-Peter
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

Both of your suggestions work so I guess I'll have to see which one turns out to be the most suitable to do what I want to do...

I had tried to do something similar to both of your suggestions and could never get it to work...

It turns out one of my main problems was that I was forgetting to use "new" to create(instanciate?) an object when I was declaring it (actually them) in the array.

BTW, for some weird reason I was unable to cut & paste from the forum to Eclipse (it only pasted one character), weird...

Thanks for your help!

Nick
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd like to point out that variables should usually have private access. This is part of the whole encapsulation and data-hiding paradigms which are part of Object Oriented Programming. If you want more information, you should be able to use some words from this post in a google search.

Layne
 
Nick St-Peter
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

Originally posted by Layne Lund:
I'd like to point out that variables should usually have private access.


I am assuming you mean by that declaring the variables/attributes private and using getters and setters.

I guess from that standpoint the preferable solution would be to convert everything to objects and later casting them back/converting them back to their original data type (Mr James' solution).

Both solutions have their trade-off but I feel they are both better than what I am trying to avoid by using them (hardcoding and manually determining things which are best done programmaticly).

The rest of the program I am currently writing actually uses (and will probably solely use) private variables/attributes...

This is part of the whole encapsulation and data-hiding paradigms which are part of Object Oriented Programming.


This can also be done in non object oriented languages but you are right in saying that it is more the norm for object oriented languages (I've actually
used similar techniques (data-hiding, getters and setters) relativly frequently in a non object oriented language).

If you want more information, you should be able to use some words from this post in a google search.

Layne


Thanks for your input!

Nick

PS: Is there a way to preview a post before "posting" it?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW: I like Michael's answer with little objects better than my own. I'd recommend trying it to get a feel for making little classes that make the rest of the code much easier to manage. I just didn't want to go that far in one step.

If I have a little private inner class that's just mimicking a struct I don't always make the variables private and add get/set methods. But if there is any chance you'll have some behavior around those variables, think about making them private and putting the behavior in your little class so you don't even need a get.

For example, I inherited a little logging criteria object from a vendor package with code like this:

and refactored to

That's a TINY improvement, but keeps knowledge of how we match in the right place so it will be easier to maintain over time. It also removed two get methods for less code & lesss risk of misuse of the variables in the future.

Hope that helps!
 
Nick St-Peter
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

Originally posted by Stan James:
BTW: I like Michael's answer with little objects better than my own. I'd recommend trying it to get a feel for making little classes that make the rest of the code much easier to manage. I just didn't want to go that far in one step.


No problem... While I did end up using his answer I learned from yours too...

If I have a little private inner class that's just mimicking a struct I don't always make the variables private and add get/set methods. But if there is any chance you'll have some behavior around those variables, think about making them private and putting the behavior in your little class so you don't even need a get.


It serves the same purpose though (data isn't directly accessible and must be accessed through these methods though in this case it's an interpretation of it and not the data itself).

I realized after posting my reply to Mr Lund that I could at least use getters but had completly forgotten to make the variables/attributes private until I read your reply.

Hope that helps!


It sure did! Thank you very much for your help!

Nick

PS: Now if I can just get this callback function/Interface working...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic