Hi, I created a constructor for MyPiece Class and it takes only PieceType as an argument as I think that only PieceType is needed when initializing a Piece and then I am assiging other attributes with switch cases according to the PieceType. Can I do that? or will I run into problems later if I dont take all the arguments in the constructor.
While I think that having a constructor that only takes a PieceType should be possible, it might not be the smartest way to go about things.
Maybe try thinking about how and when you’ll have to use the constructor. (Hint: Remember that rotating a piece returns a new piece, and that you should be able to make a deep copy of your piece)
Also remember that Java allows you to have multiple constructors in a class, so long as they have different signatures.
yes, I’ve thought about that and I also have rotationCount parameter which determines how many times the piece has been rotated in the constructor so I can get new rotated Piece.
I had the same question in my mind; I felt like I need switch cases to differentiate which PieceType to execute. I hope thats not the thing that about the visitor pattern - when we would need to create visitor class rather than having lots of switch cases. So can we do that - constructing the type with switch cases :? Or are we expected to connect PieceTypes and objects in a different way?
Here is an educated guess about how the reference works based on the code we were given and the above comment by a tutor:
- There is a single constructor in the implementation of
Piecewhich takes body, rotation point and type as argument.
- In the factories the body, rotation point and type are hardcoded for each piece in its original rotation (i.e. the leftmost column visible on the first page of the specification).
Now it is debatable whether the factory interface is good the way it is, but since you have to live with it the above strategy is probably the easiest way to go.
One thing that you should not do is having a constructor with a case for each type AND rotation. Rotation should be handled dynamically in the appropriate methods. (i.e. you should find a formula for the coefficients and rotation point of a matrix that is rotated by 90° (counter)clockwise).
Having an internal field counting rotations is not necessary; you do not need this in the internals of
Piece and since you can only use interface methods you can not access this field in the Autoplayer.
How the reference does something is not relevant.
You should develop your code in the style that it
- fulfills the specification
- looks good
- you understand ist
- it is not too slow
- it is not too complicated
In general, when you have a method operating on some collection of types with a common super type / interface, you should not use switch cases / if cascades to operate on the instances.
Instead, use class methods and overloading&overriding.
Depending on the application, you use the visitor pattern to allow extraction of the method from the data classes to handler classes (similar to how one would do it in functional programming with the approach of inductively defined functions over algebraic datatypes).
To create objects (a random piece in this instance), however, these patterns/methods are not applicable.
A switch case might be helpful here.
Yes, the pieces have to be hardcoded in one way (for instance directly or in a high-level specification).
But the rotations are mechanically inferable from the original shape and should not be hardcoded.
- easier to make mistakes
- unreadable code
- large code snippets
- hard to maintain
- hard to refactor/change/expand
Depending on your implementations this might be a useful internal field to save memory, allow for faster equality comparison, hashing, … .