question of design / structure of application and separation of concerns_问答_开发者

So this question is a sort of follow on from here (how to deal with multiple event args). That question led me onto thinking about this but is different enough to warrant its own thread.

I am creating a game (for fun and learning purpose) and would like to know if I am using good standards for design or not. I think I might have gone OTT on separation of concerns, or just got the whole thing wrong, but I am hoping that isn’t the case. I have no problem rewriting it as I want to learn “best practices” and the practical application of them.

EDIT

Let me explain a little more about the game, It is based on Jawbreaker a game found on many mobile phones (quick demo found here). Objective is to select balls that are in groups to remove them from play and score as many points as possible.

I am trying to expand it a little and have different types of boards, balls move in different ways, and different ball types, the balls may just go where they are told to, or t开发者_StackOverflowhey might do something along the way.

So Here is the structure of the objects I have created, top row shows the DLL’s with their Objects, second row shows what those objects reference:

question of design / structure of application and separation of concerns

_{(source: ggpht.com)}

Here is my attempt at doing the UML:

alt text http://yuml.me/3279d2ac

Click here to link to full page for UML, makes it a little larger and hopefully easier to read

The Objects DLL holds the basic objects used in the game, Balls and a Board. They do not contain any logic about how they act / react to situations (the ball does implement the CompareTo and the Equals methods). There could be X number of implementations of IBall (and the same for IBoard, although there will not be that many I imagine).

The InstanceManager DLL is used as a way of Creating Objects, not sure this was 100% needed it could have gone in the Objects DLL. The Factories are static classes that have various overloaded methods to create IBall objects. The BallFactory can take the BallType Enum, A Drawing.Color object, etc. The BoardFactory is very similar. Jawbreaker is a singleton object that deals with things like holding a Random Object as it is used very regularly and some GameConfiguration data, (not so relevant to this topic).

The Engine DLL is where most of the work happens. The LogicFactories take the BallType and BoardType objects to create the relevant Logic Objects. The logic objects are used to control how an IBall and IBoard object works. The BallLogic tells the ball what it can do when its events fire. For example when a Ball is selected a method is called on the Ball Logic saying Ball X on Board Y has been selected. The Ball can then do whatever its type of ball should / could do. The BoardLogic is very similar and deals with how the board acts.

The Engine Object is another singleton and is how the GUI would interact with the whole game. The GUI would not instantiate any of the other objects directly.

So to summarize the IBall and IBoard classes hold just the data about them, the Logic classes deal with all the functionality.

What I would like to know is:

1) Is this a sensible approach?

2) Should (in general) Logic be separate from the Objects / data?

3) Have I gone too far with the separation of concerns?

4) Any other comments about the design / structure

EDIT

The reason I have used a couple of singletons is partly for simplicity of accessing the data in one place without keeping hold of objects all the time and also just because it is a single game and will not be scaled to either high end or across multiple machines. I do understand that they are not great and its not something I use regularly, but appreciate the comments.

Thank you for your thoughts and feedback.

Your breakdown looks like it is going in the right direction. However I'm not sure you are trying to seperatate the data from the presentation from the logic. Take a look at the MVC, observer, and strategy patterns.

Keep this in mind: There is a tradeoff for when you are designing an application to be loosely couple. You get the ability to extend the application with less effort, however you do loose performance and memory usage. Also, I hate to say this, but don't create unnecessary interfaces. If you know you are going to extend the functionality of the object now or later on create the interface, if not think about it before you implement it.

It's hard to critique your design without a better idea of what you are trying to do. I know that it involves balls and boards, but other than that, I have no idea.

Try to avoid singletons as much as possible. Yes, I know that the GoF book lists it, and I know that it is a common pattern, but in my experience it ends up becoming an anti-pattern.

You mention that IBall and IBoard don't have any logic about how they interact. Does that imply that they don't have any methods? Are their methods just getters and setters for their private data? If IBall and IBoard are just structs (or their equivalent), then they don't need to be interfaces. Could you flesh out your description to talk about the kinds of messages that you can send to an IBall and to an IBoard?

2) Should (in general) Logic be separate from the Objects / data?

Sometimes. If you have plain old data, then separating the logic from the plain data is fine. Of course, then you're not doing OOP anymore - you are writing procedural code. I think you're struggling with the desire to not hard-code any behavior into Ball. Perhaps some other entity should be responsible for deciding how balls interact, but you still have room for Ball to participate in the decision. This is where the strategy pattern (among other patterns) would come into play. Think about how things work in the real world - how would a physical ball and a physical board coordinate their interactions? If they talked to each other, what would they say? See if you can implement that in your code.

Finally, a word about design. I think it's good to want to "get the design right." On the other hand, that's the path towards becoming an architecture astronaut. Consider what problems you currently have with your code base.

Is it hard to refactor?
Is it hard to add new types of things?
Is too much "hard-wired"?

Design doesn't exist in a vacuum - it is informed by the current state of the world. Just look at some of the crazy cell phone concept art that people come up with, and you'll see good examples of bad design. Cell phones are limited by current technology, and designs that ignore the restrictions of the real world are nothing more than dreams. The same is true in software. Pay attention to what the code is telling you it needs, and you'll do fine.

The more software you write (and finish), the more experience you will have, and the better your sense of aesthetic will become. Don't let fear of "doing it wrong" stop you from finishing your software. Persevere, make it work, and then see what you learned from the process.