Closed GoogleCodeExporter closed 8 years ago
So you're saying we should derive a class from EncryptDialog, named
EncryptGenericDialog.
In that class we add the key field (which is in fact the only difference with
EncryptDialog).
We can use a pure virtual function that validates the key, and reimplement that
function in every child class.
I find this a good idea, because we will certainly add more algorithms using
this kind of dialog in the future. Therefore I've changed the priority to
medium.
Original comment by Divendo1180@gmail.com
on 25 Jan 2012 at 9:01
Come to think about it, we don't even need to make that class. We just include
in encryptdialog, because after all, every encryption will need a key right?
What troubles me is that we have so much boilerplate code in the constructors
of its derivatives...
Original comment by xander.deseyn
on 25 Jan 2012 at 9:34
Not every algorithm needs the same type of key.
RSA for example requires two integers, while Vigenère (as we know) requires a
password.
So the key validation function can go in EncryptionDialog.
The creation of the key input field should go in a child (e.g.
EncryptGenericDialog).
By the way, not every encryption algorithm requires a key.
We may want to implement hash algorithms (MD5, SHA1, etc) in the future, these
don't require a key.
Original comment by Divendo1180@gmail.com
on 25 Jan 2012 at 9:57
Solution: the EncryptDialog class and the EncryptionAlgorithm class should be
merged.
This way each algorithm will be implemented in one class, which includes the
dialog for the algorithm and the algorithm itself.
For algorithms that are a lot like each other (e.g. XOR and Vigenère) we can
create another abstract class first from which these algorithms will derive.
Original comment by Divendo1180@gmail.com
on 12 Feb 2013 at 4:31
Fixed in r22
Original comment by Divendo1180@gmail.com
on 12 Feb 2013 at 6:46
Original issue reported on code.google.com by
xander.deseyn
on 25 Jan 2012 at 7:01