This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Beginning Java and the fly likes General opinion on placing an array Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "General opinion on placing an array" Watch "General opinion on placing an array" New topic
Author

General opinion on placing an array

wayne morton
Greenhorn

Joined: May 17, 2012
Posts: 28
This is more a question on best practice than a problem i have.

Say for example that i have a list...

3 classes are going to use that exact same list of data.

If that list of data changes it will change for all 3 classes.

If i make that list into an array, previously i have been told that if a class uses an array then the array should be in that class to help prevent unintended issues if i need to change that array and to prevent the Russian Doll effect, which is logical.

But in this case i have 3 classes that will be using exactly the same array and if it changes in any way it will change in exactly the same way for all 3 classes. (for clarification it will be me making a change to the programme rather than it changing during the programme itself)
So i thought of having a single array that i only need to change once if needs be rather than 3 separate arrays i need to change individually if a change is needed. It also reduces the scope for problems in the sense that having to change 3 separate files increases the chance of making a mistake in one of them if i ever did have to change the data.
To me that is reducing my possible workload if a change is needed but goes against that ethos of encapsulated data with the logic that uses it and to a certain degree the re-usability of the class if it was usable in another programme.

Is one way better than the other or does it depend on the situation?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38472
    
  23
wayne morton wrote: . . . 3 classes are going to use that exact same list of data.

If that list of data changes it will change for all 3 classes. . . .
That looks dubious. You are setting up global values and allowing them to change. That is error‑prone.

Consider an unmodifiable list.Now, you can try that unmodifiable list in your three classes, before and after calling that addAnotherName method.

That might help, but still: beware of global variables.
wayne morton
Greenhorn

Joined: May 17, 2012
Posts: 28
I already did that as i don't want or need the values to change in any way. The array that is exported is effectively a copy (or clone, still getting to grips with terminology but it is it's own entity) of the original array so the original array never changes.

I probably should have said this originally and will update my original post to say it. If it changes in any way it will be hard programming it, not having it change while the programme is running.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

wayne morton wrote:But in this case i have 3 classes that will be using exactly the same array and if it changes in any way it will change in exactly the same way for all 3 classes. So i thought of having a single array that i only need to change once if needs be rather than 3 separate arrays i need to change individually if a change is needed. It also reduces the scope for problems in the sense that having to change 3 separate files increases the chance of making a mistake in one of them if i ever did have to change the data.
To me that is reducing my possible workload if a change is needed but goes against that ethos of encapsulated data with the logic that uses it and to a certain degree the re-usability of the class if it was usable in another programme.

Actually the problem is more likely to arise if these 3 classes need to access the array in a multi-threaded environment.

Simply put: there is no easy way to synchronize access to an array. Sure, you can lock on the entire array itself; but unless ALL access (reads AND writes) is synchronized, there is no way to prevent possible corruption (as far as I know) and you must do it explicitly. A synchronized List on the other hand guarantees atomicity of reads and writes, but it'll act like a List, not an array. Then there is AtomicReferenceArray, of course.

Providing your 3 classes are all in the same package, you don't have to break encapsulation. Simply specify one of the classes as the array "holder" and have it provide a package-private getter for it. Alternatively, specify a separate "ArrayHolder" class (in the same package) and have each class contain its own reference to it; but if you're doing that, you might as well simply make it a package-private extension of AtomicReferenceArray. That way you have the "multi-threaded" issue covered as well.

HIH

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

wayne morton wrote:I already did that as i don't want or need the values to change in any way. The array that is exported is effectively a copy (or clone, still getting to grips with terminology but it is it's own entity) of the original array so the original array never changes.

I probably should have said this originally and will update my original post to say it. If it changes in any way it will be hard programming it not having it change while the programme is running.

Ah, well that's very different then. If you only need to read, then forget what I said and take Campbell's advice.

Winston
wayne morton
Greenhorn

Joined: May 17, 2012
Posts: 28
Thanks for your replies.

So by the sound of it, weather to have the array in the logic class or to have it separate depends on the situation. In this case it is fine to have a separate array class but in other situations it is better to have the array in the logic class.

In a way it probably seems obvious but i don't want to get into a way of thinking/doing things only to find out further along that i am doing it wrong. For this particular case it seemed logical to have a separate array class but going on previous information i was concerned i may have been digging myself a hole for later because i didn't know about the bigger picture.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

Wayne, the implementations may vary from one situation to another but the principle pretty much stays the same: it's best to keep things encapsulated and have one place where you're managing the data. It looks like you've already grasped the principles of encapsulation and DRY (Don't Repeat Yourself, that is, eliminate duplication) so that's a good sign that you're making progress. Don't be afraid to make mistakes: everyone does and that's just part of learning. Just stick to the principles and you shouldn't be very far away from a good solution, even if your first few tries are a little off. Good luck.


Junilu - [How to Ask Questions] [How to Answer Questions]
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

wayne morton wrote:In a way it probably seems obvious but i don't want to get into a way of thinking/doing things only to find out further along that i am doing it wrong. For this particular case it seemed logical to have a separate array class but going on previous information i was concerned i may have been digging myself a hole for later because i didn't know about the bigger picture.

The only thing you need to be careful of with arrays is that they are inherently mutable - and furthermore publically mutable - so any code that can "see" an array can update it. That's why I suggested a package-private getter: that way only classes in the same package as the holder can actually get the array to update it.

One other point to remember: Depending on how you initialise the array, you need to be careful to protect its contents for all the reasons above. So if, for example you supply the array via a constructor, then that constructor should store a copy of the array; otherwise some nefarious no-gooder could simply keep the array that he passed to your constructor, and update that.

You might want to Google 'defensive copying'.

Winston
 
 
subject: General opinion on placing an array