Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialAdiv Abramson
6,919 PointsShouldn't getCurrentProgress() be coded entirely inside of the Prompter class?
Since showing the user his current progress is a feature of the presentation layer, as opposed to the logic layer, shouldn't we code getCurrentProgress() inside of the Prompter class? We can access mAnswers by referencing the instance of the game object. If mAnswers is private we could use a public getAnswer() method call on the game object or perhaps declare mAnswers to be protected or protected.
As I understand the application so far, the getCurrentProgress() method is inside the Game class and is invoked by the Prompter class. Thank you.
Nicolas Romer
2,734 PointsNicolas Romer
2,734 PointsGood question! The prompter's job is to communicate with the user, hence the display*Progress() method. The prompter *gets the user's current progress from the Game and formats it in a nice readable string. the prompter handles everything to do with the interface, which in this case is the command line. If you changed the game's interface and had to re-write the entire prompter, the game logic remains in place.
In terms of separation of concerns, it seems the Prompter should also be calling the hits and misses as part of its methods.
in Short:
Prompter does the talking
Game does the thinking.