[quoted text, click to view] Marcus wrote:
> Thanks for the help.
> Could work a bit on that attitude though...
Let me address that first.
I'm sorry if I came over offensive, thats not intended.
The external initialization of internal data and the non-use of the .NET
provided resizing collections for data-storage made me think that
perhaps some general OO knowledge would help.
[quoted text, click to view] >>Why are you providing get/set methods to your private data? you might as
>>well declare it public instead
>
> I am providing get/set methods because I am planning that I will
> eventually check data for constraints and other abuse within these
> get/set methods.
You can postpose making get/set untill then. I've found that designing
for the future is usually best done as late a possible.
[quoted text, click to view] >>Why doesn't the AdminSettingsData.AdminSettingsData initialize it's
>>Users property itself, or accept it as an argument?
>
> It could do that, yes. Maybe I will eventually. My app is not 100%
> ready yet (or not even near) so there is still time. Right now
> AdminSettingsData is just a container class for data without any
> methods of its own.
The corner-stone of object oriented programming is the idea that data
and the functions operating on the data should be grouped together in an
object modelling the data and it's interaction with the surroundings.
Initializing the data inside the constructor would be just as easy, and
would leave any constructed object in a well-defined valid state.
Wouldn't the simplest solution be to just have the users as:
[Serializable]
public class User {
public string Name;
public string Password;
public User(string name, string password)
{ this.Name = name; this.Password = password; }
}
[Serializable]
public class AdminSettingsData {
public ICollection<User> Users = new List<User>();
}
Now you can add users by doing:
ICollection<User> users = adminSettings.Users;
users.Add(new User("name", "password"));
and then later write another implementation of the userlist to verify
any constraints on the list of users.
[quoted text, click to view] >>The loop fills Users, with actual TBusers instances, not null. why would
>>you want to do that?
>
> To avoid exceptions when my program tries to access a field in a null
> object.
That exception would expose a programming-error -- which would go
unnoticed if you filled the array with default-initialized Users.
[quoted text, click to view] >>There are no null-entries. You just initialized each entry to a new TBusers
>
> OK, what I meant was the entries that contains objects which
> datamembers are null.
OK. I usually prefer to let classes whose instances require
initialization to have a valid state accept that state in the
constructor. Like in the above class User. That way there is never any
objects not in a valid state.
--
Helge Jensen
mailto:helge.jensen@slog.dk
sip:helge.jensen@slog.dk