Lots of "instanceof" checks
JohnathonNow opened this issue · comments
These should be refactored. Perhaps each entity could have a method for handling collisions with the player and doing the right thing afterwards.
Bending/src/destruct/APPLET.java
Lines 1413 to 1670 in 1d9f355
I can work on this, give me 2 days to run the game and get an idea of the code base, and I can come up with a plan to refactor this part based on best practices.
If the plan sounds fine to you, I can make the PR post discussion.
Can you assign this to me?
Thanks, for assigning this to me.
I have taken a look at the code and as you suggested, we can have an abstract method in Entity.java and we could make each entity handle this.
One thing to double check is exactly what can be modified by each Entity. i.e what needs to be passed and what needs to be returned and set. So far speed variables and world values seem to be changing. But I will take a deeper look to see if anything else needs to be modified and design the return Class accordingly.
Would a mediator pattern be more appropriate here?
I had thought of using an interface (Mediator) to deal with Collisions. But every Entity logically would need to handle collisions and making each entity implement the interface, might lead to a lot more work for no particular reason. Ref
One benefit of the Mediator (As I understand it, let me know if I misunderstood it) would be to slightly decouple the Client.java from the Entity. but the Client.java would still need to be passed in the mediator, so I don't know how much benefit this would yield.
Yeah that is the benefit - not that what you have here isnt fine. The mediator would let the collision logic live outside of the entities themselves, so neither they nor the client would never have to know or care about what is happening during the collision, they would just have their properties updated.
I'm not sure, how the mediator pattern would be implemented here.
Say we have a MediatorClass
public class MediatorClass {
Client client;
Entity entity;
//constructor, this would need to be constructed for each different entity in the entityList?
//methods, this would be called by the entity in WaterEntity::handleCollision { mediator.handleCollisionWithWaterEntity() }
handleCollisionWithWaterEntity() {
//update client
//update entity
}
// wouldn't we need to create a method for each different type of entity?
// and there is also possibility of accidental misuse. i.e an entity caling the wrong collision handling method.
// and I'm not sure how this would work on the Client side either
This rough implementation is based on what's suggested here. Ref.
Do you have any idea on how this could be implemented better?
So, my recommendation would be:
in the entitiy classes, store the changes that need to happen in the class itself (make them in the base entity class). Then, the mediator can be agnostic to the specific changes that need to happen. eg:
changeinxspeed
changeinworldx
etc.
If there is more specific logic required, you can make it a virtual funciton on the entity class and implement it in the children, eg. virtual void SetWorldX(int startingx)