Introducción

En este documento intento plasmar un poco mi experiencia a la hora de tratar con bases de datos. Se que está muy de moda usar herramientas que automatizan la conexión y hacen gran parte del trabajo por nosotros. Sin embargo ésta es una de las cosas que prefiero hacer por mi cuenta, ya que he visto fracasar bastantes proyectos debido a una mala gestión de la base de datos.

Ojo, no me considero un experto sobre el tema, de hecho, mi preparación es ingeniero de telecomunicaciones y en la carrera he visto tanta teoría sobre bases de datos como la que pueden dar unos niños en la guardería.

Se aceptan críticas constructivas, comentarios, anotaciones, mejoras... en fín, lo de siempre.

Como también se pone de moda esto de las licencias, este código se presenta tal cual, sin garantía de ningún tipo. Sois libres de copiar y/o modificar el código a vuestro antojo, sin embargo declino toda responsabilidad que su mal uso pueda conllevar. También sois libres de coger el código y guardarlo en algún rincón oscuro como vuestro tesoro o usarlo para hechizos y brujería, eso si, siempre bajo vuestra responsabilidad.

Nota adicional: No puedo garantizar que el código esté 100% libre de errores, ya que la mayor parte de los ejemplos no son ejecutables y los he tenido que ir retocando (con cuidado, eso sí) para adaptarlos a la guía. Aún así, me parece importante recalcar que el código está escrito bajo el estándar C++11, así que cuidado con usar compiladores no compatibles.

Bueno, dicha la parte aburrida vamos al tema. Antes o después, todo el que se dedica al mundo de la programación, ya sea por hobby o profesionalmente, acaba haciendo uso de bases de datos. Esto suele ser debido a que tenemos la mala costumbre de querer guardar todo tipo de información... con lo divertido que es reescribir los documentos una y otra vez.

Debido a que no suele ser demasiado eficiente eso de resetear la base de datos y rellenarla de nuevo cada vez que queremos almacenar algún cambio, lo lógico es que nos veamos obligados a guardar determinada información sobre los objetos que se encuentran en la base de datos:

• Necesitamos saber si el objeto es nuevo o no (no es lo mismo CREATE que UPDATE).
• Necesitamos saber si el objeto ha sido modificado. Si no lo hacemos tendremos que actualizar TODOS, con el tiempo que ello pueda conllevar.
• En el caso de tablas con campo autoincremental, necesitamos almacenar dicho OID para futuras consultas.

La primera aproximación que yo creo que hemos hecho todos es meter toda esta información a piñón en el propio objeto. Algo del tipo:

class User
{
  public:
 
    // Interfaz para la base de datos
 
    // Devuelve el OID ( en el caso de objetos nuevos vale 0 )
    int OID( ) const;
 
    // Permite modificar el OID
    void SetOID( int oid );
 
    // Indica si el objeto es nuevo (no esta aun en la BD )
    bool IsNew( ) const;
 
    // Indica si el objeto ha sido modificado
    bool IsModified( ) const;
 
    // Reinicia los flags 'IsNew' e 'IsModified'
    void ObjectSaved( );
 
    // Interfaz propia del objeto
 
    std::string Name( ) const;
 
    std::string Surname( ) const;
 
    // ...
};

Como queda patente de un primer vistazo, esta solución no parece demasiado elegante. Estamos introduciendo acoplamiento al introducir en la interfaz elementos propios de la gestión de la base de datos. Además, este diseño plantea otros problemas:

• Si se usan plugins, exponemos información sensible de la base de datos a terceros.
• Si nuestra aplicación trabaja en red nos obliga a enviar información innecesaria en el lado del cliente.

El diseño, al fin y al cabo, es feo, ya puestos, también podemos poner en 'User' los métodos para leer y escribir en la base de datos, un par de métodos también para poder almacenar la información en un fichero y, si nos quedan más ganas de marcha, también podemos meter en la clase el código que gestione la interfaz gráfica...(espero que se entienda la ironía).

Después de un rato pensando, a alguien podría decir... "bueno, creo una clase base que tenga los datos de la BD y soluciono el problema con herencia:

class DBItem
{
  public:
 
    // Interfaz para la base de datos
 
    // Devuelve el OID ( en el caso de objetos nuevos vale 0 )
    int OID( ) const;
 
    // Permite modificar el OID
    void SetOID( int oid );
 
    // Indica si el objeto es nuevo (no esta aun en la BD )
    bool IsNew( ) const;
 
    // Indica si el objeto ha sido modificado
    bool IsModified( ) const;
 
    // Reinicia los flags 'IsNew' e 'IsModified'
    void ObjectSaved( );
};
 
class User : public DBItem
{
  public:
 
    // Interfaz propia del objeto
 
    std::string Name( ) const;
 
    std::string Surname( ) const;
 
    // ...
};

No voy a negarlo, es una posible solución, aunque este diseño sigue teniendo los mismos problemas de acoplamiento que el diseño anterior. La ventaja, eso sí, es que podremos reutilizar código de 'DBItem', no iban a ser todo malas noticias. Sin embargo, como comentaba, este diseño sigue sin convencer.

La idea entonces parece que pasa por separar físicamente la información relativa a la base de datos de los datos propios del objeto. El problema que aparece entonces es cómo conseguir esto de la forma más limpia posible, intentando además que sea reutilizable. Los requisitos que ha de cumplir este sistema son los siguientes:

• Debe ser posible separar la lógica de negocio de la capa de acceso a datos.
• Debe permitir la gestión de elementos eliminados.
• Debe ser capaz de detectar elementos nuevos y elementos modificados.
• La solución debe ser reutilizable.

---

Separar la lógica de negocio de la capa de acceso a datos.

Una posible solución, la que trataré en este tema, pasa por crear un contenedor a modo de caché.

El contenedor va a estar dividido en 2 niveles:

• Nivel 1: El contenedor. Representa la interfaz accesible por la aplicación. Debe permitir realizar las operaciones habituales sobre los objetos que gestiona: creación, borrado, edición, etc.
• Nivel 2: Información de base de datos. El contenedor almacenará instancias de un objeto que almacenará la información relevante de la base de datos. Este objeto únicamente será accesible por el contenedor.

De acuerdo con lo expuesto, la implementación de la clase interna del contenedor debería tener un aspecto similar al siguiente:

/*
 * Gestiona información sobre un elemento almacenado en una caché.
 * Los objetos se guardan indizados por clave única.
 */
class UserCacheItem final
{
    UserCacheItem( ) = delete;
 
    UserCacheItem(
              const UserCacheItem& ar_other ) = delete;
 
    UserCacheItem& operator=(
              const UserCacheItem& ar_other ) = delete;
 
  public:
 
    /*
     * Constructor de la clase.
     */
    UserCacheItem(
              User* ap_item,
              int a_key )
      : _item{ ap_item },
        _key{ a_key }
    {
    }
 
    /*!
     * Destructor de la clase.
     */
    virtual ~UserCacheItem( )
    {
    }
 
    /*!
     * Método llamado por la caché cuando se han almacando los cambios en la base de datos.
     */
    void Commit( )
    {
      if ( _tempOid )
      {
        _key = *_tempOid;
        _tempOid.reset( );
      }
    }
 
    /*!
     * Indica si el objeto gestionado es nuevo o no.
     */
    inline bool IsNew( ) const
    {
      return 0 == _key;
    }
 
    /*!
     * Indica si el objeto gestionado ha sufrido cambios desde el último commit.
     */
    inline bool IsModified( ) const
    {
      return !IsNew( ) && !_tempOid && _hash != _item->Hash( );
    }
 
    /*!
     * Expone el puntero al objeto gestionado por la instancia.
     */
    inline User* Item( ) const;
    {
      return _item.get( );
    }
 
    /*!
     * Recupera la clave única utilizada para identificar el objeto gestionado.
     */
    int Key( ) const
    {
      if ( _tempOid )
        return *_tempOid;
      else
        return _key;
    }
 
    /*!
     * Recupera la clave original. 
     */
    inline int OriginalKey( ) const
    {
      return _key;
    }
 
    /*!
     * Permite modificar la clave del objeto.
     */
    void ChangeKey(
              int a_key )
    {
      if ( ar_key == _key )
      {
        _tempOid.reset( );
      }
      else if ( ( !_tempOid ) || ( a_key != *_tempOid ) )
      {
        _tempOid.reset( new int{ a_key } );
      }
    }
 
  private:
 
    std::unique_ptr< User* > _item;
    int _key;
    std::unique_ptr< int > _tempKey
};

Como se ve, internamente se usan punteros inteligentes. Desde mi punto de vista el uso de punteros inteligentes tiene dos ventajas básicas:

• Evitar lagunas de memoria.
• Queda claro que esta clase se encarga de controlar el ciclo de vida de los objetos de tipo 'User', lo cual evita malentendidos con los 'delete'.
• Facilita el mantenimiento del código.

Además, ya se cómo funciona la memoria dinámica, no necesito practicarlo cada vez que tenga que crear objetos... y más cuando su ciclo de vida está tan delimitado. Prefiero centrar mis esfuerzos en problemas más serios.

En cuanto al control del oid, se puede apreciar que se usan dos claves: _key y _tempKey. Para almacenar el oid se ha optado por un mecanismo en dos pasos:

• El valor inicial de _key se establece al crear el objeto.
• Al llamar a ChangeKey se modifica _tempKey.
• Al llamar a 'Commit' el valor de _key se modifica por _tempKey, suponiendo que tenga valor.

Este mecanismo en dos pasos permite "recordar" la clave que tenía inicialmente el objeto de cara a poder localizarlo en la base de datos en base a dicha clave. Recordemos que las actualizaciones a la base de datos suelen ser del tipo: "UPDATE users SET key=30 WHERE key=20". Si no guardamos ese '20', dificilmente podremos localizar el registro en la base de datos.

Entiendo que en este caso cambiar el oid puede no tener demasiado sentido, pero no siempre es así.

Hablando ahora del contenedor, su interfaz se detalla a continuacion:

/*!
 * Contenedor de BD para objetos de tipo "User"
 */
class UserCache
{
    UserCache(
              const UserCache& ar_other ) = delete;
 
    UserCache& operator=(
              const UserCache& ar_other ) = delete;
 
  public:
 
    /*!
     * Constructor por defecto.
     */
    UserCache( )
    {
    }
 
    /*!
     * Destructor.
     */
    virtual ~UserCache( )
    {
    }
 
    /*!
     * Inserta un nuevo elemento en la cache
     */
    bool Add(
              User* ap_element,
              int a_key )
    {
      if ( ap_element )
      {
        auto it = _items.find( a_key );
        if ( it == _items.end( ) )
        {
          UserCacheItem* newItem = new UserCacheItem{ ap_element, a_key };
          _items.insert( std::make_pair( a_key, std::unique_ptr< UserCacheItem >{ newItem } ) );
          return true;
        }
      }
 
      return false;
    }
 
    /*!
     * Obtiene la clave para un usuario.
     */
    int Key(
              const User* ap_element ) const
    {
      auto it = FindItem( *ap_element, _items );
      if ( it != _items.end( ) )
        return it->first;
 
      return 0;
    }
 
    /*!
     * Recupera la lista de usuarios.
     */
    std::vector< User* > Items( ) const
    {
      std::vector< User* > to_return;
 
      for ( auto it = _items.begin( ); it != _items.end( ); ++it )
        to_return.push_back( it->second->Item( ) );
 
      return to_return;
    }
 
    std::map< int, User* > MappedItems( ) const
    {
      std::map< int, User* > to_return;
 
      for ( auto it = _items.begin( ); it != _items.end( ); ++it )
        to_return.insert( std::make_pair( it->first, it->second->Item( ) ) );
 
      return to_return;
    }
 
    /*!
     * Recupera un usuario en base a su oid.
     */
    User* Item(
              int a_key ) const
    {
      auto it = _items.find( a_key );
      if ( it != _items.end( ) )
        return it->second->Item( );
 
      return nullptr;
    }
 
    /*!
     * Permite cambiar el oid de un usuario.
     */
    bool ChangeKey(
              const User* ap_element,
              int a_key );
    {
      if ( ap_element )
      {
        auto it = _items.find( a_key );
        if ( it != _items.end( ) )
          return ( it->second->Item( ) == ap_element );
 
        it = FindItem( *ap_element, _items );
        if ( it != _items.end( ) )
        {
          // Si cambia la clave tenemos que actualizar el mapa de elementos
          it->second->SetKey( ar_key );
          _items.insert( std::make_pair( ar_key, std::move( it->second ) ) );
          _items.erase( it );
          return true;
        }
      }
 
      return false;
    }
 
    /*!
     * Marca todos los usuarios como "no modificados", además se encarga de
     * descartar todos los elementos eliminados.
     */
    void Commit( )
    {
      for ( auto& item : _items )
        item.second->Commit( );
    }
 
    /*!
     * Reinicia la caché. Elimina todo su contenido.
     */
    void Clear( )
    {
      _items.clear( );
    }
 
    /*!
     * Indica si hay cambios pendientes de llevar a la base de datos.
     */
    bool ChangesPending( ) const;
    {
      for ( auto& item : _items )
      {
        if ( item.second->IsModified( ) )
          return true;
      }
 
      return false;
    }
 
  private:
 
    std::map< int, std::unique_ptr< UserCacheItem > > _items;
 
    std::map< int, User* >::iterator FindItem(
              const User& ar_element ) const
    {
      return std::find_if( _items.begin( ),
                           _items.end( ),
                           [&ar_element]( const std::pair< int, User* >& pair )
                           { return pair.second->Item( ) == &ar_element; } );
    }
 
};

Bueno, con este diseño parece que hemos conseguido desacoplar el uso de la base de datos del objeto 'User'. No está mal para empezar. Sin embargo aún queda camino por recorrer.

---

Borrar usuarios

Normalmente, cuando en una aplicación se decide eliminar información, éste borrado no suele ser inmediato. En ocasiones hay que esperar a que el usuario confirme la operación dando la orden de "guardar cambios", mientras que en otras ocasiones interesa retrasar las eliminaciones con la intención de intentar agruparlas para optimizar las consultas a la base de datos.

Para satisfacer esta necesidad, nuestro contenedor va a encargarse de la gestión de los elementos borrados de la siguiente forma:

• Cuando le indicamos que deseamos borrar un elemento que ya se encuentra gestionado por el contenedor lo introduce en un listado de elementos a eliminar. Los elementos no se eliminarán de forma efectiva hasta que no hagamos "commit".
• Cuando le indicamos que deseamos borrar un elemento que NO se encuentra gestionado por el contenedor lo elimina directamente. Esto es así porque al no estar gestionado por el contenedor no es posible que otras partes del código conozcan este objeto.

Un ejemplo del código que permite cumplir con esta función lo encontramos a continuación:

class UserCache
{
  public:
 
    bool Delete(
        int a_key )
    {
      auto it = _items.find( a_key );
      if ( it != _items.end( ) )
      {
        _deletedItems.push_back( std::move( it->second ) );
        _items.erase( it );
        return true;
      }
 
      return false;
    }
 
    bool Delete(
        User* ap_element )
    {
      if ( ap_element )
      {
        auto it = FindItem( *ap_element );
 
        if ( it != _items.end( ) )
        {
          _deletedItems.push_back( std::move( it->second ) );
          _items.erase( it );
          return true;
        }
      }
 
      return false;
    }
 
    std::map< int, User* > ToDelete( ) const
    {
      std::map< int, User* > to_return;
 
      for ( auto& pair : _deletedItems )
        to_return.insert( std::make_pair( pair.first, pair.second->Item( ) ) );
 
      return to_return;
    }
 
    void Commit( )
    {
      _deletedItems.clear( );
 
      for ( auto& item : _items )
        item.second->Commit( );
    }
 
    void Clear( )
    {
      _items.clear( );
      _deletedItems.clear( );
    }
 
    bool ChangesPending( ) const
    {
      if ( !_deletedItems.empty( ) )
        return true;
 
      for ( auto& item : _items )
      {
        if ( item.second->IsModified( ) )
          return true;
      }
 
      return false;
   }
 
  private:
 
    std::vector< std::unique_ptr< User > > _deletedItems;
};

Como se puede apreciar, el contenedor nos va a ofrecer en un cómodo listado todos los objetos que se han marcado como borrados. Si recogemos este listado podemos

---

Modificar usuarios

Cuando recurrimos al método 'feo' para interaccionar con bases de datos, a menudo caemos en la tentación de registrar las modificaciones con un código similar al siguiente:

class User
{
  public:
 
    User( )
      : _modified{ false }
    { }
 
    std::string Name( ) const
    { return _name; }
 
    void SetName( const std::string& name )
    {
      if ( name != _name )
      {
        _name = name;
        _modified = true;
      }
    }
 
    bool IsModified( ) const
    { return _modified; }
 
  private:
 
    std::string _name;
    bool _modified;
};

Esta solución ya no nos sirve, ya que intentamos que la clase 'User' sera totalmente independiente de la base de datos.

Para poder marcar los objetos como modificados se puede optar por varias soluciones diferentes, os enumero tres de ellas:

• Hacer una llamada del tipo 'UserCache::SetModified( usuario )' cada vez que modifiquemos un objeto. Este mecanismo tiene el inconveniente de ser complicado de gestionar, ya que obliga a meter esta instrucción en todas las funciones que modifiquen el objeto. Si el objeto se modifica en zonas muy concretas de la aplicación puede ser una solución bastante factible. PD.: no es recomendado si la clase puede ser modificada por plugins.

class UserCache
{
  public:
    void SetModified( User* ap_element );
};
 
class Something
{
  public:
 
    void UpdateUser( User* user );
    {
      user->SetName( anotherName );
      user->SetSurname( anotherSurname );
 
      // El método realmente no es estático, lo pongo asi por legibilidad
      UserCache::SetModified( ap_element );      
    }
};

• Utilizar un hash para identificar los elementos que han cambiado. Este hash debe estar mapeado en el contenedor para poder detectar cambios. Este mecanismo puede implementarse en el contenedor o en la clase 'User'. Esta solución, aparte de ser más limpia ofrece código reutilizable, ya que el hash puede usarse, por ejemplo, en los operadores de igualdad.

class User
{
  public:
    std::size_t hash( ) const
    {
      const std::size_t name{ std::hash< std::string >( )( _name ) };
      const std::size_t surname { std::hash< std::string >( )( _surname ) };
      return name ^ ( surname << 1 );
    }
};

• Utilizar un "contador de versión". El contador de versión puede ser tan sencillo como un "unsigned int" que se va incrementando cada vez que se realiza un cambio en el objeto. Entonces, basta con que el contenedor realice un mapeo de la versión de cada objeto para poder identificar los elementos modificados. La ventaja de este sistema respecto al hash es que es más rápido, la desventaja es que requiere actualizar los setters. Este método se parece bastante al "método feo" que iniciaba este apartado, es cierto.

class User
{
  public:
 
    User( )
      : _version{ 0 }
    { }
 
    void SetName( const std::string& name )
    {
      if ( name != _name )
      {
        _name = name;
        ++_version;
      }
    }
 
    unsigned int Version( ) const
    { return _version; }
};

Una vez que ya hemos elegido el mecanismo que vamos a implementar tenemos que adaptar el funcionamiento del contenedor para que sea capaz de identificar los elementos que han sufrido cambios. En este caso, el código de ejemplo presupone que se ha tomado como buena la opción de hash. Adaptar el código para que funcione con la opción del "contador de versiones" es bastante sencillo:

Clase UserCacheItem:

class UserCacheItem final
{
  public:
 
    /*!
     * \brief Constructor de la clase.
     */
    UserCacheItem(
        User* ap_item,
        int a_key )
      : _item{ ap_item },
        _key{ ar_key },
        _hash{ ap_item->Hash( ) }
    {
    }
 
    /*
     * Método llamado por la caché cuando se han almacando los cambios en la base de datos.
     */
    void Commit( )
    {
      if ( _tempOid )
      {
        _key = *_tempOid;
        _tempOid.reset( );
      }
 
      _hash = ap_item->Hash( );
    }
 
    /*!
     * Indica si el objeto gestionado ha sufrido cambios desde el último commit.
     */
    inline bool IsModified( ) const
    { return !IsNew( ) && !_tempOid && _hash != _item->Hash( ); }
 
  private:
 
    std::unique_ptr< User > _item;
    int _key;
    std::unique_ptr< int > _tempOid;
    std::size_t _hash;
 
};

Clase UserCache:

class UserCache
{
  public:
 
    std::set< User* > ToCreate( ) const
    {
      std::set< User* > to_return;
 
      for ( auto& item : _items )
      {
        if ( item.second->IsNew( ) )
          to_return.insert( item.second->Item( ) );
      }
 
      return to_return;
    }
 
    std::map< int, User* > ToUpdate( ) const
    {
      std::map< int, User* > to_return;
 
      for ( auto& item : _items )
      {
        if ( item.second->IsModified( ) )
          to_return.insert( std::make_pair( item.first, item.second->Item( ) ) );
      }
 
      return to_return;
    }
 
    bool ChangesPending( ) const
    {
      for ( auto& item : _items )
      {
        if ( item.second->IsModified( ) )
          return true;
      }
 
      return false;
    }
};

---

Conectar el contenedor con la base de datos

Una de las primeras motivaciones que nos ha llevado a este punto ha sido la necesidad de reducir el nivel de acoplamiento en nuestras clases. Por este motivo vamos a delegar la responsabilidad de la comunicación con la base de datos en una nueva clase.

A mí se me ha ocurrido llamarla 'DBUsers', para gustos, los nombres de las clases. Bueno, al tema, el caso es que esta clase debería proporcionar métodos para leer y escribir en las cachés de datos. Personalmente, en esta clase no me preocupa demasiado que haya acoplamiento ya que, como norma general, cada aplicación tiene su propio diseño de base de datos, por lo que el código de esta clase dificilmente será reutilizable.

class DBUsers
{
    DBUsers( ) = delete;
 
    DBUsers(
          const DBUsers& ar_other ) = delete;
 
    const DBUsers& operator=(
          const DBUsers& ar_other ) = delete;
 
  public:
 
    DBUsers(
           const UniqueKeyCache< User, int >& ar_cache )
      : _cache{ &ar_cache }
    {
    }
 
    virtual ~DBUsers( )
    {
    }
 
    bool SaveData( )
    {
      bool ok = true;
 
      // Este primer chequeo no sería necesario, pero me gusta la simetría
      // y además así aseguro que se elimina deletedItems
      if ( ok )
      {
        // Primero es recomendable realizar la operación de borrado
        auto deletedItems = _cache.ItemsToDelete( );
        for ( auto& pair : deletedItems )
        {
          // Generación y ejecución de las consultas de eliminación.
          // Si algúna consulta da error, actualizamos ok a false
        }
      }
 
      if ( ok )
      {
        // Después actualizamos los elementos modificados
        auto updatedItems = _cache.ItemsToUpdate( );
        for ( auto& pair : updatedItems )
        {
          // Generación y ejecución de las consultas de actualización
          // Si algúna consulta da error, actualizamos ok a false
        }
      }
 
      // Finalmente damos de alta los nuevos registros
      if ( ok )
      {
        auto newItems = _cache.ItemsToCreate( );
        for ( auto& item : newItems )
        {
          // Generación y ejecución de las consultas de creación
          // Si algúna consulta da error, actualizamos ok a false
 
          // No hay que olvidarse de recuperar el OID de cada elemento
          // y actualizar la cache.
          _cache->ChangeKey( &item, newOid );
        }
      }
 
      if ( ok )
        _cache->Commit( );
      else
      {
        // Si se produce algún error tenemos que decidir entre resetear la cache
        // o permitir al usuario intentarlo más veces.
      }
    }
 
    void LoadUsers( )
    {
      // Consulta de selección sobre la tabla de usuarios
      // ...
      while ( row.next( ) ) // Para cada registro leído...
      {
        User* user = new User{ };
        user->SetName( row.data( "name" ).toString( ) );
        user->SetSurname( row.data( "surname" ).toString( ) );
 
        _cache->Add( user, row.data( "id" ).toInt( ) );
      }
    }
 
    // No hace falta leer toda la tabla... se puede leer bajo demanda para
    // reducir los tiempos de acceso.
    void LoadUsers( const std::string& name );
 
  private:
 
    UniqueKeyCache< User, int >* _cache;
 
};

Como se ve, la caché la almaceno por referencia. Si no tengo necesidad de eliminar un objeto en un contexto dado, y además necesito que ese objeto exista, prefiero usar una referencia que un puntero, así queda claro que no es competencia de ese contexto hacer un delete. Además, la idea de que la caché pueda utilizarse de forma independiente permite aislar la capa de acceso a base de datos, piensa que no es obligatorio que los datos también se pueden guardar en un fichero o enviar por red... este diseño permite tener una clase específica para cada uso y sin necesidad de que se conozcan entre ellas.

---

Reutilización del código

El código ya nos funciona para la clase 'User', pero la gracia es que todo este esfuerzo pueda ser reutilizado con otras clases. La mejor forma para hacer esto es convertir la caché en un template... el código puede que se ensucie un poco con esta conversión, pero creo que es un sacrificio razonable que se va a compensar con creces:

Template CacheItem (sustituye a UserCacheItem):

/*!
 * Gestiona información sobre un elemento almacenado en una caché.
 * Los objetos se guardan indizados por clave única.
 */
template< class _CLASS_, class _KEY_ >
class CacheItem final
{
    CacheItem( ) = delete;
 
    CacheItem(
        const CacheItem& ar_other ) = delete;
 
    CacheItem& operator=(
        const CacheItem& ar_other ) = delete;
 
  public:
 
    /*!
     * Constructor de la clase.
     */
    CacheItem(
        _CLASS_* ap_item,
        const _KEY_& ar_key );
 
    /*!
     * Destructor de la clase.
     */
    virtual ~CacheItem( );
 
    /*!
     * Método llamado por la caché cuando se han almacando los cambios en la base de datos.
     */
    void Commit( );
 
    /*!
     * Indica si el objeto gestionado es nuevo o no.
     */
    inline bool IsNew( ) const
    { return _KEY_{ } == _key; }
 
    /*!
     * Indica si el objeto gestionado ha sufrido cambios desde el último commit.
     */
    inline bool IsModified( ) const
    { return !IsNew( ) && !_tempOid && _hash != _item->Hash( ); }
 
    /*!
     * Expone el puntero al objeto gestionado por la instancia.
     */
    inline _CLASS_* Item( ) const
    { return _item.get( ); }
 
    /*!
     * Recupera la clave única utilizada para identificar el objeto gestionado.
     */
    _KEY_ Key( ) const;
 
    /*!
     * Recupera la clave original. 
     */
    inline _KEY_ OriginalKey( ) const
    { return _key; }
 
    /*!
     * Permite modificar la clave del objeto.
     */
    void ChangeKey(
        const _KEY_& ar_key )
    {
      if ( ar_key == _key )
      {
        _tempOid.reset( );
      }
      else if ( ( !_tempOid ) || ( ar_key != *_tempOid ) )
      {
        _tempOid.reset( new _KEY_{ ar_key } );
      }
    }
 
  private:
 
    std::unique_ptr< _CLASS_ > _item;
    _KEY_ _key;
    std::unique_ptr< _KEY_ > _tempOid;
    std::size_t _hash;
 
};
 
template< class _CLASS_, class _KEY_ >
CacheItem< _CLASS_,_KEY_ >::CacheItem(
          _CLASS_* ap_item,
          const _KEY_& ar_key )
  : _item{ ap_item },
    _key{ ar_key },
    _hash{ ap_item->Hash( ) }
{
}
 
template< class _CLASS_, class _KEY_ >
CacheItem< _CLASS_,_KEY_ >::~CacheItem( )
{
}
 
template< class _CLASS_, class _KEY_ >
void
CacheItem< _CLASS_,_KEY_ >::Commit( )
{
  if ( _tempOid )
  {
    _key = *_tempOid;
    _tempOid.reset( );
  }
 
  _hash = _item->Hash( );
}
 
template< class _CLASS_, class _KEY_ >
_KEY_
CacheItem< _CLASS_,_KEY_ >::Key( ) const
{
  if ( _tempOid )
    return *_tempOid;
  else
    return _key;
}

Se pueden apreciar algúnos cambios en lo relativo al tratamiento de la clave primaria. Dado que ahora esta clave puede ser de cualquier tipo (un string por ejemplo), los métodos ahora gestionan la clave por referencia.

Clase UniqueKeyCache (sustituye a UserCache):

template< class _CLASS_, class _KEY_ >
class UniqueKeyCache
{
    UniqueKeyCache(
        const UniqueKeyCache& ar_other ) = delete;
 
    UniqueKeyCache& operator=(
        const UniqueKeyCache& ar_other ) = delete;
 
  public:
 
    /*!
     * Constructor por defecto.
     */
    UniqueKeyCache( )
    { }
 
    /*!
     * Destructor.
     */
    virtual ~UniqueKeyCache( )
    { }
 
    /*!
     * Inserta un nuevo elemento en la cache.
     */
    bool Add(
        _CLASS_* ap_element,
        const _KEY_& ar_key );
 
    /*!
     * Devuelve la clave asociada a un elemento.
     */
    _KEY_ Key(
        const _CLASS_* ap_element ) const;
 
    /*!
     * Marca un elemento para ser eliminado.
     */
    bool Delete(
        const _KEY_& ar_key );
 
    /*!
     * Marca un elemento para ser eliminado.
     */
    bool Delete(
        _CLASS_* ap_element );
 
    /*!
     * Devuelve el listado de elementos.
     */
    std::set< _CLASS_* > Items( ) const;
 
    /*!
     * Devuelve el listado de elementos mapeados por la clave primaria.
     */
    std::map< _KEY_, _CLASS_* > MappedItems( ) const;
 
    /*!
     * Devuelve un elemento dada su clave primaria.
     */
    _CLASS_* Item(
        const _KEY_& ar_key ) const;
 
    /*!
     * Devuelve la lista de elementos que aún no están dados de alta en la base
     * de datos.
     */
    std::set< _CLASS_* > ToCreate( ) const;
 
    /*!
     * Devuelve la lista de elementos a actualizar en la base de datos.
     */
    std::map< _KEY_, _CLASS_* > ToUpdate( ) const;
 
    /*!
     * Devuelve la lista de elementos a eliminar de la base de datos.
     */
    std::map< _KEY_, _CLASS_* > ToDelete( ) const;
 
    /*!
     * Permite modificar la clave primaria de un elemento.
     */
    bool ChangeKey(
        const _CLASS_* ap_element,
        const _KEY_& ar_key );
 
    /*!
     * Limpia la lista de elementos nuevos y/o modificados y elimina los
     * elementos marcados para borrar.
     */     
    void Commit( );
 
    /*!
     * Limpia la caché, eliminando todo su contenido.
     */
    void Clear( );
 
    /*!
     * Indica si hay o no cambios pendientes de llevar a la base de datos.
     */
    bool ChangesPending( ) const;
 
  private:
 
    using _Item_              = CacheItem< _CLASS_, _KEY_ >;
    using _ItemMap_           = std::map< _KEY_, std::unique_ptr< _Item_ > >;
    using _ItemPair_          = std::pair< _KEY_, std::unique_ptr< _Item_ > >;
    using _ItemMapIterator_   = typename _ItemMap_::iterator;
    using _ItemList_          = std::vector< std::unique_ptr< _Item_ > >;
 
    _ItemMap_ _items;
    _ItemList_ _deletedItems;
 
    /*!
     * Utilidad para buscar en la lista de elementos.
     */
    _ItemMapIterator_ FindItem(
        _CLASS_* ap_element ) const
    {
      return std::find_if( _items.begin( ),
                           _items.end( ),
                           [ap_element]( const _ItemPair_& pair )
                           { return pair.second->Item( ) == ap_element; } );
    }
};
 
template< class _CLASS_, class _KEY_ >
bool
UniqueKeyCache< _CLASS_, _KEY_ >::Add(
          _CLASS_* ap_element,
          const _KEY_& ar_key )
{
  if ( ap_element )
  {
    auto it = _items.find( ar_key );
    if ( it == _items.end( ) )
    {
      _Item_* newItem = new _Item_{ ap_element, ar_key };
      _items.insert( std::make_pair( ar_key, std::unique_ptr< _Item_ >( newItem ) ) );
      return true;
    }
  }
 
  return false;
}
 
template< class _CLASS_, class _KEY_ >
_KEY_
UniqueKeyCache< _CLASS_, _KEY_ >::Key(
          const _CLASS_* ap_element ) const
{
  auto it = FindItem( *ap_element );
  if ( it != _items.end( ) )
    return it->first;
 
  return _KEY_{ };
}
 
template< class _CLASS_, class _KEY_ >
bool
UniqueKeyCache< _CLASS_, _KEY_ >::Delete(
          const _KEY_& ar_key )
{
  auto it = _items.find( ar_key );
  if ( it != _items.end( ) )
  {
    _deletedItems.push_back( std::move( it->second ) );
    _items.erase( it );
    return true;
  }
 
  return false;
}
 
template< class _CLASS_, class _KEY_ >
bool
UniqueKeyCache< _CLASS_, _KEY_ >::Delete(
          _CLASS_* ap_element )
{
  if ( ap_element )
  {
    auto it = FindItem( *ap_element );
    if ( it != _items.end( ) )
    {
      _deletedItems.push_back( std::move( it->second ) );
      _items.erase( it );
      return true;
    }
  }
 
  return false;
}
 
template< class _CLASS_, class _KEY_ >
std::set< _CLASS_* >
UniqueKeyCache< _CLASS_, _KEY_ >::Items( ) const
{
  std::set< _CLASS_* > to_return;
 
  for ( auto& pair : _items )
    to_return.insert( pair.second->Item( ) );
 
  return to_return;
}
 
template< class _CLASS_, class _KEY_ >
std::map< _KEY_, _CLASS_* >
UniqueKeyCache< _CLASS_, _KEY_ >::MappedItems( ) const
{
  std::map< _KEY_, _CLASS_* > to_return;
 
  for ( auto& pair : _items )
    to_return.insert( std::make_pair( pair.first, pair.second->Item( ) ) );
 
  return to_return;
}
 
template< class _CLASS_, class _KEY_ >
_CLASS_*
UniqueKeyCache< _CLASS_, _KEY_ >::Item(
          const _KEY_& ar_key ) const
{
  auto it = _items.find( ar_key );
  if ( it != _items.end( ) )
    return it->second->Item( );
 
  return nullptr;
}
 
template< class _CLASS_, class _KEY_ >
std::set< _CLASS_* >
UniqueKeyCache< _CLASS_, _KEY_ >::ToCreate( ) const
{
  std::set< _CLASS_* > to_return;
 
  for ( auto& pair : _items )
  {
    if ( pair.second->IsNew( ) )
      to_return.insert( pair.second->Item( ) );
  }
 
  return to_return;
}
 
template< class _CLASS_, class _KEY_ >
std::map< _KEY_, _CLASS_* >
UniqueKeyCache< _CLASS_, _KEY_ >::ToUpdate( ) const
{
  std::map< _KEY_, _CLASS_* > to_return;
 
  for ( auto& item : _items )
  {
    if ( item.second->IsModified( ) )
      to_return.insert( std::make_pair( item.first, item.second->Item( ) ) );
  }
 
  return to_return;
}
 
template< class _CLASS_, class _KEY_ >
std::map< _KEY_, _CLASS_* >
UniqueKeyCache< _CLASS_, _KEY_ >::ToDelete( ) const
{
  std::map< _KEY_, _CLASS_* > to_return;
 
  for ( auto& pair : _deletedItems )
    to_return.insert( std::make_pair( pair.first, pair.second->Item( ) ) );
 
  return to_return;
}
 
template< class _CLASS_, class _KEY_ >
bool
UniqueKeyCache< _CLASS_, _KEY_ >::ChangeKey(
          const _CLASS_* ap_element,
          const _KEY_& ar_key )
{
  if ( ap_element )
  {
    auto it = _items.find( ar_key );
    if ( it != _items.end( ) )
      return ( it->second->Item( ) == ap_element );
 
    it = FindItem( *ap_element );
    if ( it != _items.end( ) )
    {
      it->second->SetKey( ar_key );
      _items.insert( std::make_pair( ar_key, std::move( it->second ) ) );
      _items.erase( it );
      return true;
    }
  }
 
  return false;
}
 
template< class _CLASS_, class _KEY_ >
void
UniqueKeyCache< _CLASS_, _KEY_ >::Commit( )
{
  _deletedItems.clear( );
 
  for ( auto& item : _items )
    item.second->Commit( );
}
 
template< class _CLASS_, class _KEY_ >
void
UniqueKeyCache< _CLASS_, _KEY_ >::Clear( )
{
  _items.clear( );
  _deletedItems.clear( );
}
 
template< class _CLASS_, class _KEY_ >
bool
UniqueKeyCache< _CLASS_, _KEY_ >::ChangesPending( ) const
{
  if ( !_deletedItems.empty( ) )
    return true;
 
  for ( auto& item : _items )
  {
    if ( item.second->IsModified( ) )
      return true;
  }
 
  return false;
}

---

Posibles mejoras

La cache se puede heredar para añadir funcionalidad específica en función del tipo de objeto que estemos cacheando. Por ejemplo, en el caso de los usuarios podría ser util obtener un listado de los usuarios con la cuenta bloqueada. Básicamente lo único que tendríamos que modificar en la clase 'UniqueKeyCache' es poner el listado de elementos en la parte protegida y heredar:

class UsersCache : public UniqueKeyCache< User, int >
{
  public:
 
    std::set< User* > LockedAccounts( ) const
    {
      std::set< User* > to_return;
 
      for ( auto& pair : _items )
      {
        if ( pair->second->Item( )->IsLocked( ) )
          to_return.insert( pair->second->Item( ) );
      }
 
      return to_return;
    }
};

 Y bueno, dado que un template no es exactamente lo mismo que una clase base, lo mejor es también sustituir 'DBUsers' para que acepte un objeto de tipo 'UserCache':
 

class DBUsers
{
    DBUsers( ) = delete;
 
    DBUsers(
          const DBUsers& ar_other ) = delete;
 
    const DBUsers& operator=(
          const DBUsers& ar_other ) = delete;
  public:
 
    DBUsers(
           const UsersCache& ar_cache )
      : _cache{ ar_cache }
    {
    }
 
    virtual ~DBUsers( )
    {
    }
 
    bool SaveData( )
    {
      bool ok = true;
 
      // Este primer chequeo no sería necesario, pero me gusta la simetría
      // y además así aseguro que se elimina deletedItems cuando deja de ser necesario
      if ( ok )
      {
        // Primero es recomendable realizar la operación de borrado
        auto deletedItems = _cache.ItemsToDelete( );
        for ( auto& pair : deletedItems )
        {
          // Generación y ejecución de las consultas de eliminación.
          // Si algúna consulta da error, actualizamos ok a false
        }
      }
 
      if ( ok )
      {
        // Después actualizamos los elementos modificados
        auto updatedItems = _cache.ItemsToUpdate( );
        for ( auto& pair : updatedItems )
        {
          // Generación y ejecución de las consultas de actualización
          // Si algúna consulta da error, actualizamos ok a false
        }
      }
 
      // Finalmente damos de alta los nuevos registros
      if ( ok )
      {
        auto newItems = _cache.ItemsToCreate( );
        for ( auto& item : newItems )
        {
          // Generación y ejecución de las consultas de creación
          // Si algúna consulta da error, actualizamos ok a false
 
          // No hay que olvidarse de recuperar el OID de cada elemento
          // y actualizar la cache.
          _cache.ChangeKey( &item, newOid );
        }
      }
 
      if ( ok )
        _cache.Commit( );
      else
      {
        // Si se produce algún error tenemos que decidir entre resetear la cache
        // o permitir al usuario intentarlo más veces.
      }
    }
 
    void LoadUsers( )
    {
      // Consulta de selección sobre la tabla de usuarios
      // ...
      while ( row.next( ) ) // Para cada registro leído...
      {
        User* user = new User{ };
        user->SetName( row.data( "name" ).toString( ) );
        user->SetSurname( row.data( "surname" ).toString( ) );
 
        _cache.Add( user, row.data( "id" ).toInt( ) );
      }
    }
 
    // No hace falta leer toda la tabla... se puede leer bajo demanda para
    // reducir los tiempos de acceso.
    void LoadUsers( const std::string& name );
 
  private:
 
    UsersCache& _cache;
 
};

Y esto es todo. Creo que el diseño final es elegante, ya que reduce enormemente la dependencia entre clases y permite crear rápidamente enlaces con bases de datos, ficheros XML, ficheros binarios, sockets, etc.

También hay que tener en cuenta que el diseño que he planteado se puede adaptar de forma más o menos sencilla para que funcione bajo diferentes escenarios: Registros sin clave primaria, Registros con clave primaria compuesta, Clave primaria repetida, etc. Yo, personalmente, diseñaría un template de cache específico para cada caso... no soy especialmente partidario de hacer un template que herede de otro.

Y poco más que contar. Espero que os haya gustado, que hayáis aprendido algo o, en el peor de los casos, me conformo con que no penséis que habéis perdido el tiempo al leer este artículo.

Un saludo.

Muchas veces, al hacer programas nos dedicamos a reinventar la rueda. Unas veces es para aprender, pero otras muchas es por simple desconocimiento de las herramientas de las que disponemos.

He aquí algunos ejemplos, aunque hay que tener en cuenta lo siguiente:

• Algunos ejemplos solo funcionarán con compiladores compatibles con C++11.
• Para entender los ejemplos es necesario tener una base mínima ( familiarizarse con contenedores e iteradores, por ejemplo )
• Los ejemplos no intentan hacer uso del algoritmo más óptimo o más rápido o más ... son simplemente ilustrativos. La opción más óptima dependerá de los requisitos propios de cada aplicación.

Si el aporte os resulta interesante intentaré ampliarlo conforme tenga tiempo libre.

Ordenar un vector:

std::sort es el primero de los grandes desconocidos. Esta función, bien utilizada, nos permite ordenar con facilidad casi cualquier tipo de vector, lista, arreglo, ... para ello nos apoyamos en las funciones std::begin y std::end, nuevas en C++11, que permiten obtener iteradores incluso para arreglos.

Si usamos C++11, podemos también diseñar nuestras propias funciones de ordenación basándonos en funciones lambda, como se verá más adelante.

Apoyándonos en las funciones std::begin y std::end podemos

#include <algorithm>
#include <functional>
#include <iostream>
 
int main( )
{
  int numeros[] = {3, 5, 7, 2, 9, 1, 4, 8, 6 };
 
  std::cout << "Orden de mayor a menor" << std::endl;
  std::sort ( std::begin(numeros), std::end(numeros), std::greater< int >( ) );
  for ( auto it = std::begin( numeros ); it != std::end( numeros ); ++it )
    std::cout << *it << ' ';
  std::cout << std::endl;
 
  std::cout << "Orden de menor a mayor" << std::endl;
  std::sort ( std::begin(numeros), std::end(numeros), std::less< int >( ) );
  for ( auto it = std::begin( numeros ); it != std::end( numeros ); ++it )
    std::cout << *it << ' ';
  std::cout << std::endl;
  return 0;
}

Conteo de elementos en un vector

En el foro suele ser habitual que alguien pida ayuda saber cuántos elementos de un arreglo cumplen una serie de características...

Normalmente las soluciones pasan por poner un for con uno o varios ifs en su interior... con lo limpio que puede llegar a quedar usando las instrucciones adecuadas.

greater_equal es un template que implementa el operador función. Dicho operador requiere 2 parámetros... el primero es el valor a comprobar y el segundo el valor de referencia. El operador devuelve true si el primer parámetro es mayor o igual al segundo. Debido a que el parámetro que sirve de referencia es el segundo, se hace necesario usar la funcion bind2nd "bind second", que permite asignar un valor fijo al segundo parámetro a lo largo de todas las llamadas.

finalmente count_if se encarga de recorrer los iteradores y realiza un conteno de todas las comprobaciones que arrojan un resultado positivo.

El resultado es una comparación programada en un par de líneas.

Para comparaciones más complejas se puede usar una expresión lambda, una función propia o una clase que implemente el operador función, como puede verse en los ejemplos.

#include <algorithm>
#include <functional>
#include <iostream>
 
bool pares( int num )
{
  return num % 2 == 0;
}
 
class DivisiblePorN
{
  public:
 
    DivisiblePorN( int divisor )
      : _divisor( divisor )
    { }
 
    bool operator( )( int numero )
    {
      return ( numero % _divisor == 0 );
    }
 
  private:
 
    int _divisor;
};
 
int main( )
{
  int numeros[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 };
  int resultado = std::count_if( std::begin( numeros ), std::end( numeros ),
                                 std::bind2nd( std::greater_equal< int >( ), 7 ) );
  std::cout << "Numeros mayores o iguales a 7: " << resultado << std::endl;
 
  resultado = std::count_if( std::begin( numeros ), std::end( numeros ),
                             []( int num ){ return num%2; } );
  std::cout << "Numeros impares: " << resultado << std::endl;
 
  resultado = std::count_if( std::begin( numeros ), std::end( numeros ), pares );
  std::cout << "Numeros pares: " << resultado << std::endl;
 
  DivisiblePorN divisible3( 3 );
  resultado = std::count_if( std::begin( numeros ), std::end( numeros ), divisible3 );
  std::cout << "Numeros divisibles entre 3: " << resultado << std::endl;
 
  return 0;
}

Intercambiar el valor de dos variables

El titular lo dice todo... podemos hacer uso la opción larga que todo el mundo conoce ( en cualquiera de sus variantes ) o dejar que la stl haga el "trabajo sucio:

#include <algorithm>
#include <iostream>
#include <utility>
#include <vector>
 
int main( )
{
  int x = 1;
  int y = 2;
 
  std::swap( x, y );
 
  std::cout << "X = " << x << "; Y = " << y << std::endl << std::endl;
 
  int v1[] = { 1, 2, 3, 4 };
  int v2[] = { 5, 6, 7, 8 };
  std::swap( v1, v2 );
 
  std::cout << "v1 = {";
  for ( auto i : v1 )
    std::cout << " " << i;
  std::cout << " }" << std::endl;
  std::cout << "v2 = {";
  for ( auto i : v2 )
    std::cout << " " << i;
  std::cout << " }" << std::endl << std::endl;
 
  std::vector< int > vector1 = { 10, 20, 30, 40 };
  std::vector< int > vector2 = { 50, 60, 70, 80 };
  std::swap( vector1, vector2 );
 
  std::cout << "vector1 = {";
  for_each( vector1.begin( ), vector1.end( ), []( int num ){ std::cout << " " << num; } );
  std::cout << " }" << std::endl;
 
  std::cout << "vector2 = {";
  for_each( vector2.begin( ), vector2.end( ), []( int num ){ std::cout << " " << num; } );
  std::cout << " }" << std::endl;
 
  return 0;
}

Sumar valores

"Tengo que devolver la suma de todos los valores del arreglo"... ¿te suena esta frase? La primera solución que aparece en la mente de más de uno pasa por inicializar un contador, poner un bucle for e ir acumulando valores... no hace falta:

#include <functional>
#include <iostream>
#include <numeric>
 
int main( )
{
  int numeros[] = { 20, 45, 86, 91, 10, 25, 4, 17, 62 };
 
  std::cout << "Suma total: ";
  std::cout << std::accumulate(std::begin( numeros ), std::end( numeros ), 0 );
  std::cout << std::endl;
}

¿Y si sólo queremos saber la suma de aquellos que cumplan una condición determinada? Sin problemas, únicamente tenemos que aplicar lo que hemos visto en apartados anteriores:

#include <functional>
#include <iostream>
#include <numeric>
 
class AddLessThanN
{
  public:
 
    AddLessThanN( int n )
      : _limit( n )
    {
 
    }
 
    int operator( )( int accum, int x )
    {
      if ( x < _limit )
        accum += x;
 
      return accum;
    }
 
  private:
 
    int _limit;
};
 
int main( )
{
  int numeros[] = { 20, 45, 86, 91, 10, 25, 4, 17, 62 };
 
  AddLessThanN lessThan( 20 );
  std::cout << "Sumar elementos menores que 20: ";
  std::cout << std::accumulate(std::begin( numeros ), std::end( numeros ), 0, lessThan );
  std::cout << std::endl;
}

Eliminar elementos de un vector

La opciónes tradicionales pasan todas por usar un bucle for y luego, o hacer malabares con los iteradores, añadir los elementos a eliminar en una lista... o crear una lista nuevo con los elementos válidos...

#include <algorithm>
#include <iostream>
#include <vector>
 
int main( )
{
  std::vector< int > numeros = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
 
  std::vector< int >::iterator it = std::remove_if ( numeros.begin( ), numeros.end( ), [](int num){ return num%2; } );
  numeros.erase( it, numeros.end( ) );
 
  std::cout << "Solo pares: ";
  for_each( numeros.begin( ), numeros.end( ), []( int num){ std::cout << num << " "; } );
  std::cout << std::endl;
 
  return 0;
}

PD.: también funciona con arreglos:

#include <algorithm>
#include <iostream>
#include <vector>
 
int main( )
{
  int numeros[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
 
  int* itEnd = std::remove_if ( std::begin( numeros ), std::end( numeros ), [](int num){ return num%2 == 0; } );
 
  std::cout << "Solo impares: ";
  for_each( std::begin( numeros ), itEnd, []( int num){ std::cout << num << " "; } );
  std::cout << std::endl;
 
  return 0;
}

Visto que aquí entra mucha gente que está aprendiendo a programar, he creído conveniente indicar una serie de ideas que creo que mejoran la legibilidad, usabilidad e incluso el rendimiento del código.

1. Al pasar una clase como parámetro, mejor con referencia

Es muy común ver la gente, en las prácticas, presenta una función del tipo

void func( std::string parametro );

El problema que presenta este código es que se va a crear un string temporal, copia del que se ha pasado como parámetro, y que se eliminará al salir de la función.

La forma natural de evitar este problema es pasar las clases como referencias constantes. De esta forma aseguramos, si se aplican buenas prácticas, que el objeto pasado como parámetro no va a ser modificado dentro de nuestra función:

void func( const std::string& parametro );

Además, su uso dentro de la función no va a cambiar, ya que al ser referencia el acceso a sus miembros se sigue haciendo con el operador '.'.

2. Al pasar un tipo básico como parámetro, evita referencias constantes.

Mucha gente se aprende lo indicado en el primer punto y lo aplica de forma indiscriminada. Esto lleva a encontrarse funciones del tipo:

void func( const bool& parametro );

No hay que olvidar que una referencia es un puntero "encubierto". Punteros, referencias y la inmensa mayoría de tipos básicos ocupan lo mismo en la pila, por lo que no se obtiene ninguna ventaja al pasar un tipo básico como referencia constante.

Además, pasar un tipo como referencia provoca que en la pila se almacene la referencia, lo que provoca que el acceso al parámetro conlleve dos instrucciones en vez de una...

3. Los miembros de una clase, mejor privados

Es costumbre, supongo que por comodidad, el declarar algunos miembros de una clase en la parte pública para ahorrarnos los getters y los setters correspondientes.

Esta práctica es bastante mala, ya que rompe con el principio de encapsulación que es uno de los pilares de la programación orientada a objetos. Además, presenta el problema de que, si en algún momento, una necesidad obliga a implementar un getter y/o un setter, tendremos que reemplazar todas las llamadas correspondientes... y eso no suele ser algo trivial.

Además, utilizar getters y setters no suele provocar problemas de rendimiento, ya que los compiladores son capaces de optimizar el código de forma que el acceso sea tan eficiente como llamar directamente a la variable miembro.

class VersionMala
{
  public:
    std::string nombre;
    int edad;
};
 
class VersionBuena
{
  public:
    std::string GetNombre( ) const;
    void SetNombre( const std::string nombre );
 
    int GetEdad( ) const;
    void SetEdad( int edad );
 
  private:
 
    std::string nombre;
    int edad;
};

4. Los destructores, preferiblemente virtuales.

Declarar un constructor como virtual permite que ese destructor sea llamado cuando estamos eliminando una instancia de una subclase.

Parece una tontería, pero no es un fallo obvio y descubrir el origen de una laguna de memoria provocada por este motivo puede ser complicada de detectar.

5. Acostúmbrate a usar Forward declarations.

Cuando se compila un código fuente, el compilador necesita "explotar" los includes para poder realizar su tarea correctamente. Explotar los includes significa que ha de sustituir un include por el contenido del archivo al que apunta... y todo esto para cada archivo a compilar.

Hay que tener en cuenta que el proceso de explotar los includes es recursivo... los includes que se encuentran dentro del archivo apuntado por el include también son explotados.

Como es de imaginar, este trabajo incrementa el tiempo de compilación y los recursos de memoria necesarios para compilar un programa o librería.

Hay una forma de reducir esta carga y es mediante las forward declarations.

A continuación se explican los casos en los que se pueden usar forward declarations en vez de includes:

* Cuando el miembro de una clase es un puntero:

class VehiculoImpl;
 
class Vehiculo
{
  private:
    VehiculoImpl* impl;
};

* Clases pasadas como argumento, se pase la clase por valor, referencia o puntero:

class VehiculoImpl;
class Persona;
 
class Vehiculo
{
  private:
    VehiculoImpl* impl;
 
  public:
    void SetConductor( Persona conductor );
};

* Clases retornadas en un método:

class VehiculoImpl;
class Persona;
 
class Vehiculo
{
  private:
    VehiculoImpl* impl;
 
  public:
    void SetConductor( Persona conductor );
 
    Persona GetConductor( ) const;
};

*Lo anterior es perfectamente aplicable cuando nos encontramos con namespace:

class VehiculoImpl;
 
namespace prueba
{
  class Persona;
}
 
class Vehiculo
{
  private:
    VehiculoImpl* impl;
 
  public:
    void SetConductor( prueba::Persona conductor );
 
    prueba::Persona GetConductor( ) const;
};

Hay una excepción, y se encuentra al tratar con templates... una clase definida por un template no puede aprovecharse de esta característica del lenguaje, mala suerte.

6. Evitar defines, usar enums

Usar enumerados en vez de defines tiene numerosas ventajas:

• Los valores, por defecto, siempre van a ser consecutivos.
• Los valores se mantienen agrupados.
• A la hora de revisar el código, se sabe qué valores están relacionados.
• Se evitan sustituciones inesperadas en el código.
• A partir de C++11 se pueden añadir opciones de tipado fuertes, lo que mejora su usabilidad.

7. Nombra las clases, variables, métodos, miembros y argumentos con sentido.

un código tal que:

class clase
{
  public:
    void func( int a, int b, std::string c )
    {
      if ( a != this->a && b != this->b && a < b )
      {
        this->a = a;
        this->b = b;
        this->c = c;
    }
 
  private:
    int a;
    int b;
    std::string c;
 
};

seguro que es menos claro que:

class Filtro
{
  public:
 
    void SetValores( int minimo, int maximo, std::string mensaje )
    {
      if ( minimo != _minimo && maximo != _maximo && minimo < _maximo )
      {
        _minimo = minimo;
        _maximo = maximo;
        _mensaje = mensaje;
      }
    }
 
  private:
    int _minimo;
    int _maximo;
    std::string _mensaje;
}

A la larga usar nombres que aporten información sobre la función a cumplir por el elemento en cuestión proporciona una cantidad enorme de beneficios.

8. No tengas miedo a los contenedores

Yo creo que la práctica totalidad de la gente que está aprendiendo a programar no es consciente de la potencia y versatilidad que proporcionan los contenedores de la STL.

Muchos, al venir de una experiencia previa con C, siguen aplicando los mismos mecanismos de arreglos a la hora de trabajar con colecciones de elementos.

Lo que sucede es que los contenedores están específicamente diseñados para trabajar con colecciones. Gracias a ello suponen una herramienta muy útil a la par que potente... incluso si se elige el contenedor adecuado a nuestras necesidades podemos ahorrarnos bastante código.

* vector: Es el contenedor por defecto. Tiene la característica de que el orden de sus elementos permanece inalterado y permite el acceso a sus elementos a través de índices.

* set: Este contenedor almacena sus elementos ordenados y no admite duplicados. Cuando añadimos un elemento nuevo no podemos saber, a priori en qué posición se va a almacenar. No admite el acceso a través de índices.

  Una característica poco explotada de este elemento y que creo que a todos nos acaban pidiendo alguna vez en las prácticas es la siguiente: coger una lista de elementos y presentar un listado sin duplicados:

int lista[10] = { 5, 2, 3, 1, 6, 5, 4, 2, 5, 1 }; 
std::set< int > sinDuplicados( lista, lista + 10 );
 
for ( auto it = sinDuplicados.begin( ); it != sinDuplicados.end( ); ++it )
  std::cout << *it << " ";
 
std::cout << std::endl;
 

  El código anterior sacará por lo siguiente:


  Fácil, no?

* map: Este contenedor permite añadir elementos asociándoles una clave; los registros se almacenan ordenados en base a su clave y no admite dos claves iguales, en esto se parece al set. No admite el acceso por índice, pero si por clave:

std::map< std::string, int > items;
items[ "uno" ] = 1;
items[ "dos" ] = 1;
items[ "tres" ] = 3;
items[ "dos" ] = 2;
 
for ( auto it = items.begin( ); it != items.end( ); ++it )
  std::cout << it->first << " " << it->second << std::endl;

  Resultado:


* stack: Implementa una pila LIFO.

* queue: Implementa una pila FIFO.

* array: Es similar a un vector en cuanto a que los elementos se almacenan de la misma forma y que admite duplicados. Es de tamaño fijo y dicho tamaño hay que especificarlo al crear el objeto.

9. Olvida los cast de C

A primera vista, puede parecer mucho más cómodo realizar una conversión utilizando los cast propios de C. Sin embargo, este tipo de conversiones pueden llegar a ser peligrosas, ya que no hacen ningún tipo de chequeo previo.

Los cast de C++ proporcionan más seguridad al respecto. Además, también es más sencillo localizar cast propios de C++ por su sintaxis particular.

10. Diseña funciones cortas.

Como norma general, las funciones no deberían tener más de 20 - 30 líneas.

Tener funciones con este tamaño permite tener funciones sencillas, con una traza fácil de seguir y con un mantenimiento bastante sencillo. Además, podrás ver toda la función en la pantalla de una vez, lo que supone una gran ventaja.

Normalmente cuando una función se hace demasiado grande ( y las he llegado a ver de 5.000 líneas y más ) es debido, bien a un mal diseño por parte del programador, bien a que la función está asumiendo más de una responsabilidad. En cualquier caso lo ideal sería revisar esa función y reducir su tamaño.

Esta norma es sobretodo orientativa... pueden darse casos en los que no es recomendable aplicarla... pero ya adelanto que en un buen diseño son una minoría.

11. Evitar miembros privados y estáticos

class POO
{
  public:
    POO( );
 
    // ...
  private:
    static bool _algo;
};

Los miembros privados y estáticos no aportan absolutamente nada a la interfaz de una clase en C++... no influyen en el tamaño de la clase, no permiten el acceso a información nueva...

Y no contentos con esto aportan un problema, y es que, al añadir, modificar o eliminar alguno de estos miembros se obliga a recompilar todos los fuentes dependientes de esta clase.

Es más práctico declarar esos elementos en el cpp, ya que así, en caso de sufrir cambios, solo se recompila un archivo.

Para evitar problemas con nombres duplicados, lo recomendable es definirlos dentro de un espacio de nombres anónimo. Esto es:

namespace
{
  bool _algo = false;
}
 
POO::POO( )
{
  _algo = true;
}
 

Al incluir la declaración en un namespace anónimo convertimos ese código en innacesible desde fuera del archivo en el que se encuentra, por lo que no habrá problemas si en otro cpp declaramos otra variable _algo, sea o no del mismo tipo.

Como se puede ver, acceder a la variable estática es algo totalmente trivial y exento de complicaciones.

Este truco se puede aplicar también a métodos que estén definidos como privados y estáticos, lo cual es igualmente aconsejable.

12. Evita a toda costa usar using namespace en las cabeceras.

Quizás por comodidad, la gente se acostumbra a usar esta sintaxis en los archivos de cabecera, así el acceso a las clases incluidas en ese espacio de nombres es más corto y limpio.

El problema es que al incluir un using en un archivo de cabecera automáticamente se propaga a todos los archivos que tengan dependencias de dicha cabecera.

En caso de usar esta característica, añádela únicamente a los cpp, aunque mi consejo personal es no usar "using namespace" como norma general. La razón es que al perder la clase su espacio de nombres se desvirtúa el código. "std::vector" te da mucha más información que "vector" a secas... además evitas colisiones por coincidencia de nombres.

13. Una clase o un método = una responsabilidad

A veces a los programadores se nos empiezan a ocurrir mil ideas que acabamos conjugando en un único sitio, obteniendo como resultado una clase o método gigantesco que más bien parece sacado de la segunda parte de godzilla.

Hay que procurar que cada clase y cada método tenga una única responsabilidad. Esto es, si tenemos una clase "Alumno"... esta clase sólo ha de preocuparse de almacenar los datos de un alumno, única y exclusivamente.

* si necesitamos gestionar una colección de alumnos de forma especial debemos crear una clase tipo "ListaAlumnos"
* Para rellenar los datos de un alumno, el código que interacciona con el usuario / base de datos / socket / ... ha de estar, necesariamente, en cualquier otro sitio.

Tener clases y métodos con una única responsabilidad facilita la comprensión del código y dificulta la aparición de errores.... tener un método que se conecte a un servidor, le pida información, la muestre por pantalla y le pregunte al usuario su nombre no parece que vaya a resultar agradable a la hora de depurarlo.

Definir correctamente las responsabilidades de cada clase y cada método puede costar bastante al principio, pero al final es sobretodo práctica y experiencia... no digo que después sea coser y cantar... siempre hay situaciones en las que la decisión no es clara, pero no por ello nos vamos a rendir a las primeras de cambio.

14. Evita el acoplamiento entre clases

Se dice que dos clases están acopladas cuando resulta imposible trabajar con una de ellas sin tener que depender de la otra. Obviamente siempre va a existir un cierto acople entre las clases... es ley de vida, sin embargo hay que reducir esa dependencia al mínimo y evitar situaciones absurdas.

El problema que crea el acoplamiento es que te limita la versatilidad del código.

A continuación tenemos un ejemplo de acoplamiento.

class Usuario
{
  public:
    void GuardarUsuario( std::ostream& stream );
};

La clase "Usuario" incluye un método para almacenar en un stream de salida los datos del usuario. ¿Qué sucede si después se decide también volcar esa información a una base de datos? O bien optas por crear un conector de bases de datos que se enlace al ostream o te toca crear un nuevo método para esta nueva tarea... ambas soluciones no son, desde luego, las ideales.

En este caso el acoplamiento se produce porque no se ha respetado lo indicado en el punto anterior acerca de las responsabilidades. Es decir, la clase "Usuario" no solo almacena los datos de un usuario, sino que además se encarga de volcar los datos a un stream...

Da la sensación de que tenemos miedo a crear clases, es como si se nos fuese a ir de las manos. Nada más lejos de la realidad. La programación ha de ser como construir con Lego... tienes fichas pequeñas pero eso no te impide crear estructuras de varias decenas de metros y varias decenas de kilos de peso... en su sencillez radica su potencia... en la programación sucede lo mismo.

15. Evita utilizar const_cast

C++, al igual que C, permite hacer muchas perrerías. Lo siguiente por ejemplo es totalmente válido:

class POO
{
  public:
    void Func( ) const;
 
  private:
    int _dato;
};
 
void POO::Func( ) const
{
  // instruccion no valida
  _dato = 5;
 
  // este codigo no da error, compila y funciona.
  POO* ptr = const_cast< POO* >( this );
  ptr->_dato = 5;
}

Obviamente todos nos podemos imaginar que no es la mejor solución a elegir... para cosas de estas existe el modificador "mutable" o, directamente, darle un par de pensadas al diseño del sistema.

Como norma general, si en una parte del código tenemos un valor o clase constante... dejémoslo así... si resulta que es necesario modificarlo entonces deberíamos quitarle el atributo const, ya que este tipo de códigos complican la lectura del código.

16. Valida SIEMPRE las entradas del usuario

Una gran cantidad, por poner un ejemplo, de portales Web son sensibles a ataques mediante un método conocido como "inyección SQL". Esta vulnerabilidad permite hacer casi cualquier escabechina en el portal.

Otro fallo bastante común, este caso en aplicaciones de escritorio, es el de desbordamiento de buffer... y permite ejecutar código totalmente aleatorio con los mismos privilegios que la aplicación... imagínate si la aplicación tiene privilegios de administrador la que te pueden liar.

Problemas como estos se producen porque un programador "presupone" que el usuario es bueno y siempre va a facilitar la información que se le pide sin intentar tocar las narices. ERROR!!!

Las interfaces de usuario hay que programarlas con la idea en mente de que el usuario va a ser un cab*** despiadado que te va a buscar las cosquillas hasta en el carnet de conducir. Cada entrada a la aplicación, ya sea por teclado, archivo, sockets, ... debe ser validada para evitar problemas.

Por ejemplo, si un dato a pedir es la edad debemos verificar, en primer lugar, que la información facilitada es, efectivamente, numérica... luego ya puede que interese comprobar que está dentro de un rango determinado, pero siempre hemos de asegurar que la información que entra a nuestra aplicación es válida... nos ahorraremos muchos disgustos después.

17. No escribas código en los .h

Puede parecer muy tentador implementar una función tipo getter o setter directamente en la cabecera para ahorrarnos tiempo y código.

El problema que subyace en esta práctica es que si el futuro requiere un cambio en esta función habremos de recompilar todos y cada uno de los archivos dependientes del archivo donde se encuentre... como os podéis imaginar el tiempo empleado puede ser considerable.

En cambio, si el código se encuentra en los cpp solo será necesario recompilar dicho archivo, con el ahorro de tiempo que ello conlleva.

Los compiladores actuales son capaces de hacer optimizaciones que ni nos imaginamos, por lo que no debemos preocuparnos en pensar que poner la implementación en el cpp va a implicar más instrucciones que dejar el código en la cabecera.

Además se consigue una cabecera más limpia... que es lo que normalmente se usa como referencia.

18. Implementa grupos de operadores completos

Si en una clase te ves obligado a implementar, por ejemplo, el operador '>', procura implementar también los operadores '<', '==', '<=' y '>='.

El motivo es que, si te ves obligado a hacer una comparación... no tiene sentido a que te ates a usar una única comparación... puedes encontrarte con situaciones en las que el código sea más cómodo si usas otra comparación diferente. E incluso puede suceder que estos operadores estén ya implementados en una clase padre... no sobrescribirlos en la hija no te va a dar error... pero si puede dar resultados no esperados.

19. Evita códigos "inusuales"

bool resultado = Func( );
 
resultado && Func2( );

bool resultado = Func( );
 
if ( resultado )
  Func2( );

¿Qué opción queda más clara? Espero que al menos la inmensa mayoría digáis la segunda... poco más que añadir al respecto.

El código claro y sencillo facilita su lectura y comprensión y eso reduce el número de horas necesarias para arreglar un problema. No hay que olvidar que en este mundo las horas tienen un coste económico.

20. No uses friend

El uso de 'friend' rompe con cualquier principio relacionado con la programación orientad a objetos que te puedas imaginar.

Si necesitas usar 'friend' es porque la arquitectura elegida es mejorable.

Entre otras cosas, 'friend' se encarga de hacer un acoplamiento bastante fuerte de las clases y eso va a dificultar la aplicación de tests unitarios, por ejemplo.

21. Acostúmbrate a usar repositorios

La época en la que el historial de cambios se almacenaba guardando las copias de seguridad en archivos comprimidos pasó a mejor vida.

En la actualidad dudo que encuentres una sola empresa en la que se trabaje así. La gran mayoría sino todas usan algún tipo de repositorio ( SVN, Mercurial, GIT, ... ). Lo mejor es que te vayas familiarizando con su uso. Lo vas a agradecer.

Como recomendación personal, creo que empezar con Mercurial es una buena opción.

* Te permite crear fácilmente repositorios nuevos
* No tiene un juego de instrucciones especialmente complicado.
* Dispones de portales web ( como BitBucket ) que te permiten almacenar repositorios privados de forma gratuita.

La idea luego sería utilizar repositorios más conocidos, como SVN o git, pero claro, es sólo mi opinión.

---

Y bueno, si tiene buena acogida este hilo lo extenderé con el tiempo... por supuesto, se aceptan comentarios y aportes.