CODEWITHSUNDEEP
c#formsclass
NootyToot
NootyToot

Reputation: 13

Using classes with forms

I'm trying to understand whether or not it is correct to use a class when entering data into a form. I am unsure whether my understanding is correct, I don't know if I should be trying to create a new object when entering the data, or if my data should be stored in an array/file etc.

This is just for my understanding, I am just learning for myself, so don't have a specific example of what I'm trying to achieve. I am trying to understand classes, and when to use them, currently I'm messing about with c# forms in visual studio

lets say, I want to enter information into a form of all of the members of my fishing club, i.e. name, address, contact info etc. should I be attempting to create a new object of a class that contains methods for getting/setting these variables, or should I be storing these details somewhere else, in an array, or write them to a text file/excel file for example? As I'm new I think I'm struggling with the concept of classes and where to use them.

I expect that to use a class for this purpose I would have to learn to create a class instance at run time in order to create multiple instances of a class, whereas entering the data into an array I would just need to initialize the size of the array.

I'm a bit lost so any help would be very much appreciated.

Upvotes: 0

Views: 485

Answers (1)

BradleyDotNET
BradleyDotNET

Reputation: 61369

  • Should you store those fields in objects? Yes
  • Should those objects be stored in a collection (like an array)? Yes
  • Would persisting that collection to a file make sense? Yes

Basically, you are asking to choose an alternative among things that aren't really comparable, much less mutually exclusive. As the comments suggest, make sure to read up on object oriented programming, but here's a quick explanation of each of the above:

Objects provide a structured way to store information (giving each field a name and a type, for starters) and a way for the language/compiler to enforce that structure. Storing all the related data for an entity in an object is a great idea, you almost never want to have a bunch of members for that purpose.

Arrays or more generally, collections, are groups of "things". You could have stored all that information in an array instead of an object (and then for multiple records had "parallel" arrays" but this is a very messy and amateur technique). A collection of your objects however, is a totally reasonable thing to do (you don't want object1, object2, object3 variables in your code).

Files are important because both objects and collections (which are, in and of themselves, objects) are stored in memory, they will go away when the application closes. Files (and similar, like databases) give you a way to persist them (hence such techniques being referred to as a "persistence" layer). You can then load the persisted data into a new instance of your program (say if the user restarts the computer).

Side note: Should I make methods for getting/setting these variables? No.

Just use properties (ie, public string Address {get; set;}). They provide both a backing field (at least with an auto property like the above) and are syntactic sugar for both get and set methods (which you can override with a "full" property).

As a bonus, if using WPF you can automate the population of properties from UI with data binding, but that's a question for another day :).

Upvotes: 2

Related Questions