• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

immutable stack implementation

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi.. I am trying to work on some exercises that I found that seem to be pretty good for learning some interesting things about Java. The one I am on now is to implement an immutable Stack. I wanted to see if you can critique my implementation and let me know what I could do better or correct if it is wrong. Here is what I have so far. The original implementation was from Bloch's book. The method repOk is supposed to be used for the jUnit tests I have written. I have those written too now to test each method and they pass the tests but I want more feedback if possible, please.

Thanks!

 
Bartender
Posts: 15741
368
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jerry, here are a few things to consider.

- Your class is not generic. It would be far more useful if you parameterized it, so your client can push and pop objects of a specific type.
- Why should it be illegal to add null elements to a stack?
- Your Stack(Object, Object[]) constructor is incredibly inefficient. You are creating a new array for every element in the given object array, and copying all the elements. Why not just create the new array in one go?
- If the array argument contains null elements and you want to disallow them (again, I don't understand why), you can just throw an exception upon discovery of the first null element.
- Even if you don't want to throw an exception, you can just count the number of null objects in the given array first, and then still create the new array in one go.
- Why are the semantics of the Stack(Object[]) constructor so different from the former?
- Your isEmpty() method uses a lot of redundant code. Just return size == 0, or Campbell will eat you.
- I'm all for clarity and using lots of variables and all, but why not just have your top() method return elements[size -1]?
- Don't use StringBuffer, use StringBuilder.

Now I know this is an exercise, but consider how useful such a class would be. It would probably only be useful for defensive copying if you want to return a stack field from a method in another class, in which case you might as well return Collections.unmodifiableCollection(myStack), where myStack is an instance of the Deque interface. It's also very inefficient, because it achieves its immutability through lots of copying. To make it more efficient, you could consider letting all the instances that are derived from the same stack (through push and pop operations) share the same array. They can just keep some index fields around to tell them which part of the array is valid for them.
 
Jerry Oreganini
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your time and great advice. I will work on incorporating all of what you have said and post an updated one for further inspection.
 
Jerry Oreganini
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok so it seems like maybe I was going overboard with this idea of copying the objects around to keep a client of the class from adding mutable objects to the stack and changing them after the fact. I thought that is a big concern here, no? Does this implementation still avoid that issue, i.e. a client adds date references to the immutable stack and changes them after they have been pushed?

Other than that, I think I incorporated everything you indicated. Does this look better?

Thanks again!

 
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If someone wants to add mutable objects to the stack and change them later, there's absolutely nothing you can do about it. Your previous implementation wouldn't help there either, because you're never actually copying objects, just references. All you can do is make sure the stack itself is immutable.
 
Jerry Oreganini
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, it all makes good sense now! I agree the usefulness of this is near zero but it has taught me a lot about what an immutable object can and can't do and how it should behave and look in the end. Your replies were very helpful.
 
Stephan van Hulst
Bartender
Posts: 15741
368
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm glad you figured things out for yourself

For comparison:
Normally I would use an ArrayDeque though.
 
reply
    Bookmark Topic Watch Topic
  • New Topic