Welcome to the Treehouse Community
The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Adiv 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.