xephorium / mario Goto Github PK

Hey Chris,

A couple of things caught my eye that you did really well.

Great job wrapping your pyramid logic into an object and utilizing toString. That's known as the value object pattern and it's something that you'll use all the time. Great job with that.

Also, great job using a constructor to populate the default data in your pyramid object

Although, this project's most recent refactor (pset2) did clean up the main (Mario) class and replace most unruly code with reusable method calls, I'm worried that simply creating a static Utilities class and moving tasks there doesn't take full advantage of the strategy design pattern. With such a small application, I'm having a hard time coming up with a better alternative, though. I see that in problem set 3, the instructions reference a "Printer" Interface. For simplicity, I'll go ahead and create my own Printer interface as well as corresponding strategy classes. But, even then, the Utilities class will remain with greeting and sentinel methods.

@MoMenne Is it acceptable practice to use static classes this way? If so, is there a good rule of thumb for deciding when they're becoming too bloated with random methods?