Separated Interface

Defines an interface in a separate package from its implementation.

1. You can put interfaces in the same package as that of the client.

2. Or put interfaces in a third package.

Now, how does the client instantiate the implementation as this would require knowledge of the implementation class. There are two approaches for this

1. Use a separate factory object, where again there is a separated interface for the factory. And to bind an implementation to the factory, Plugin can be used.

2. Let yet another package that knows both the interface and implementation and it instantiates the right objects at startup.

Model View Controller

Most of the applications get data from a data store and display it to the user. And if the user changes the data, the data store is updated.



UI <--> Data



Problem



If Data and UI are coupled,



1. UI changes more frequently than the data stored in the system.

2. Business logic gets in UI



Model is an object that represents some information about the domain. It's a nonvisual object containing all the data and behavior other than that used for the UI.



The view represents the display of the model in the UI. The view is only about display of information; any changes to the information are handled by the controller. The controller takes user input, manipulates the model, and causes the view to update appropriately. In this way UI is a combination of the view and the controller.



There occurs two separations



1. Presentation from model



Besides other advantages, it allows for easy testing of domain logic.



Principle : The presentation depends on the model but the model doesn't depend on the presentation.



This principle introduces a common issue. With a rich-client interface of multiple windows it's likely that there will be several presentations of a model on a screen at once. If a user makes a change to the model from one presentation, the others need to change as well. To do this without creating a dependency you usually need an implementation of the Observer pattern. The presentation acts as the observer of the model.



2. View from controller



Separation required to support editable and noneditable behavior, which you can do with one view and two controllers for the two cases, where the controllers are strategies for the view. In practice most systems have only one controller per view, however, so this separation is usually not done.

API Design Guidelines - Progressive APIs

What are progressive APIs ?

1. Low barrier to entry (and get progressively difficult)
2. Powerful
3. Consistent

API Design Principles

1. Scenario-Driven Design
a. Define top scenarios.
b. Write code samples, design API later.
c. Make top scenarios easy, make the rest possible.
d. Usability test top scenarios. (Preferably other language)

2. Support Experimentation
a. Obvious entry points
A good way to indicate entry point is to use domain correspondence.
b. Minimal initialization, sensible defaults
c. Usage of properties
d. Immediate feedback (exception)

3. Aggregate Component
a. Create, set and call usage pattern
b. They build on the factored types

4. Self-Documenting APIs
a. Consistency
If you learn one part, you can know the other part
b. Progressive documentation
It has to start with simple scenario and then go to advanced concepts.


5. Keep things simple
a. Number of objects - less objects should be required to setup.
b. OO design methodologies is not meant for API design.

API Design Guidelines - Designing Inheritance Hierarchies

1. Prefer broad, shallow hierarchies
a. Less than or equal to two additional levels = rough rule !
b. Contracts and responsibilities are difficult to maintain and explain in deep hierarchies

2. Consider making base classes not constructible (use abstract class)
a. Make it clear what the class is for
b. Provide a protected constructor for subclasses to call

3. By default, everything should be non-virtual.
a. There is the danger and power of virtual methods
i. Danger : Owner of base classes cannot control what subclasses do
ii. Power : Base class don't have to change as new subclasses are created
b. Always consider LSP

4. Use abstract members only where it is absolutely required
a. There is more chance of introducing bugs.

5. Interface vs. Base Classes
a. Its easy to add members to base classes but not to interface. You have to create a new interface version.