Question

Let’s assume I am in charge of developing a Scrabble game, being that one of the principal requirements of the client is the ability to later try out different ways and modes of the game. I already made a design that is flexible enough to support those kinds of changes. The only question left is what to expose to the client(objects’ access modifiers), and how to organize it (how to expose my objects in namespaces/packages).

How should I define things such that the client can both easily use my standard implementation (a standard Scrabble game, and yet be able to make all the modifications that he wants? I guess what I need is a kind of framework, on which he can work on.

I organized my classes/interfaces in a non-strict layered system:

Data Types

Contains basic data types that might be used in the whole system. This package and its members can be accessed by anyone in the system. All its members are public.

Domain

Contains all the interfaces I’ve defined and that might be useful to be able to make client’s new Scrabble’s implementations. Also contains value types, like Piece, that are used in the game. All its members are public.

Implementations

Contains all the needed classes/code to implement my standard Scrabble game in a Implementations.StandardScrabble package. If the client decides to implement other variants of the game, he can create them in Implementations.XYZ, for example.
These classes are all package protected and the only thing that is available to the outside of the package is a Game façade. Uses both Domain and Data Types packages.

UI

Contains the UI class that I have implemented so that both the client and the users of the program can run the game (my implementation). Can access all the other layers.

---

There are several drawbacks to the way I am organizing things, the most obvious being that if the client wants to create its own version of the game, he will have to basically implement almost everything by himself(I share in the Domain the interfaces, but he can do almost nothing with them). I feel I should maybe pass all the Implementation’s classes to the Domain and then only have a Façade that builds up my standard Scrabble in the Implementations namespace?

How would you approach this? Is there any recomended reading on how to build this kind of programs (basically, frameworks)?

Thanks

Answer 1

I think that you’re trying to give too much freedom to a client. This must be making things that difficult for you to handle. Based on what you have described it seems that a client will be able to modify almost all parts of your game – model, logic, UI… I think it would be better to restrict modifiable areas in your application but expose some via general Plugin interface set. This would make it easier for a user as well – he will only need to learn how plugins work, not the entire application’s logic. Define areas for your plugins if you want – UI plugin, game mode plugin and so on. Many production applications and games work in such way (recall Diablo II and that AMAZING variety of plugins it has!).