Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

OOP, encapsulation and bulk loading

Name: Anonymous 2010-07-04 19:10

So I have this class that represents a thing that can be created or loaded and saved, it's nice and encapsulated - it has a couple of properties that are private with public getters and setters. Nothing special, when I load this thing - properties get set directly, when I create it - I use property setters that do some sanitization and validation.

Now the question. I also, for performance reasons, need to bulk load these things.
1st, where could I put such method? It doesn't really belong on the things class, I mean static <Thing[]>Thing.Load(keys[]) doesn't look right at all.
2nd, how would I initialize these things? I don't want to use the public setters, because, as I mentioned, they do some checking that's necessary only the first time, when I'm loading it from the storage, everything is already sane. I also don't want to expose the properties publicly. Currently I have a constructor that takes all properties and sets them directly, but that's ugly.

Name: Anonymous 2010-07-07 16:30

>>4
I didn't want to add a class just for the sake of one method, but I guess you're right. That seems like a reasonable solution.

OK, so, users can create and edit these things, there's already validation in user interface with friendly error messages, but in case someone got around the GUI, I also do validation with setters and throw exceptions if something isn't right. So the problem is these setters, they assume that data comes from untrusted source, which isn't the case when I'm bulk loading these things (creating a new instance and setting properties). Basically I have two cases, one is when the data comes from user and I need to validate it and other when the data comes from storage and validation should be skipped. I can think of a couple of solutions, but I'm not sure which way to go. 1) I could add a property that specifies whether validation should be done. 2) I could derive user side Thing from internal Thing, where internal doesn't do validation. 3) I could have multiple method for setting properties Thing.SetFoo() and Thing.SetAndValidateFoo(). 4) I could have a constructor that takes all properties and sets them directly (this is what I do currently). 5) I could move validation off the setters and into a Validate() method. What do you think?

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List