Es muy poco probable que se obtenga algo con este ejercicio. El buen código C ya es más modular de lo que normalmente puede ser C++: el uso de punteros a estructuras permite que las unidades de compilación sean independientes en el mismo modo que lo hace pImpl en C++; en C no es necesario exponer los datos dentro de una estructura exponer su interfaz. Así que si a su vez cada función C
// Foo.h
typedef struct Foo_s Foo;
int foo_wizz (const Foo* foo, ...);
en una clase de C++ con
// Foo.hxx
class Foo {
// struct Foo members copied from Foo.c
int wizz (...) const;
};
se le han reducido la modularidad del sistema en comparación con el código C - cada cliente de Foo ahora necesita reconstruir su caso las funciones de implementación privadas o las variables miembro se agregan al tipo Foo.
Hay muchas cosas que las clases en C++ le dan, pero la modularidad no es una de ellas.
Pregúntele a su jefe cuáles son los objetivos comerciales que se logran con este ejercicio.
Nota sobre la terminología:
Un módulo en un sistema es un componente con una interfaz bien definida que puede ser reemplazado con otro módulo con la misma interfaz sin afectar al resto del sistema. Un sistema compuesto de tales módulos es modular.
Para ambos idiomas, la interfaz de un módulo es por convención un archivo de encabezado. Considere string.h y string como la definición de las interfaces para los módulos simples de procesamiento de cadenas en C y C++. Si hay un error en la implementación de string.h, se instala una nueva libc.so. Este nuevo módulo tiene la misma interfaz, y todo lo que se vincule dinámicamente con él se beneficia inmediatamente de la nueva implementación. Por el contrario, si hay un error en el manejo de cadenas en std::string, entonces cada proyecto que lo use debe ser reconstruido.C++ introduce una gran cantidad de acoplamiento en los sistemas, que el lenguaje no hace nada para mitigar; de hecho, los mejores usos de C++ que explotan completamente sus características a menudo están mucho más unidos que el código C equivalente.
Si intentas hacer C++ modular, normalmente terminas con algo como COM, donde cada objeto tiene que tener tanto una interfaz (una clase base virtual pura) como una implementación, y sustituyes una indirecta por una plantilla eficiente generada código.
Si no le importa si su sistema está compuesto por módulos reemplazables, entonces no necesita realizar acciones para hacerlo modular, y puede usar algunas de las características de C++ como clases y plantillas que , adecuado aplicado, puede mejorar la cohesión dentro de un módulo. Si su proyecto es producir una única aplicación enlazada estáticamente, entonces no tiene un sistema modular, y puede permitirse no preocuparse en absoluto por la modularidad. Si desea crear algo como anti-grain geometry, que es un bello ejemplo del uso de plantillas para acoplar diferentes algoritmos y estructuras de datos, entonces necesita hacer eso en C++, bastante bien, nada más difundido es tan poderoso.
Tenga mucho cuidado con lo que su gerente quiere decir con 'modularización'.
Si cada archivo ya tiene "su propio propósito y función" y "cada función en el programa pasa un puntero a una de las estructuras", entonces la única diferencia en cambiarlo en clases sería reemplazar el puntero a la estructura con el puntero implícito this. Eso no tendría ningún efecto en la modularización del sistema, de hecho (si la estructura solo se define en el archivo C en lugar del encabezado) reducirá la modularidad.
+1 Ese gran suspiro colectivo que acaba de escuchar fue la gran cantidad de usuarios de SO que trabajan con código heredado ... –
O bien refactorizarlo en C bien estructurado, o reescribirlo en C++ idiomático. Intentar forzar a C malo a utilizar algún tipo de lenguaje híbrido le dará los problemas de mantenimiento de ambos idiomas, y pocos de los beneficios de ninguno de ellos. –
Definitivamente hablaría con su jefe sobre la reescritura del programa –