Our challenge is to come up with the "ideas" for several problem domain classes that model graphic elements.

Here is a full listing of the methods that are needed for each class.

Wow, this will be a lot of methods to code!

When object coders see redundancy like this, red flags go up and whistles go off.

It puts us into generalization and reuse mode.

This is our primary (#1) listing/toolbox in terms of reuse.

Object composition simply means when one object uses another object as a component/child (like an ivar).

We browse for components that will help with our problem.

Point and Frame look like good candidates based their provide.

We go back to our diagram.

It seems that all of our elements have an "anchor point" (type "Point" from our listing).

Again, we go back to our diagram.

It seems that all of our elements also have a bounding frame (type "Frame" from our listing).

We sketch up an object diagram with our new ivars "anchor" and "boundary".

This way we can see what our object structure looks like.

The anchor point would likely be part of our basis, while the frame we might derive (compute). But those are implementation details not to be worried about now.

Thus each domain class gets the two ivars.

All of the highlighted methods can be delegated to our components "anchor" and "boundary".

Finding delegated methods is design gold 💡.

Only a few methods are not delegated.

This is our secondary (#2) listing/toolbox in terms of reuse.

We know that inheritance means when a type has a "supertype" and inherits structure and behavior from the super.

Our problem domain classes all have two common ivars.

Redundancy (duplication) of ivars tells us we should consider generalization. 💡

Our problem domain classes have a large set of common methods.

Redundancy (duplication) of methods tells us we should consider generalization. 💡

In cases like this where we have common object structure (ivars) and/or behavior (methods) we consider generalizing using inheritance.

Do our domain classes of Circle, Rectangle and Arc all conform to a more general class?

Yes it seems Shape would be a reasonable generalized class. We add it to the design and have the three classes inherit from it.

We move the common ivars up to the Shape type.

Similarily, we move the common methods up to the Shape type.

This eliminates the redundancy putting all the coding in one spot which is ideal.

Remember our first cut at our problem domain classes.

By reusing types (by composition and inheritance) our solution is extremely lightweight.

Light coding is happy coding. 💡