Aunque no puede fijarse de antemano el número y tamaño de estos módulos, debe intentarse un compromiso entre ambos factores. Si nos encontramos ante un módulo con un tamaño excesivo, podremos dividir éste a su vez en partes (nuevos módulos)  más manejables, produciéndose la sucesiva división siempre desde problemas generales a problemas cada vez menos ambiciosos y, por tanto, de fácil desarrollo y seguimiento. Así, esta división toma la forma de un árbol cuya raíz es el programa principal que implementa la solución al problema que afrontamos utilizando uno o varios módulos que realizan partes de dicha solución por sí solos o invocando a su vez otros módulos que solucionan subproblemas más específicos. A esta aproximación se la denomina diseño descendente o top-down, como queda esquematizado en la siguiente figura:



Fig. 5.1. Diseño descendente.

El carácter autocontenido de los módulos o librerías hace que pueda ocultarse el funcionamiento interno de las funciones contenidas en un módulo, ya que para utilizarlas basta con saber con qué nombre y argumentos se invocan y qué tipo de valores devuelven. Al reunirlas en un módulo, se realza la relación entre las mismas separándolas del resto del programa.

Esta ocultación de los detalles se denomina encapsulación y se alcanza dividiendo el código del programa en dos ficheros diferenciados: un fichero (con extensión ".h") que incluye la declaración de los tipos de datos y de las funciones gracias a lo cual se sabe cómo acceder y utilizar cada una de las mismas y otro (con extensión ".c") que contiene el código de cada una de las funciones declaradas en el .h.

Al compilar este último queda transformado en código objeto (al cual ya no se puede acceder para su lectura o modificación) y puede distribuirse conjuntamente con el fichero de declaración (el que acaba en .h), para su uso por parte de terceros sin riesgo alguno de alteración de la funcionalidad original (ésta quedó encapsulada u oculta).

Esto es así porque para hacer uso de las funciones incluidas en el módulo únicamente necesitaremos conocer la información que nos proporciona el fichero de declaración: el nombre, tipos de datos de los argumentos y valores de retorno de las funciones. No es necesario conocer los detalles de implementación (sentencias que se ejecutan dentro de una función).

Evidentemente, desde el código que haga uso de alguna de las citadas funciones de la librería, hemos de invocar los ficheros de declaración correspondientes. Para ello, utilizaremos la directiva de C include, tal y como hacíamos para utilizar las funciones de  entrada/salida con stdio.h o las de cadenas de caracteres con strong.h, sólo que cambiaremos los símbolos < y > por dobles comillas ", por no tratarse de una librería estándar, sino creada por el propio programador y cuya ubicación, por tanto, no es la del directorio que alberga dichas librerías, en la cual el compilador busca por defecto, sino la especificada entre dobles comillas. En caso de no  especificarse ninguna ruta dentro de las dobles comillas, sería buscada en el directorio actual. Por tanto, podemos indicar que esta técnica persigue obtener una descomposición en forma de árbol que permita el fraccionamiento del programa en módulos que  resulten fáciles de entender, desarrollar, probar y mantener, y que agrupen las funciones y datos que estén estrechamente relacionadas entre sí.