I went though the code last night and found serveral issues with the code. Such as the event system is not correctly setup as CLR standards say. First off they are protected not internal. Also they are virtual so that any class that derives of this class will be able to handle the even itself.
Also the use of the keyword internal is overly used. as this is the same as friend in C++. However it really isn't OOP as it violates the very idea. Beyond that internal allows any code that is compiled along with your also can access those variables. It is preferred to have them private and public accessing methods/properties.
While you also do not take advantage of OOP as you do not encapsulate any classes correctly so that they can be used in other langauges. Such as your collections you allow direct access from your MailMessage class to the ArrayList of RCPTs. I beleive this is poor design. As you could create a class that holds that that dirves of IEnumerator
Then allow Add,Remove,Current methods along with an indexer. And moveover a properties that correctly encapsulate the data. So that it can not be modified directly by classes compile with it.
Just some suggestions on how to improve on design.
Hopefully this will help a bit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The use of internal actually speeds up calls from within the namespaces. If you look at decompiled IL you'll see this removes and extra call. BUT every internal field has a public equivalent for callers. I know its prefered to keep them private in true OOP blackbox fashion but in this case I think the need for performance outweighed that. Just wanted to calrify why I chose that.
But your other suggestions make a lot of sense. In the next release I will take all of this into consideration and make appropriate changes. Thanks for taking the time to look over the code. Every bit of help counts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I went though the code last night and found serveral issues with the code. Such as the event system is not correctly setup as CLR standards say. First off they are protected not internal. Also they are virtual so that any class that derives of this class will be able to handle the even itself.
Also the use of the keyword internal is overly used. as this is the same as friend in C++. However it really isn't OOP as it violates the very idea. Beyond that internal allows any code that is compiled along with your also can access those variables. It is preferred to have them private and public accessing methods/properties.
While you also do not take advantage of OOP as you do not encapsulate any classes correctly so that they can be used in other langauges. Such as your collections you allow direct access from your MailMessage class to the ArrayList of RCPTs. I beleive this is poor design. As you could create a class that holds that that dirves of IEnumerator
Then allow Add,Remove,Current methods along with an indexer. And moveover a properties that correctly encapsulate the data. So that it can not be modified directly by classes compile with it.
Just some suggestions on how to improve on design.
Hopefully this will help a bit.
I'll take this all into consideration.
The use of internal actually speeds up calls from within the namespaces. If you look at decompiled IL you'll see this removes and extra call. BUT every internal field has a public equivalent for callers. I know its prefered to keep them private in true OOP blackbox fashion but in this case I think the need for performance outweighed that. Just wanted to calrify why I chose that.
But your other suggestions make a lot of sense. In the next release I will take all of this into consideration and make appropriate changes. Thanks for taking the time to look over the code. Every bit of help counts.