Skip to main content
Game Development

Return to Answer

added 322 characters in body
Source Link
Antares
Antares
  • 148
  • 5

Strictly speaking you did not optimize the code, you restructured it. You have performed a refactoring (but probably without tests).

There is a principle of locality inherent in object oriented programming. Meaning, functionality that belongs to an object should be kept at the object. Having a render method in each class is nothing to be condemned per se. There is even a design pattern for it, the command pattern.

In the presented case you collected all render stuff in one extra layer or compartmentpackage/namespace, but the control flow dependency is still there between each Pac and PacRenderer, Fruit and FruitRenderer etc. Note the reference you have to pipe to each renderer to make this approach work. If you truly had abstracted/separated things, such a dependency would not be present anymore.

The underlying idea is that changes on the object probably make changes of the rendering necessary. So the best/simplest case is, object logic and render code are held together. Similar parts could be moved to a common parent class (or static helper classes), if this makes things easier to handle.

Don't worry tho, these are all best practices coming with more experience. Just keep going. You did the best thing here: Trying to change code and learn something from it is the best teacher you can have!

Strictly speaking you did not optimize the code, you restructured it. You have performed a refactoring (but probably without tests).

There is a principle of locality inherent in object oriented programming. Meaning, functionality that belongs to an object should be kept at the object. Having a render method in each class is nothing to be condemned per se. There is even a design pattern for it, the command pattern.

In the presented case you collected all render stuff in one extra layer or compartment. The underlying idea is that changes on the object probably make changes of the rendering necessary. So the best case is, object logic and render code are held together. Similar parts could be moved to a common parent class, if this makes things easier to handle.

Don't worry, these are all best practices coming with more experience. Just keep going. Trying to change code and learn something from it is the best teacher you can have!

Strictly speaking you did not optimize the code, you restructured it. You have performed a refactoring (but probably without tests).

There is a principle of locality inherent in object oriented programming. Meaning, functionality that belongs to an object should be kept at the object. Having a render method in each class is nothing to be condemned per se. There is even a design pattern for it, the command pattern.

In the presented case you collected all render stuff in one extra layer or package/namespace, but the control flow dependency is still there between each Pac and PacRenderer, Fruit and FruitRenderer etc. Note the reference you have to pipe to each renderer to make this approach work. If you truly had abstracted/separated things, such a dependency would not be present anymore.

The underlying idea is that changes on the object probably make changes of the rendering necessary. So the best/simplest case is, object logic and render code are held together. Similar parts could be moved to a common parent class (or static helper classes), if this makes things easier to handle.

Don't worry tho, these are all best practices coming with more experience. Just keep going. You did the best thing here: Trying to change code and learn something from it is the best teacher you can have!

Source Link
Antares
Antares
  • 148
  • 5

Strictly speaking you did not optimize the code, you restructured it. You have performed a refactoring (but probably without tests).

There is a principle of locality inherent in object oriented programming. Meaning, functionality that belongs to an object should be kept at the object. Having a render method in each class is nothing to be condemned per se. There is even a design pattern for it, the command pattern.

In the presented case you collected all render stuff in one extra layer or compartment. The underlying idea is that changes on the object probably make changes of the rendering necessary. So the best case is, object logic and render code are held together. Similar parts could be moved to a common parent class, if this makes things easier to handle.

Don't worry, these are all best practices coming with more experience. Just keep going. Trying to change code and learn something from it is the best teacher you can have!