1

(Please excuse the level of simplicity in this question, as it is very basic)

I have been working with very simple Object-Orientated Programs and learning basic concepts. For example, my programs would only have one or two objects, each being assigned to a variable.

TStudent student1 = new TStudent();
TStudent student2 = new TStudent();

As you can see in the above program, I have two simple variables (student1 and student2). Each variable stores an object of type TStudent.

My question is, what if I had 1000 students, each with a FName, SName, Address etc. Would I continue on and create 1000 variables? And, would data relating to the properties of these objects (such as their FName, SName, Address etc) be stored in a database?

I hope this makes sense, and I apologize for the simplicity of it. thanks.

1
  • 4
    You should take a look at Lists, Arrays, or any other kind of Collections (depending on the programming language you use). – Andy Sep 19 '16 at 13:48
1

I'd think at that point you might put them into a list or an array or whatever sort of collection. Storing in the database? Sure, if you need to... where else would the info come from? For that matter, how often would you need to have all of these objects loaded in memory at the same time?

Consider this:

var students = new List<Student>();
someDataSource.FillStudentList(students);
// students now has 1000 student objects inside it
// wat do?

Or:

var students = new List<Student>();
students.Add(new Student() { Name = "John Smith" };
students.Add(new Student() { Name = "Mary Smith" };
students.Add(new Student() { Name = "John Doe" };
/// x1000

In what scenario do you expect to "manually" load data like that? Would you expect it to come from the UI? Perhaps from a file upload? What do you need to do with it after?

I guess the point is that there's really any number of ways you could manage this, and whether or not it gets stored in a database is really up to the requirements of the application. Most times, something like this would indeed be stored in a database, after which you would only retrieve the data into an object as it's needed by the application.

Other times, you might upload a file of say, 100k people, and process them accordingly, so there's reasonable cause for dealing with a larger amount of objects as well.

Does this help put things in some perspective?

4
  • Yes, this makes sense. I've studied DB separately and OOP separately, but never 'married' the two concepts in a real working program. As I see it, it would be acceptable practice to use the DB as a data-source for each of my objects as they are created. (I.E my class' methods would pull data from a DB to upload any details such as FName, SName etc...) – user3396486 Sep 19 '16 at 13:56
  • It's about persistence: objects live in memory and represent something. That representation has to come from somewhere. You don't hard code students into an application. Whether it's a database or xml file or whatever, it's a matter of deciding where to put the data, assuming you need to store it. Some apps won't need to store certain data, but for the most part, every single application has to store something... i.e., this is very standard stuff! – jleach Sep 19 '16 at 13:59
  • @jdl134679 - Standard, yes, but don't be too hard on him; I remember my own formal programming education, and while I knew about SQL from back in high school internships, I wasn't writing applications as coursework that used a SQL database as a data store until junior year of college. The systematic education track for programmers assumes nothing, and so things we do every day in the industry are fairly high-level undergrad concepts, because the first two years of higher ed are spent re-teaching things the luckier half of us learned in high school (or earlier). – KeithS Sep 19 '16 at 15:23
  • @KeithS - oh no, didn't mean to sound hard on anyone... just explaining! We've all been there. – jleach Sep 19 '16 at 18:17
0

You're right, there are more advanced ways to handle multiple objects.

TStudent student1 = new TStudent();

This line of code is doing two things. It's constructing an object and it's holding a reference to it. You don't have to do these two things together. You don't have to type them out each time you want to do a different one.

There are creational patterns that help with the construction part. It's a really good idea not to mix construction with behavior. Beyond the GoF creational patterns is the Joshua Bloch builder that hacks named parameters into a language that doesn't have them. This goes as far as writing iDSL's to construct your objects. You can basically write your own language to construct your objects.

As for holding a reference we can do better than a simple identifier. Array's work when you know ahead of time exactly how many there are going to be but most people skip right past them to collections that can grow in size at any time.

They come in a great many flavors. In java I've found this to be a very handy way to decide which to use:

enter image description here

What your line didn't show is how you get the students information into the object.

This can come from many sources, DB, flat file, other objects, web forms, command line input. Because of that it's a good idea to not make it the student objects job to get this input. Far better to to have a simple Student class that's waiting for something to hand it the data. Then write some construction code for each of those cases that hands it the data.

That's called dependency injection and you can do it without any special software.

Not the answer you're looking for? Browse other questions tagged or ask your own question.