Popular posts

I don't think I agree with this quote. When you design your classes, you must not think about modularity but about responsability. The modularity results from that good separation of responsabilities.

In your case, sure Cell and Piece is too much, because this is logic the Board is responsible for but I think Player deserves its own class because then, you will end up putting the code handling players management in a place it does not belong. And maybe "in the unknown future", you will want to make your game 2 players :)

Maybe it is worth to begin a topic about this to ask what the community is thinking about it !

My issue, stated in the original post, was "predictability". I wanted accounts to be flexible enough to be used globally, for multiple products.

But then, the reality of spending too much time on an unreleased product, which I honestly know will eventually have many pieces refactored with a clean slate mentality, kept reminding myself of the task at hand and the importance of seeing it as a viable way of creating something new with room for improvement, as opposed to updating something that was already pulling in revenue.

Doubling-up my code and separating important sets of logic for user accounts and profiles, that really didn't need to be outside of the User model, would have actually prevented me from helping it grow from an idea to an effective, functional prototype for something that could also become much bigger than I currently think it could be.

So I KISSed it. "Keep It Stupid Simple" - or, in my case - "Keep It Simple, Stupid". ;)