• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to peek() (and ultimately, other actions) at an Object inside a LinkList inside an Array?  RSS feed

 
Richard Warner
Greenhorn
Posts: 16
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I may be struggling simply to correctly reference (from a separate class) objects which have been built by each other.

I made an abstract class called Card and many Sub Classes of it, each with their own (nearly identical) constructors.

I made a LinkedList<Card> class called Pile, which extends LinkedList<Card> and itself has its own constructor, which populates (with randomly chosen cards) a LinkedList to a size dictated by an int parameter depth.



I made a Deck class which builds two Pile[] arrays. They are given constants which gives them a number of rows. Lines 14 through 35 are just there to give the deck a stagger effect on both ends. (I don't think that's the problem, but included just in case Note: int Flank.ROWS = 6; and int FLANK.COLS = 6; are public static final from the main class, and the constructor called here is simply fed those two as parameters where applicable (rows, cols, etc.)



When ran, various constructors from Subclasses of Card ARE being called randomly as intended; however, whether they are being catalogued correctly, I'm less confident.

The error comes in my main class (called Flank, the game's name) which asks inside a thread (a thread induced after performing these above actions):



I am expecting a card. I get "null".

Anticipating that this error may be (as before) that I'm asking for an Object and expecting a String,



returns a NullPointerException error. The Card abstract class has a method in it:



And all non-abstract Card subclasses' constructors have as their first line. Where x is their unique card name. I being shown no compiler errors (well, no red errors. Excepting a few yellow unused for future)

I at first tried this toString method being overridden by each Subclass (and there's a mess of them, lots of copy-paste) as suggested by Eclipse's mouse over F2 box thing.

Didn't work. Then tried a single, inherited method from Card class as above.

Up until now, I had been fighting NPEs like mad, but now that the program as a whole finally runs without any, I thought I had it licked. Until I went to actually test it.

I think I understand what a NPE is, but in practice... I can't seem to anticipate them. Or again, I am likely expecting something to do something it was never intended to do.

MID-POST UPDATE: obsoleted buildDeck() by moving the two separate Array definitions and calls to the main class to tidy up the Deck class having a single constructor Deck() and having Deck() look almost exactly like buildDeck() did. All functions otherwise the same, same error. I'm throwing all sorts of irrelevant Hail Marys at this thing. Now allows allyDeck[0].peek() or axisDeck[0].peek() without compiler errors (no need to type "deck.") but still shows null on syso. Not sure why I thought that would help, but it is cleaner, I guess.

Thank you folks and your brilliant minds willing to try to make heads or tails of my mess! I feel I am at a huge impasse that keeps me from gaining any ground on this game!
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your Pile class extends LinkedList but the constructor it is creating it's own LinkedList which is then lost when the constructor finishes.
 
Richard Warner
Greenhorn
Posts: 16
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh! That makes sense. THANK YOU SO MUCH! I've been fighting that for days!

For future reference for any other Greenhorns making the mistake of doublebagging and forgetting that methods go poof with everything inside them when they're done, here's how my new Pile class looks (and it works!):



Thanks again!
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Glad that solved the problem however, I would have gone for the alternate solution of removing the extends LinkedList and having an internal private LinkedList instance. Currently anyone who has access to a Pile object can use any of the LinkedList methods to add, remove, move etc cards from the pack whereas you probably only need a public shuffle and deal methods.
 
Richard Warner
Greenhorn
Posts: 16
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have some plans for add, remove, etc. From the main or probably from another class. Will the other approach you prefer allow the same, but just requires Getters and setters? I haven't programmed enough yet to really see the value in private over public. But on your advice, I'll go that other way if your foresight can save me valuable time reprogramming much later.
 
Richard Warner
Greenhorn
Posts: 16
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again, for the sake of other greenhorns, Pile class is now:



This works great, too! Thank you again, Tony!
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It not about saving programming time it's about encapsulating your data.
Having accessible methods that allow other code to alter the internal state of your object in an uncontrolled manner can lead to security issues as well as very hard to find bugs. With a deck of cards, malicious code with that level of access could for example fix the deck.
 
Richard Warner
Greenhorn
Posts: 16
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, I see. Cool!
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just seen your revised class, well done.
But (there's always a but isn't there ) your getPile and setPile methods break the encapsulation by allowing other code to access your internal LinkedList card store. you should really use a defensive copy to isolate your internal LinkedList from the outside world. So getPile should copy the internal list into a new LinkedList and return that. SetPile should clear() the existing list and use addAll() to fill it with items from the passed in list.
 
Richard Warner
Greenhorn
Posts: 16
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


This makes a lot more sense to me why to make setters and getters. Since they were doing exactly the same thing, I thought, "Well, that's goofy, one's just a private version of the other." With them actually creating isolating barriers it all suddenly makes sense. One guy making tutorials online was just letting Eclipse generate those generic placeholders, so that's what I was doing. Now, with it better, I see I've got an index out of bounds exception from my other stuff right away, which is a good thing. Thank you once again! And I came here for the "buts," of course!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!