wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes OO Design for Deck class (Card holder) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "OO Design for Deck class (Card holder)" Watch "OO Design for Deck class (Card holder)" New topic
Author

OO Design for Deck class (Card holder)

Faz Ali
Greenhorn

Joined: Dec 02, 2010
Posts: 21
Hi All,

I've decided to go over some old code I wrote to make it a lot more OO friendly but am having trouble with two classes in particular which are extremely similar but also quite different:



The problem I have is that PlayingDeck is the standard deck we all know and love when playing card games such as Poker etc. ShreddedDeck is a deck which will be populated with cards which have been discarded from the PlayingDeck. That is why the implementation of the addCard() and removeCard() is different, the constructor is also different between these classes. Nevertheless, these classes are quite similar so should I add/is there scope for say an interface or an abstract class somewhere?
I was thinking about a Deck Interface with the methods add(), remove(), size() but decks are also shuffled but the shreddedDeck() should never be shuffled.
Any advice/input would be welcome.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187

Faz Ali
Greenhorn

Joined: Dec 02, 2010
Posts: 21
Jimmy Clark wrote:


This is a similar design I came up with but the problem is the shuffle() method which is not something that a ShreddedPlayingCardDeck should have therefore should not be a part of its API which it will be when implementing that interface.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
The ShreddedPlayingCardDeckImpl would not have an implementation for a shuffle() method. There are numerous ways to code shuffle() to prevent it from operating in specific conditions. There are many factors to take into consideration when designing an OO application and many decisions have to be made, big ones and trivial ones.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OO Design for Deck class (Card holder)
 
Similar Threads
Encapsulation seems to make inheritance counter productive in this example?
Constructor problem.
can't split card shuffle method into a separate class
newbie help please with arrays
Need help with constructor and fields