Class Responsibilities

Experience. Program design is a (difficult) art, that takes a good feel for things and experience of knowing what's bad/good and why.

In general though, if you have two things that shouldn't know about one another, make a third that knows/glues both.

It sounds to me like you need to read up on Design Patterns :)

Quote:

Original post by Kronojuice The part I'm hung up on is deciding where the responsibilities should be. Should I have my input class call changes to my model, or should the model query the input class? Should the model call the graphics output, or should a third class query the model, then send that to the graphics class? Should the graphics class be sent instructions to draw 1 block at a time, or should it be sent a model of the current state, and decipher it itself?

I think I would like the input to push changes to the model, and the presentation layer can query the model to decide what to display.

Thanks for your advice. I picked up a copy of "Design Patterns Elements of Reusable Object-Oriented Software" It was a book I was planning on reading eventually anyway. Hopefully it helps.

Quote:

Original post by Kronojuice Thanks for your advice. I picked up a copy of "Design Patterns Elements of Reusable Object-Oriented Software" It was a book I was planning on reading eventually anyway. Hopefully it helps.

If you're getting lost in the complexity of the examples or the situations in which the design patterns are being applied, check out Head First Design Patterns. It doesn't cover all the patterns the GoF book does, but it provides more straight-forward examples and teaches in a more informal manner. It's worth worth a look at.

You have a program with 10-15 classes and you ask 10 programmers specifically how they should interact and you will get 10 different answers (20+ if you come back and ask them again at a later date). My general rules are; keep the data for each class in one place. Let a class change it's own data through requests of other classes. Only allow interaction through requests (ie. don't have another class force a change, only request it).

That is pretty much it. That might seem a bit over simplified, and it is, but the actual design depends on the situation. A designed that might work well for a game would be a pain in the neck for a payroll program. So the best way to learn class design is just to do it, and then redo it and then redo it again. About the time you are a well into programming what ever you are working on is when you are going to start to see how you really should have designed it. Then you have to decide to start over or leave it the way it is.

theTroll