The problem is not clear. You are looking for some abstraction technique while you don't have abstract target. I mean that in your exact case you don't really need further abstraction. Here is why: you pass a parameter of the class or structure
Account
. It has five properties you want to append to some string, no more. If this is a class, you can extend it and pass an instance of a derived class, but as your method is written to the base abstract or pseudo abstract class, it can only work with the property of a base class.
The classic OOP approach is that you need to add some virtual method like
AppendPropertyValuesToStringBuilder
and override it in each of the derived classes. In this case, you will move the fragment appending
Name
,
Password
,
Email
,
VerificationCode
and
ActivationStatus
from your
Write_Account
method to each of derived classes where it really belongs, because only the classes know what are their properties. Remember, in each of derived classes you can always call
base.AppendPropertyValuesToStringBuilder
to append the part of data already defined in the base class (where this method is non-abstract). As it leverages the mechanism of
late binding, the method
AppendPropertyValuesToStringBuilder
called by
Write_Account
on a base class as a
compile-time type, will actually be dispatched to call the overridden method of one of the
run-time types to be passed to this method as its argument; and each of those run-time types will be one of the derived classes. This is a heart of classical OOP. Please see:
http://en.wikipedia.org/wiki/Dynamic_dispatch[
^],
http://en.wikipedia.org/wiki/Late_binding[
^],
http://en.wikipedia.org/wiki/Object-oriented_programming[
^].
You really need to fully understand OOP to do any .NET development.
Now, you have some solution, but you need to look at this problem from a different point of view. You don't use appropriate abstraction mechanism not just because you don't know them well, but because your approach to data is questionable. Your property appending code tells me that you are trying to work with string presentation of data instead of data itself. Yes, there are places where you need to show some data in the string form; on the screen, for example. But this should be totally isolated from data itself. Just think about it.
And finally, your code has one critical problem. In your exception catch handler, you totally block exception propagation. As a rule of thumb, you should not do it. Let exception go. You can finally catch all exceptions only on the top of the stack of each thread. By blocking exception propagation, you effectively defeat the purpose of structural exception handling. You really need to learn the basics of exception handling. The pain purpose of it is to avoid dealing with exception in almost all of your code. The mechanism isolates exceptional situation from the regular operation, so you can forget about them in most of your work. Please see:
http://en.wikipedia.org/wiki/Exception_handling[
^].
Please also see my recommendations in my past answers:
How do i make a loop that will stop when a scrollbar reaches the bottom[
^],
When i run an application an exception is caught how to handle this?[
^],
throw . .then ... rethrowing[
^],
Error Logging and Screen Shot.[
^],
Catching an Exception[
^],
Handling exceptions in class library (dll)[
^].
—SA