How to better organize classes/packages in a framework so that the client of my application can easily extend them?

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

MVC/Compund Pattern

You may release earlier version of your package. later on you can upgrade it based on user requirement.

If you are using MVC or other compound pattern wisely, I believe you also can upgrade your package easily.

Answer 2

For the algorithms and strategies I would define interfaces and default implementations, and provide abstract superclasses which are extended by you own implementations, so that all the boilerplate code is in the abstract superclass. In addition I would allow the client to subclass your impl. Just make more than one impl, and you see what to place where.

But most important: Give your client the code. If he needs to understand where to place his code, he should be able to see what you have coded, too. No need to hide stuff.