C# Object Oriented Programming

IntoTheVoid

IntoTheVoid

IntoTheVoid

Associate
Joined
31 Dec 2002
Posts
458
Hi,

I have just started to dive into learning OOP with C#. Getting to grips with creating Classes, Constructors, Properties and Methods etc.

However I could do with a nudge conceptually. Say you had an application using employee objects how would you keep track of multiple employees. Also how would you retrieve specific instances of an employee and make changes? would you save the state of an object to a database? and then retrieve it from there? or would you also use collections such as an arraylist?

Say the user creates a user account and enters their details how would the application instantiate an Employee object dynamically? without explicitly declaring it in the application?

Sorry for all the questions but OOP is a bit of a leap!!!!

Cheers.
 
Eisenhorn said:
Hi,

I have just started to dive into learning OOP with C#. Getting to grips with creating Classes, Constructors, Properties and Methods etc.

However I could do with a nudge conceptually. Say you had an application using employee objects how would you keep track of multiple employees. Also how would you retrieve specific instances of an employee and make changes? would you save the state of an object to a database? and then retrieve it from there? or would you also use collections such as an arraylist?
Click to expand...
Yes you would use a list or array or an observeablecollection or similar depending what you want to do with it.
So basically you could have something like


List<employer> employerList = new List<employer>();
public void AddEmployerToList(employer e)
{
employerList.Add(e);
}

public employer GetEmployerByIndex(int i)
{
return employerList;
}

public void test()
{
//1st lets make an new employer say from a pretend form
var emp = new employer();
emp.Employername = textbox1.text;
emp.Address - textbox2.text;


//now we can add it to the list
employerList.Add(emp);


//Check its in the list

if (employerList.Count() >0)
{
MessageBox("You have put " + GetEmployerByIndex(0).EmployerName);
}
}


Say the user creates a user account and enters their details how would the application instantiate an Employee object dynamically? without explicitly declaring it in the application?

Sorry for all the questions but OOP is a bit of a leap!!!!

Cheers.
Click to expand...

Sort of like the above.
Although im sure some one else will come along with some better examples. Are you using .Net?
 
A database would be the best place to store your objects. Take a look at Entity Framework: Code First when you get a chance. It's a framework for storing and retrieving your classes in a DB.
 
Hi thanks for the quick replies, appreciate it. I am using .NET and Visual Studio 2013 through VMWARE Fusion. I have an iMac and have also been playing with Xamarin and Java.
 
One thing that baffles me is how would you get all of an Employee objects associated properties. Say you had name, age, job role, age for each employee. Would you need to keep track of the list index number for each employee and then work with that?
 
So going back to make changes to a hypothetical employee named Joe Bloggs that is stored in index 0 of the employeeList list would be something like:

Code: 
if (employeeList[0].name == "Joe Bloggs")
{
employeeList[0].jobrole = "Department manager";
employeeList[0].salary = "45000";
employeeList[0].leave = "35";
employeeList[0].appraisal = "Excellent";

}
 
Eisenhorn said:
So going back to make changes to a hypothetical employee named Joe Bloggs that is stored in index 0 of the employeeList list would be something like:

Code: 
if (employeeList[0].name == "Joe Bloggs")
{
employeeList[0].jobrole = "Department manager";
employeeList[0].salary = "45000";
employeeList[0].leave = "35";
employeeList[0].appraisal = "Excellent";

}
Click to expand...
Another vote for entity framework here.
Yes that would change the properties on that object. Although its more likely you would not do it directly like that but do something like select employee from the list 1st then change it, are you planning to use mvvm?
 
Hi sorry have not heard of MVVM, will take a look. Just been reading about Entity Framework, it looks really interesting. Regarding you mentioning selecting the employee from the list first before making changes, how would you do this? i.e. instantiating that specific instance again? would it be something like:

Code: 
Employee retrievedEmployee;
retrievedEmployee = employeeList[0];
retrievedEmployee.salary = int.Parse(txtSalary.Text);

What I do not understand is if the list had a datatype of Employee objects how would you grab an object from it, or would you have to recreate as above?
 
Last edited:
Eisenhorn said:
Hi sorry have not heard of MVVM, will take a look. Just been reading about Entity Framework, it looks really interesting. Regarding you mentioning selecting the employee from the list first before making changes, how would you do this? i.e. instantiating that specific instance again? cheers.
Click to expand...

So you would have a property like selectedEmployee
Then when you have chosen the employee to edit you set selected employee to that object.
Something else to read about is linq. This will allow you to do
SelectedEmployee =EmployeeList.where(e => e.FirstName == "Joe" && last name == "bloggs").First();

Then you can just do selectedemployee.taxcode = "4x"

And since it is the same object as in the list it wont need updating there.
Hope that makes sense, I'm typing on phone in the sun.
Mvvm is a methodology to make data driven programs which helps seperate the data access from the ui.

Edit :your last snippet doesn't revreate the object, it is the same object
E.g
Employer emp =new employer ()
emp.name = "Joe"
Employer emp2 = emp;
Emp2.name ="Pete";

Print emp.name would show Pete not joe
 
Last edited:
Eisenhorn said:
I see now, you changed the reference with emp2 pointing to the emp object. So any changes made to either emp or emp2 would update the same object. I think !!!!
Click to expand...

Yup
So Employer emp =new employer ()
emp.name = "Joe"
Employer emp2 = emp;
Emp2.name ="Pete";

emp == emp2 is true

Employer emp3 =new employer ()
emp3.name = "Joe"


Emp == emp3 is false because even though they store the same data they are not the same object.
 
Haircut said:
Being really pedantic I'll point out that that's only true if Employer is a reference type :p
Click to expand...

Good point.
For Eisenhorn this means if it was a value type such as char or int it doesnt behave this way.
Such as

int i = 66;
int j = 45;
i = j;
j = 44;


i == j would return false;
i == 45 would return true;
j == 44 would return true;

Link
http://msdn.microsoft.com/en-us/library/t63sy5hs.aspx
 
Not to hijack the thread but it intrigued me as to why you would be better holding individual instances of classes in a database over say a dictionary?

I admit I'm a bit old school but wouldn't you only want to hold them in a database once everything was ready to commit them (i.e. by some user event pressing save or what not)?

I'm of the variety that you only make a call to a db as and when you need data from it or need to write verified data to it.
 
Stupid Question Alert;

Code: 
Is this all the code needed to write the entire object to the database?

Contact con = new Contact();
con.fname = TextBox1.Text;
con.lname = TextBox2.Text;
con.phone = TextBox3.Text;

ContactsDb db = new ContactsDb();
db.Contacts.AddObject(con);
db.SaveChanges();

No SQL actually needs written?

[URL="http://www.codeproject.com/Articles/363040/An-Introduction-to-Entity-Framework-for-Absolute-B"]The code is from this article[/URL]

Thanks,

Blackvault
 
Blackvault said:
Stupid Question Alert;

Code: 
Is this all the code needed to write the entire object to the database?

Contact con = new Contact();
con.fname = TextBox1.Text;
con.lname = TextBox2.Text;
con.phone = TextBox3.Text;

ContactsDb db = new ContactsDb();
db.Contacts.AddObject(con);
db.SaveChanges();

No SQL actually needs written?

[URL="http://www.codeproject.com/Articles/363040/An-Introduction-to-Entity-Framework-for-Absolute-B"]The code is from this article[/URL]

Thanks,

Blackvault
Click to expand...

Not sure if that code is 100% right but yes entity framework handles much of the sql for you, you may have to write some if you want to do some complex stored procedures and such but the savechanges should write the insert/update statement as needed.
Neat aint it.
 
meandu229 said:
Not sure if that code is 100% right but yes entity framework handles much of the sql for you, you may have to write some if you want to do some complex stored procedures and such but the savechanges should write the insert/update statement as needed.
Neat aint it.
Click to expand...

My mind has just been blown! I've got lots of Insert SQL statements written for my MySQL database. Time to scrap those and look at Entity framework then.

Thanks,

Blackvault
 
You must log in or register to reply here.
Back
Top Bottom