views:

83

answers:

2

I'm trying to fix a design flaw that I recently ran across in some of our software without re-writing the entire thing. There is a .exe which has a message listener thread that is receiving data from some server, and then writing it to a class in a seperate DLL (we'll call it StaticDataClass) that is storing all of the data it receives (mostly static pulled from a database on startup). This class also provides methods that other classes can use to retreive the data. The problem is that the store (set) methods are all public, so any other class can overwrite this data and break the whole application. What is a good way for me to protect the data (make the set/store methods invisible) to all objects except for those contained with the executable itself?

Right now I'm toying with an interface that defines only the public getters, and then having a singleton class implement that interface and then the Instance property will return the interface type so they will only be able to use the get methods declared in the interface. But when the executable starts up, it will somehow get an actual reference to the StaticDataClass object and not the interface type, so it will be able to call the store/set methods as well.

This isn't totally full proof, but it prevents some developer who isn't familiar with the system from think it's ok to use these public storage methods because Visual Studio intellitype makes them visible when they are coding. Instead, they will have to try to break it by casting the object as the type which contains the store methods.

Is there a cleaner way to do this?

+4  A: 

You could make the set methods internal, and use InternalsVisibleToAttribute to grant access to the favoured executable.

itowlson
This sounds like it has potential, I will try it. Thanks.
alexD
Looks like it works...this is simpler than any solution I had hoped for!
alexD
A: 

I agree - making the internals visible to the trusted assembly sounds like the easiest way to achieve what you want to do.

FinnNk