2 ms·
Sounds similar to Powershell's SecureString, if you want to compare vs a non-"toy" equivalent.
by Hjfrf 5y ago
Sounds similar to Powershell's SecureString, if you want to compare vs a non-"toy" equivalent.
- LadyCailin 5y agoIn isolation, yes, but my version is a subclass of string, which adds another layer of functionality on top of the base feature set.
- javajosh 5y agoI fear that this design violates the so-called "substitution principle", which states you should be able to use instances of a subclass anywhere instances of the parent class are used. In this case, you have defined a default behavior, but I would argue it's degenerate, because the value of your subclass are all the same. In general, it's better to design subclasses to be constrained versions of the parent. If you want to add functionality to a class you're better off using another technique like composition, or even just a simple utility method. Another way to state the issue here is that a user of an encrypted string will always need to know that it is an encrypted string because the only thing cyphertext is useful for is feeding the decryption algorithm.
- catlifeonmars 5y agoI don’t really see the value in considering it a subclass of a string. Without decryption, the only meaningful “string-like” operations on it are equality (well, even that’s assuming that like strings share encrypted values, or equality is stored in a separate property). Why even make it a subclass of string in the first place?