Index
Overview


Our goal is to simplify an object design as much as practical.

The steps presented are just ideas to achieve the goal.

You may decide to use similar steps, or different steps -- whatever works for you to achieve this stated goal is fine.

For some problems, we will be able to an initial design and simplify it tremendously. While in other cases, the initial design may need little or no simplification. As coding usually goes, it's case by case.


Objectives


Let us say we code 1000 lines of code when we could have coded 300 lines with a simpler design. The extra complexity causes these headaches:


The objective of this object design normalization, is to simplify the design as much as practical, to minimize the headaches listed above. And
also to design as many trivial delegated methods as possible.


What Does an Object Design Look Like?


The key pieces (deliverables) of an object design include designed object types, hierarchies, sub-components (ivars), and behaviors (methods).

Here is an example design.

How Design Normalization Fits In


Normalization is:


We will use a three step process (1NF, 2NF, and 3NF) where "NF" is "normal form" -- e.g., "1NF" = first normal form.

As previously mentioned, the important thing is not this process, but rather the goal: design simplification.

Note that our usage of the term "normalize" is relatively similar to the concept in database design.

THE BIG THREE (Design Steps)


By normalize we basically mean to simplify part of the design. We assume that extra (unnecessary) complexity is not normal.

We will use the following table as a tool to normalize an object design.

      Normalizing Object Design Table
StepNameDescriptionQuestion
1NFUse ComponentsObject behaviors should not be redundant (re-invented) if a component (ivar) could do the jobCould components (ivars) be added to provide required functionality?
2NFGeneralize ComponentsThe type of each component should be as general as practicalCould any of the component types be more general?
3NFUse InheritanceObjects with redundant components/behaviors should have a common super-type where practicalDo two or more of the designed object types have redundant components or functionality?

Notes:


Examples



Coding


See design-to-code...

Do Not Let Object Construction Limit Your Design
































Object Oriented Programming (Chapter 301 - Normalizing (Simplifying) an Object Design)










Normalizing (Simplifying) an Object Design

Chapter Examples Top Search Site Contents