If I showed the former to someone who couldn’t code I think they’d be able to understand (especially with a few comments thrown in)...
You: "Read that code and tell me what you think it does"
Other: "If left pressed then you set the ship's XSpeed to negative Constants.SHIP_SPEED. If right pressed you set the ship's XSpeed to Constants.SHIP_SPEED, otherwise you set its XSpeed to 0. Ok, so negative speed means left and a positive speed means right and 0 means it's not moving at all. Ok, I understand."
You: "Ok, read this other version and see if it makes more or less sense to you."
Other: "This code just sets the ship's direction to, well, what's this shipDirection() thing?"
You: "Oh, that's a method. It returns a Direction value."
Other: "And what's a Direction value?"
You: "LEFT, RIGHT, or NONE."
Other: "Ok, so you're setting the ship's direction to whatever direction the shipDirection() method returns. Cool."
You: "So that makes sense?"
Other: "What, to set the ship's direction to LEFT, RIGHT, or NONE? Why wouldn't it make sense?"
Emma Sophia Jones wrote:
Removal of AlienEntity
It’s interesting that you suggested the removal of AlienEntity as my instinct would have been to remove AlienRow if we were cutting down on classes. ... So I guess my questions are. Is there an inherent advantage to removing classes?
AlienEntities though strike me as kind of important as they provide a graphic representation of the aliens on screen. (They also seem to be the more natural object to ask hasBeenHitBy(ShotEntity shot))
Emma Sophia Jones wrote:
Method names – I will try to adopt more of an implementation mindset with these… as you say it’s tricky but I see the advantages
Emma Sophia Jones wrote:I suppose I don’t really understand why you’d choose to get rid of AlienEntity over AlienRow.
Junilu Lacar wrote:I'll address your questions, one per reply.
Junilu Lacar wrote:
(...)A Constants class emits a code smell: the author didn't or couldn't decide to which class(es) the various values that are defined within are most closely associated. A Constants class is a cop-out at best and lazy at worst. The fact that you even have comment headers for each section of values in the Constants class screams "REFACTOR ME!" ALIENS_PER_ROW wants to be part of the AlienRow class, for example. NUM_ROWS wants to be part of the AlienBlock class.
Again, if you're going to write an OO program, you're going to have to recognize what constructs are more procedural than OO. Why would you have code external to a Ship know about a ship's speed? What you're doing when you write something like ship.setXSpeed(-Constants.SHIP_SPEED); is externalizing the logic/responsibility of determining the ship's movement. The *ship* should know how to manage its movement in an OO program. But the Constants.SHIP_SPEED makes it difficult to break away from the mindset of telling a Ship what its speed is because if Constants.SHIP_SPEED is a "good practice" then certainly ship.setXSpeed(-Constants.SHIP_SPEED); can't be that bad either, right? Well, it is if you want to write OO code.
Junilu Lacar wrote:Thanks for your comments, Piet.(...)
Hey cool! They got a blimp! But I have a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton