Click here to Skip to main content
15,504,830 members

Comments by C Pottinger (Top 15 by date)

C Pottinger 17-Feb-22 15:26pm View    
I don't see how that would stop a user of the class from using the wrong constructor.
C Pottinger 17-Feb-22 15:24pm View    
'IConfigurable is missing a "Name"'
Actually, no. That was the idea. IConfigurableShape would not expose Name, but IDisplayOnlyShape would.

'IConfigurable maybe should inherit IReadOnly instead'
I think you might have meant to say 'IDisplayOnlyShape would...'. That is the "read-only" interface. Perhaps my example was not clear.

Despite that, you have offered what I think will be best solution: by having 2 private constructions, each called by different static factory methods. I can then have IConfigurableShape expose one method and IDisplayOnlyShape expose the other, thus limiting the use of the constructors.
THANK YOU.

However, PIEBALDconsult's comment above still holds true - I can't stop a user from casting from one type to another. Still, a little control is better than none.
C Pottinger 11-Feb-22 15:24pm View    
I see your point. Thank you for the speedy reply.
In the future I will stick with creating two derived classes, but for this project, I will continue with the above structure and run the risk of being taken out by a Predator drone.
C Pottinger 13-Aug-21 15:14pm View    
I see what you are saying, but
a) I put production in quotes because what I really wanted to refer to was my 'program code' as opposed to my 'testing code'. I think my program code should not have to know anything about my testing code.
b) #DEFINE would be fine to separate my debugging code from my final code. But even if I did that, I would still have the issue that my program code contains knowledge of my unit tests.
c) Even with conditional compilation, I would still run into the issue that Assembly.GetTypes() would pick up types dynamically generated by Moq whenever I unit test.
C Pottinger 13-Aug-21 15:06pm View    
Thanks Richard. But that does seem like an awful lot of work to go through just to not have Moq interfere with Assembly.GetTypes().

In the end, it turned out I had to refactor my code, for unrelated reasons, and in doing so it allowed me to use dependency injection to provide a class that does the actual loading of the Types from a dll. I can now mock this new IPluginTypesLoader interface and avoid calling System.Reflection.Assembly.GetTypes() from within my unit tests.