Remove loading and saving from the Player class

[verhagen]

Separation of Concerns

Loading and saving should go to something like a PlayerRepository, similar to Item and ItemRepositry

[projectdelphai]

The problem that I'm having with stuff like this (Item vs ItemRepository) is the fact that there is a TON of abstraction and splitting up of classes. However, since progether projects are supposed to be a collaboration of multiple contributors often many who are new to coding or Java specifically, this can quickly become confusing.

So while it may be best practice, there needs to be a way to make it easier for people to understand the code if we go through with things like this. For example, there really isn't any documentation explaining why certain classes are implemented the way they are. Most things are pretty self-explanatory (monsterFactory, Items, Backpack) but for stuff like Item and ItemRepository, it can become very confusing without a proper explanation (rather than having to go through and look up all the pull requests). Also, why Repository? That work doesn't really have anything to do with loading and saving. Is that just a standard? Because a name like PlayerInit, PlayerSetup, PlayerLoad or something similar would be a lot more readable.

[verhagen]

The splitting comes from Clean Code applied. For Item the following rules could be applied

• SRP  -  Single Responsibility Principle
  every class or entity should deal with one topic solely, and do that well. What needs to be said for a given concern, should be found at a single location.
• SoC -  Separation of Concerns
  decompose functionality into orthogonal concerns. Increase focussing and cohesion within a single concern, and decrease coupling amongst separate concerns.

The below text comes from Domain Driven Design - A Step by Step Guide (part 1)

The primary purpose of a Repository is to represent itself as a collection, albeit a collection with fairly specific and advanced querying. The Repository provides a simple and powerful mechanism for making your Domain totally unaware of the actual persistence framework you are using behind it.

As a Repository is a collection, anything that uses it is completely unaware of where the Entity or Value Object may or may not have been stored.

As a learning project for others, it would be good to show / teach how things are done in the best way possible we can come up with. With that in mind, I think, we should apply Clean Code and Domain Driven Design.

Related Books

• The Clean Coder
• Domain Driven Design