Grade-school: Structure very unclear

The intended structure of the School class is very hard to pin down. All of the add() calls are done directly on the School, but then for the first few tests, things (size, added students) are accessed through an arbitrary middle layer, db(). After the first few tests, suddenly the calls change from school.db().get({grade number}) to school.grade({grade number}).

Examples: school.add("Chelsea", 3); assertThat(school.db().get(3).size(), is(1)); assertThat(school.grade(5).size(), is(2));

If the point of the exercise is to force adherence to an arbitrary (and frankly ridiculous) structure, then I would consider it a great success.

[jtigger]

---

@colin-mullikin: I’m pretty sure we could have done without that last sentence (in your initial comment). To suppose a nonsense basis for the work is disrespectful to the person who did it, even though they are not named outright. It absolutely fine to be critical, let’s just keep it respectful, please. Thank you!

---

@FridaTveit: I like where you’re going with this. I don’t worry too much about breaking existing solutions… the value of Exercism is really in the thinking/conversation around the solutions.

Yeah, death to db()! What do you think of the idea of asserting that insertion order is maintained for grade() — this would differentiate its output from that of allStudentsInAllGradesSorted()?

Other name options for allStudentsInAllGradesSorted():

• grades() (Rust track did that)
• studentsByGradeAlphabetical()
• allStudentsByGrade()
• roster()

[matthewmorgan]

@FridaTveit @jtigger I’ve participated in some other discussions on and offline about this exercise, and there was agreement around the thought that one of the valuable points of this exercise actually lives in the “bonus” section of README.md – protecting the internal structure from mutation.

The sorting issue is some tracks and solutions was solved by sorting on insert, FYI, rather than having a method to trigger sorting on the DB or specifically to return a sorted list. Just a thought there.

Maybe outside of the scope of your proposed changes, but it would be nice to see a test for protection against mutation of the list object…again, just a thought as long as you’re tinkering. 😃