Приглашаем посетить
Паустовский (paustovskiy-lit.ru)

Chapter 8.  Designing a Good API

Previous
Table of Contents
Next

8. Designing a Good API

WHAT MAKES SOME CODE "GOOD" AND OTHER code "bad"? If a piece of code functions properly and has no bugs, isn't it good? Personally, I don't think so. Almost no code exists in a vacuum. It will live on past its original application, and any gauge of quality must take that into account.

In my definition, good code must embody qualities like the following:

  • It is easy to maintain.

  • It is easy to reuse in other contexts.

  • It has minimal external dependencies.

  • It is adaptable to new problems.

  • Its behavior is safe and predictable.

This list can be further distilled into the following three categories:

  • It must be refactorable.

  • It must be extensible.

  • It must be written defensively.

Bottom-Up Versus Top-Down Design

Design is essential in software development. The subject of software design is both broad and deep, and I can hardly scratch the surface in this chapter. Fortunately, there are a number of good texts in the field, two of which are mentioned in the "Further Reading" section at the end of this chapter.

In the broadest generality, design can be broken into two categories: top-down and bottom-up.

Bottom-up design is characterized by writing code early in the design process. Basic low-level components are identified, and implementation begins on them; they are tied together as they are completed.

Bottom-up design is tempting for a number of reasons:

  • It can be difficult to wrap yourself around an entire abstract project.

  • Because you start writing code immediately, you have quick and immediate deliverables.

  • It is easier to handle design changes because low-level components are less likely to be affected by application design alterations.

The drawback of bottom-up design is that as low-level components are integrated, their outward APIs often undergo rapid and drastic change. This means that although you get a quick start early on in the project, the end stages are cluttered with redesign.

In top-down design, the application as a whole is first broken down into subsystems, then those subsystems are broken down into components, and only when the entire system is designed are functions and classes implemented.

These are the benefits of top-down design:

  • You get solid API design early on.

  • You are assured that all the components will fit together. This often makes for less reengineering than needed in the bottom-up model.



Previous
Table of Contents
Next