Open fedemgp opened 3 years ago
el encoder_init
creará una encoder protocol correspondiente al método que le pasen, inicializará las estructuras que correspondan, y el método encode hará algo parecido a lo siguiente:
encoder_encode(encoder_t *self, char *msg, size_t len) {
switch(self->mode) {
case CESAR:
encoder_vigenere_encode((encoder_vigenere_t *) self->encoder_protocol, msg, len);
// etc...
}
}
¿ Hay formas mas limpias de hacerlo? si, podrías usar punteros a funciones, pero con esto te sobra.
Si tomás el cámino de hacerte el tda string y cargar todo a memoria, no sería estrictamente necesario los TDA vigenere, cesar y rc4 porque con lo que tenés te sirve, pero no está bien encapsulado (y se te bajará 1 punto por eso). ¿Por qué está conceptualmente mal dejar este tda así como está? porque no es escalable.
Supongamos que me interesaría agregar 3 métodos nuevos: RSA, DES y 3DES. Para hacer esto, debería crear mas funciones privadas en este TDA, haciendo que el archivo crezca bastante y se haga dificil de leer (a nadie le gusta ver un .c de 200+ lineas con lógica mezclada entre distintos entes que son independientes). Si hubiera un buen encapsulamiento de los objetos, tendrías un .c por cada método, teniendo todo el código autocontenido en su tda.
https://github.com/nazar9318/taller1-2c2020-TP1/blob/a61b543a3d047f948c663c43f2d1376f00826091/common_encoder.c#L55-L69
Si hacés el cambio que te pedí acá tené en cuenta de que si tomás el camino 2 (vas procesando de a 64 bytes) vas a tener que modificar la lógica que hay acá, ya que vas a querer conservar un estado de rc4. Esto también denota una falta de encapsulamiento. Podrías tener 3 tda mas: cesar, vigenere, rc4. Tu tda encoder tendría la siguiente forma