Month: December 2018

Using the refactoring checklist I will attempt to improve the design of  my Desktop Snowfall project

• Can the code be Tested?  – The application is GUI based application with not a huge amount going on underneath.  Also some of this is subjective ie is the snow realistic? So it is impossible to test for. The current class diagram looks likes this:

• Do you need a seam?
  • extract methods using protected not private that use the seam.

• Create Tests

To create the tests I will need to extract the GUI from the other logic e.g generation of the snow. I started by creating an Environment package and an Environment interface that can store the environmental variables, screen size etc. This is then injected into the snowfall class. Additionally a factory pattern could be used for creating the items in the weather. Hence as weather factory interface could created and injected into the snowfall class. For future flexability objects that fall are defined by a Map held by the environment. Keys in the map are the class names of the objects and the int is the percentage occurrence in the environment.  Therefore the amount of objects created is still controlled by the user through the variable renamed from amountOfAnow to theAmountOfWeatherObjects.

I then created implementations and tests for them and I then integrated them into the design.

• Start with the deepest branch to shortest branch – Refactored
• Keep changes small and consistently retest. – Refactored
• Remove complexity – Refactored
• Methods should not have more than 10 lines of code – Refactored with a couple of instances where a method is 12 lines of code.
• Replace conditionals with strategy pattern. – Refactored – achieved with introduction of weatherObjects, WeatherFactory and Enviroment interfaces.
• Remove local variables – Refactored
• Remove comments – use descriptive method names. – Refactored
• Remove cryptic or clever code, – Refactored
• Remove abbreviated code – Refactored
• Refactor with dependency injection – Refactored used with implementing strategy pattern.
• Refactor using SOLID
  • Single Responsibility Principle (SRP)
    • All classes now have singular responsibilities
  • Open Closed Design Principle
    • Up to this point I have amended, restructured the program to fit in with design principles. One I have completed this list. I will hold to this more strictly. Which begs the question. Should it have come first or last.
  • Liskov Substitution Principle (LSP)
    • implemented with the WeatherFactory, Environment, WeatherObject and Weather classes.
  • Interface Segregation Principle
    • At present the interfaces are basic and largly singular in purpose. e.g Environment interface only for retreiving details about the weather.
  • Dependency Inversion Principle
    • Achieved by making Environment, Weather and WeatherFactory dependent on abstractions.
• Refactor using other design principles
  • Encapsulate what changes.
    • Reviewed – no further changes needed.
  • Don’t Repeat Yourself (DRY)
    • Reviewed. No further changes needed
  • Don’t look for things. Ask for things. (Dependency Injection)
    • Reviewed. No further changes needed.
  • Favor Composition over Inheritance
    • Reviewed. No further changes needed
  • Program to the Interface not to the Implementation
    • Reviewed. No further changes needed
  • Delegation Principles
    • Reviewed. No further changes needed

Now the structure of the program now looks like this:

I will update the source forge and the projects page in the coming days.