A simple employee class : OOP Study

[RSH]

I am really trying to grasp the concept of OOP as it applies to C#.

I am looking at trying to set up a simple Employee Class but I am having
trouble conceptualizing what this class should look like. I was hoping
someone might be able to simply outline what I envision my class to look
like:

Basically I am envisioning a Class called Employee:

I imagine it would have many properties(?) such as:
EmployeeID
LastName
FirstName
Address
City
State
ZipCode
etc.

I imagine I would have AddNew(), Update(), Delete() methods.

Is this a good place to utilize a class? If so what would the basic
infrastructure look like for the class?

I have been through several tutorials but they are very basic and use things
like Dogs and firehydrants as object examples which don't translate well
into business object uses.

Sorry for the basic question.

I greatly appreciate any responses.
RSH

[RCS]

First thing that comes to mind, is you should really have a class, that does
nothing but contain all of your employees, called Employees - that class
would have an "indexer" to get to the actual employees.. and it's in this
class, that you'd have an Insert()/Update()/etc..

In other words, the Employee class would contain all the information about
exactly one employee. Then, another class, called Employees, could contain
links to instances of Employee classes, filled out with the specific
information for each person.

Does that help?

"RSH" <wa*************@yahoo.com> wrote in message
news:e5**************@TK2MSFTNGP15.phx.gbl...

I am really trying to grasp the concept of OOP as it applies to C#.

I am looking at trying to set up a simple Employee Class but I am having
trouble conceptualizing what this class should look like. I was hoping
someone might be able to simply outline what I envision my class to look
like:

Basically I am envisioning a Class called Employee:

I imagine it would have many properties(?) such as:
EmployeeID
LastName
FirstName
Address
City
State
ZipCode
etc.

I imagine I would have AddNew(), Update(), Delete() methods.

Is this a good place to utilize a class? If so what would the basic
infrastructure look like for the class?

I have been through several tutorials but they are very basic and use
things like Dogs and firehydrants as object examples which don't translate
well into business object uses.

Sorry for the basic question.

I greatly appreciate any responses.
RSH

[RSH]

That makes a lot of sense but what would that basic structure look like?

I'm trying to understand what the code would look like. I'm having a tough
time going from conceptualization to code. For example does each property
of an employee (or field) have to be set like (that would be a lot of code
for a typical Employee table!):
private int employeeId;
public int EmployeeID
{
get
{
return employeeId;
}
set
{
employeeId = value;
}
}

private int lastName;
public int LastName
{
get
{
return lastName;
}
set
{
lastName= value;
}
}
etc.....

"RCS" <rs****@gmail.com> wrote in message
news:EC****************@newssvr22.news.prodigy.net ...

First thing that comes to mind, is you should really have a class, that
does nothing but contain all of your employees, called Employees - that
class would have an "indexer" to get to the actual employees.. and it's in
this class, that you'd have an Insert()/Update()/etc..

In other words, the Employee class would contain all the information about
exactly one employee. Then, another class, called Employees, could contain
links to instances of Employee classes, filled out with the specific
information for each person.

Does that help?

"RSH" <wa*************@yahoo.com> wrote in message
news:e5**************@TK2MSFTNGP15.phx.gbl...

I am really trying to grasp the concept of OOP as it applies to C#.

I am looking at trying to set up a simple Employee Class but I am having
trouble conceptualizing what this class should look like. I was hoping
someone might be able to simply outline what I envision my class to look
like:

Basically I am envisioning a Class called Employee:

I imagine it would have many properties(?) such as:
EmployeeID
LastName
FirstName
Address
City
State
ZipCode
etc.

I imagine I would have AddNew(), Update(), Delete() methods.

Is this a good place to utilize a class? If so what would the basic
infrastructure look like for the class?

I have been through several tutorials but they are very basic and use
things like Dogs and firehydrants as object examples which don't
translate well into business object uses.

Sorry for the basic question.

I greatly appreciate any responses.
RSH

[JoSkillz]

I hate to tell you this RSH but it is going to take allot of code with
whatever endeavor you choose. OOP is not a cookie cutter practice it
requires patience and diligence on your part to be fully implemented.
Having to write property accessor for your fields (gets; sets;) is just
something that comes with the territory of programming. There are
several add-ins you may add to VS that can short-cut the implementation
of the field accessor but in the end you will have to write code. If
you are using VS 2005 you can use the "prop" snippet and it will write
some of the accessor code for you. If you are using VS 2003 I
encourage you to look at
ReSharper(http://www.jetbrains.com/resharper/). It creates field
accessor and a whole lot more.

Happy Coding!

[Joanna Carter [TeamB]]

"RSH" <wa*************@yahoo.com> a écrit dans le message de news:
e5**************@TK2MSFTNGP15.phx.gbl...

| I am looking at trying to set up a simple Employee Class but I am having
| trouble conceptualizing what this class should look like. I was hoping
| someone might be able to simply outline what I envision my class to look
| like:
|
| Basically I am envisioning a Class called Employee:
|
| I imagine it would have many properties(?) such as:
| EmployeeID
| LastName
| FirstName
| Address
| City
| State
| ZipCode
| etc.

You can start by having a simple class that is mainly just data; there would
be very few methods for an entity like an Employee :

public class Employee
{
private int id;
private string lastName;
...

public int ID
{
get { return id; }
set { id = value; }
}

public string LastName
{
get { return lasName; }
set { lastName = value; }
}

...
}

| For example does each property
| of an employee (or field) have to be set like (that would be a lot of code
| for a typical Employee table!):

This is the correct way to declare a class. You should not be trying to
write classes that wrap tables; rather you should design classes first and
then design tables to support storing instances of those classes. Classes
are not meant to be just wrappers for database tables, they can also have
behaviour; in this case though there is very little code to associate with
an Employee.

| I imagine I would have AddNew(), Update(), Delete() methods.

These methods are not part of an Employee class, they actually belong in
more than one other class.

e.g.

If you are using C# 2.0 then you would use a generic list like :

List<Employee> employees = new List<Employee>();

But if you are using .NET 1.0 then you need to declare your own typesafe
list classes.

public class EmployeeList
{
private ArrayList employees = new ArrayList();

public Employee AddNew()
{
Employee newItem = new Employee();
employees.Add(newItem);
return newItem;
}

public void Delete(Employee item)
{
employees.Remove(item);
}

...
}

public class DataLayer
{
public void Update(object item)
{
// handle data updating into database
}
}

| Is this a good place to utilize a class? If so what would the basic
| infrastructure look like for the class?

Classes represent business or other concepts, you can't design any software
in C# without using classes. To demonstrate the mixture of properties and
methods in a class, look at this example of a Sales Order :

public class Product
{
...
public string Code {...}
public string Description {...}
public float UnitPrice {...}
}

public class OrderLine
{
private int quantity;
private Product product;

public int Quantity {...}
public Product Product {...}
public float Total
{
get { return product.UnitPrice * quantity; }
}
}

So you get code that works on data to give you claculated totals or other
behaviour as well as just data. Think about the DataLayer class where most
of the class will be methods that talk to a database and there would be very
few private fields holding data in memory.

| Sorry for the basic question.

We all had to start somewhere :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[RSH]

Oh dont get me wrong I understand it takes code i was just wondering if I
was doing it correctly or not. Since all the examples I'm finding talk
about Dogs or Cars with 3 properties it is hard to know if in the real world
defining 70+ properties is realistic or if I am using the wrong tool for the
job. My problem is not the amount of coding required, it is more of trying
to understand the structure of a real world OOP example and since I am
looking at a basic real world business example, I have a database that
houses our employees which have 75 fields so I figured i would start with
that as an exersize.

Thansk,
RSH

"JoSkillz" <oc*****@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

I hate to tell you this RSH but it is going to take allot of code with
whatever endeavor you choose. OOP is not a cookie cutter practice it
requires patience and diligence on your part to be fully implemented.
Having to write property accessor for your fields (gets; sets;) is just
something that comes with the territory of programming. There are
several add-ins you may add to VS that can short-cut the implementation
of the field accessor but in the end you will have to write code. If
you are using VS 2005 you can use the "prop" snippet and it will write
some of the accessor code for you. If you are using VS 2003 I
encourage you to look at
ReSharper(http://www.jetbrains.com/resharper/). It creates field
accessor and a whole lot more.

Happy Coding!

[RSH]

Joanna,

WOW thanks for your response!

For fear of sounding even more basic...you mention the data Layer Class...
would this be in the same physical C# class file? or would this be another
set of file(s)?


"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

"RSH" <wa*************@yahoo.com> a écrit dans le message de news:
e5**************@TK2MSFTNGP15.phx.gbl...

| I am looking at trying to set up a simple Employee Class but I am having
| trouble conceptualizing what this class should look like. I was hoping
| someone might be able to simply outline what I envision my class to look
| like:
|
| Basically I am envisioning a Class called Employee:
|
| I imagine it would have many properties(?) such as:
| EmployeeID
| LastName
| FirstName
| Address
| City
| State
| ZipCode
| etc.

You can start by having a simple class that is mainly just data; there
would
be very few methods for an entity like an Employee :

public class Employee
{
private int id;
private string lastName;
...

public int ID
{
get { return id; }
set { id = value; }
}

public string LastName
{
get { return lasName; }
set { lastName = value; }
}

...
}

| For example does each property
| of an employee (or field) have to be set like (that would be a lot of
code
| for a typical Employee table!):

This is the correct way to declare a class. You should not be trying to
write classes that wrap tables; rather you should design classes first and
then design tables to support storing instances of those classes. Classes
are not meant to be just wrappers for database tables, they can also have
behaviour; in this case though there is very little code to associate with
an Employee.

| I imagine I would have AddNew(), Update(), Delete() methods.

These methods are not part of an Employee class, they actually belong in
more than one other class.

e.g.

If you are using C# 2.0 then you would use a generic list like :

List<Employee> employees = new List<Employee>();

But if you are using .NET 1.0 then you need to declare your own typesafe
list classes.

public class EmployeeList
{
private ArrayList employees = new ArrayList();

public Employee AddNew()
{
Employee newItem = new Employee();
employees.Add(newItem);
return newItem;
}

public void Delete(Employee item)
{
employees.Remove(item);
}

...
}

public class DataLayer
{
public void Update(object item)
{
// handle data updating into database
}
}

| Is this a good place to utilize a class? If so what would the basic
| infrastructure look like for the class?

Classes represent business or other concepts, you can't design any
software
in C# without using classes. To demonstrate the mixture of properties and
methods in a class, look at this example of a Sales Order :

public class Product
{
...
public string Code {...}
public string Description {...}
public float UnitPrice {...}
}

public class OrderLine
{
private int quantity;
private Product product;

public int Quantity {...}
public Product Product {...}
public float Total
{
get { return product.UnitPrice * quantity; }
}
}

So you get code that works on data to give you claculated totals or other
behaviour as well as just data. Think about the DataLayer class where most
of the class will be methods that talk to a database and there would be
very
few private fields holding data in memory.

| Sorry for the basic question.

We all had to start somewhere :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

"RSH" <wa*************@yahoo.com> a écrit dans le message de news:
%2***************@TK2MSFTNGP14.phx.gbl...

| For fear of sounding even more basic...you mention the data Layer Class...
| would this be in the same physical C# class file? or would this be
another
| set of file(s)?

Unless there is a very tight interdependence, all classes tend to be written
in their own code files.

Just to make advice easier, are you using C# 1 or 2 ?

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[JoSkillz]

WOW 70+ properties is not the way you want to go. You want to think
more abstract when you are creating your classes then just mirroring
the implementation of the data layer. Consider the following; some
table structures for a customer table might have several fields
identified for mailing. Such as mailAddress1, billingAddress1,
shipAddress1 etc. The following implementation may give you more of
understanding of how to abstract you classes for reuse and better O/O
design.

public class Person
{
private string firstName;
private string lastName;
private Address mailingAddress;
private Address billingAddress;
private Address shippingAddress;

public Person()
{
this.mailingAddress = new Address();
this.billingAddress = new Address();
this.shippingAddress = new Address();
}

public Address ShippingAddress
{
get { return shippingAddress; }
}

public Address BillingAddress
{
get { return billingAddress; }
}

public Address MailingAddress
{
get { return mailingAddress; }
}

public string LastName
{
get { return lastName; }
set { lastName = value; }
}

public string FirstName
{
get { return firstName; }
set { firstName = value; }
}

}

public class Address
{
private string line1;
private string city;
private string state;
private string postalCode;

public string PostalCode
{
get { return postalCode; }
set { postalCode = value; }
}

public string State
{
get { return state; }
set { state = value; }
}

public string City
{
get { return city; }
set { city = value; }
}

public string Line1
{
get { return line1; }
set { line1 = value; }
}

}

Happy coding
JO

[RCS]

Yep, what you have below is heading in the right direction - although
Joanna's example is bit more proper.

If you are talking about theses classes as a concept, that's one thing - but
it sounds like you intend to load the structure of a database into these
objects? If so - that usually isn't appropriate. It's much faster to just
access the data directly via a DataSet/DataView or bound directly to a
control.

Concept-wise though, you wouldn't often implement something like this. An
example of when you would - is let's say you have a job that is supposed to
notify various people, if the job blows up. In that case, you may hit the
database to get their information, load those people into individual
instances of a Contact class, that is accessible from a Contacts container
class. Then you could do something like:

Contacts objContacts = LoadContacts();
foreach (Contact cnt in objContacts.Items)
{
if ( cnt.Email.Length > 0 )
SendEmail(cnt)
if ( cnt.Pager.Length > 0 )
SendPage(cnt)
}
HTH

"RSH" <wa*************@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

That makes a lot of sense but what would that basic structure look like?

I'm trying to understand what the code would look like. I'm having a
tough time going from conceptualization to code. For example does each
property of an employee (or field) have to be set like (that would be a
lot of code for a typical Employee table!):
private int employeeId;
public int EmployeeID
{
get
{
return employeeId;
}
set
{
employeeId = value;
}
}

private int lastName;
public int LastName
{
get
{
return lastName;
}
set
{
lastName= value;
}
}
etc.....

"RCS" <rs****@gmail.com> wrote in message
news:EC****************@newssvr22.news.prodigy.net ...

First thing that comes to mind, is you should really have a class, that
does nothing but contain all of your employees, called Employees - that
class would have an "indexer" to get to the actual employees.. and it's
in this class, that you'd have an Insert()/Update()/etc..

In other words, the Employee class would contain all the information
about exactly one employee. Then, another class, called Employees, could
contain links to instances of Employee classes, filled out with the
specific information for each person.

Does that help?

"RSH" <wa*************@yahoo.com> wrote in message
news:e5**************@TK2MSFTNGP15.phx.gbl...

I am really trying to grasp the concept of OOP as it applies to C#.

I am looking at trying to set up a simple Employee Class but I am having
trouble conceptualizing what this class should look like. I was hoping
someone might be able to simply outline what I envision my class to look
like:

Basically I am envisioning a Class called Employee:

I imagine it would have many properties(?) such as:
EmployeeID
LastName
FirstName
Address
City
State
ZipCode
etc.

I imagine I would have AddNew(), Update(), Delete() methods.

Is this a good place to utilize a class? If so what would the basic
infrastructure look like for the class?

I have been through several tutorials but they are very basic and use
things like Dogs and firehydrants as object examples which don't
translate well into business object uses.

Sorry for the basic question.

I greatly appreciate any responses.
RSH

[Joanna Carter [TeamB]]

"RCS" <rs****@gmail.com> a écrit dans le message de news:
Ze*****************@newssvr33.news.prodigy.com...

| Yep, what you have below is heading in the right direction - although
| Joanna's example is bit more proper.
|
| If you are talking about theses classes as a concept, that's one thing -
but
| it sounds like you intend to load the structure of a database into these
| objects? If so - that usually isn't appropriate. It's much faster to just
| access the data directly via a DataSet/DataView or bound directly to a
| control.

This idea that loading lists of objects is slow is a myth. If you design a
Broker that feeds objects from the database on an "as required" basis, you
end up with a similar rate of loading as that found in datasets, which
follow a similar strategy.

The important concept is to separate business logic from database access.
..NET provides the most wonderful data-aware architecture that is designed
around connecting visual controls to objects and/or list of objects. A
database table has to support IListSource and it is this that the controls
bind to.

We have been designing OO applications that use an Object Persistence
Framework for some years now and find that, for most business data entry
applications, the speed difference (if any) is really not worth worrying
about.

I have a company that I consult for that has a real-time multi-threaded
application that uses totally OO frameworks like these and they are running
interactive video output at up to 60 frames per second.

The whole point of working this "correct" way is to give you flexible,
adaptable assemblies that can be changed, if necessary at runtime, and that
can do things like changing the database connection at runtime without the
business logic knowing anything about it. Also, using Model View Presenter
principles, we can change the UI without having to change any business
logic; in factr, our forms have no code on them apart from that which is
generated by the form designer in placing the elements on the form.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[RSH]

I appreciate the input.

After some reflection I see that like Jo said I was thinking about it
incorrectly...making a database wrapper. After some more reading and your
replies here I'm strating to understand how to better conceptualize an
object. I think i still need to see some examples of a true business object
class to see what a properly implemented class looks and feels like. So I
will continue searching for samples...but I am definitely looking at things
differently now...THANKS!

RSH

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

"RSH" <wa*************@yahoo.com> a écrit dans le message de news:
e5**************@TK2MSFTNGP15.phx.gbl...

| I am looking at trying to set up a simple Employee Class but I am having
| trouble conceptualizing what this class should look like. I was hoping
| someone might be able to simply outline what I envision my class to look
| like:
|
| Basically I am envisioning a Class called Employee:
|
| I imagine it would have many properties(?) such as:
| EmployeeID
| LastName
| FirstName
| Address
| City
| State
| ZipCode
| etc.

You can start by having a simple class that is mainly just data; there
would
be very few methods for an entity like an Employee :

public class Employee
{
private int id;
private string lastName;
...

public int ID
{
get { return id; }
set { id = value; }
}

public string LastName
{
get { return lasName; }
set { lastName = value; }
}

...
}

| For example does each property
| of an employee (or field) have to be set like (that would be a lot of
code
| for a typical Employee table!):

This is the correct way to declare a class. You should not be trying to
write classes that wrap tables; rather you should design classes first and
then design tables to support storing instances of those classes. Classes
are not meant to be just wrappers for database tables, they can also have
behaviour; in this case though there is very little code to associate with
an Employee.

| I imagine I would have AddNew(), Update(), Delete() methods.

These methods are not part of an Employee class, they actually belong in
more than one other class.

e.g.

If you are using C# 2.0 then you would use a generic list like :

List<Employee> employees = new List<Employee>();

But if you are using .NET 1.0 then you need to declare your own typesafe
list classes.

public class EmployeeList
{
private ArrayList employees = new ArrayList();

public Employee AddNew()
{
Employee newItem = new Employee();
employees.Add(newItem);
return newItem;
}

public void Delete(Employee item)
{
employees.Remove(item);
}

...
}

public class DataLayer
{
public void Update(object item)
{
// handle data updating into database
}
}

| Is this a good place to utilize a class? If so what would the basic
| infrastructure look like for the class?

Classes represent business or other concepts, you can't design any
software
in C# without using classes. To demonstrate the mixture of properties and
methods in a class, look at this example of a Sales Order :

public class Product
{
...
public string Code {...}
public string Description {...}
public float UnitPrice {...}
}

public class OrderLine
{
private int quantity;
private Product product;

public int Quantity {...}
public Product Product {...}
public float Total
{
get { return product.UnitPrice * quantity; }
}
}

So you get code that works on data to give you claculated totals or other
behaviour as well as just data. Think about the DataLayer class where most
of the class will be methods that talk to a database and there would be
very
few private fields holding data in memory.

| Sorry for the basic question.

We all had to start somewhere :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[RSH]

C# 2

I think my problem is that my mindset is wrong about how and when to use an
object and how to conceptualize it's layout...like you mentioned
yesterday...I was simply making a database wrapper instead of considering
the application logic. I think that is always a danger when trying to learn
something new.

RSH

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:u4*************@tk2msftngp13.phx.gbl...

"RSH" <wa*************@yahoo.com> a écrit dans le message de news:
%2***************@TK2MSFTNGP14.phx.gbl...

| For fear of sounding even more basic...you mention the data Layer
Class...
| would this be in the same physical C# class file? or would this be
another
| set of file(s)?

Unless there is a very tight interdependence, all classes tend to be
written
in their own code files.

Just to make advice easier, are you using C# 1 or 2 ?

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[clintonG]

IMO WROX, "C# Class Design Handbook" is a good resource.
<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/
"RSH" <wa*************@yahoo.com> wrote in message
news:e5**************@TK2MSFTNGP15.phx.gbl...

I am really trying to grasp the concept of OOP as it applies to C#.

I am looking at trying to set up a simple Employee Class but I am having
trouble conceptualizing what this class should look like. I was hoping
someone might be able to simply outline what I envision my class to look
like:

Basically I am envisioning a Class called Employee:

I imagine it would have many properties(?) such as:
EmployeeID
LastName
FirstName
Address
City
State
ZipCode
etc.

I imagine I would have AddNew(), Update(), Delete() methods.

Is this a good place to utilize a class? If so what would the basic
infrastructure look like for the class?

I have been through several tutorials but they are very basic and use
things like Dogs and firehydrants as object examples which don't translate
well into business object uses.

Sorry for the basic question.

I greatly appreciate any responses.
RSH

[clintonG]

<snip />

The more I learn about Agile development the more I understand -- and
accept -- that the class JoSkillz suggests still sounds flawed itself as it
contains properties that should be isolated and moved into a class of their
own.

A street address for example is not a property of a Person nor is it a
property of an Employee. An address as being used in this context is the
property of a building of some sort and is used to identify the location of
that object.

On the other hand, a Person could easily have 70 or more properties if in
fact the Person class was designed to be a class which defined the actual
properties for a Person rather than a hybrid class which contains redundant
and impertinent properties such as street adresses and so on. Hair, eye
color, height, weight and many more biological factors which are properties
of a Person come to mind.

As I understand the principles of Agility in this example there should be a
separate homeAddress class, homeOfficeAddress class and so on.

--
<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/

[JoSkillz]

I agree Clinton completely on what you have written. My objective was
not to teach RSH about proper domain isolation with an OO structure but
to give him a base on where he needs too look at objects in an abstract
manner in comparison to a straight flat table implementation of a
class. I too practice Agile Development and try to live by Eric Evans
Domain Driven Design principals. If you haven't had a chance to read
it, it is a must read IMHO. Along with Michael Feathers book
"Working Effectively with Legacy Code"

Happy Coding,
JO

[RSH]

I was playing with the code you provided a bit and it really started to open
my eyes a bit. I experimented a bit and came up with something like this
below. Would this be a good framework, or how would the Orders be
introduced into the mix?

Thanks,
Ron

using System;

using System.Collections.Generic;

using System.Text;

namespace ClassTesting

{

public class Person

{

private string firstName;

private string lastName;

private Address mailingAddress;

private Address billingAddress;

private Address shippingAddress;

private Phone homePhone;

private Phone cellPhone;

public Person()

{

this.mailingAddress = new Address();

this.billingAddress = new Address();

this.shippingAddress = new Address();

this.homePhone = new Phone();

this.cellPhone = new Phone();

}

public Address ShippingAddress

{

get { return shippingAddress; }

}

public Address BillingAddress

{

get { return billingAddress; }

}

public Address MailingAddress

{

get { return mailingAddress; }

}

public Phone HomePhone

{

get { return homePhone; }

}

public Phone CellPhone

{

get { return cellPhone; }

}

public string LastName

{

get { return lastName; }

set { lastName = value; }

}

public string FirstName

{

get { return firstName; }

set { firstName = value; }

}

}

public class Address

{

private string line1;

private string city;

private string state;

private string postalCode;

public string PostalCode

{

get { return postalCode; }

set { postalCode = value; }

}

public string State

{

get { return state; }

set { state = value; }

}

public string City

{

get { return city; }

set { city = value; }

}

public string Line1

{

get { return line1; }

set { line1 = value; }

}

}

public class Phone

{

private int areaCode;

private int prefix;

private int postfix;

private int extension;

public int AreaCode

{

get { return areaCode; }

set { areaCode = value; }

}

public int Prefix

{

get { return prefix; }

set { prefix = value; }

}

public int Postfix

{

get { return postfix; }

set { postfix = value; }

}

public int Extension

{

get { return extension; }

set { extension = value; }

}

public string PhoneNumber

{

get { return "(" + this.AreaCode.ToString() + ")" + this.Prefix.ToString() +
"-" + this.Postfix.ToString(); }

}

}

public class Orders : Person

{

private int orderNumber;

private DateTime orderDate;

private string quantity;

private string product;

public int OrderNumber

{

get { return orderNumber; }

set { orderNumber = value; }

}

public DateTime OrderDate

{

get { return orderDate; }

set { orderDate = value; }

}

public string Quantity

{

get { return quantity; }

set { quantity = value; }

}

public string Product

{

get { return product; }

set { product = value; }

}

}

}

[JoSkillz]

At quick glance I would say you are off to a good start. About the
only BIG thing I see is that you are inheriting from Person in Orders.
You are in essence mixing apples with oranges. I don't think an Order
can ever be a person and vice versa. I would say though that a
Customer has many Orders. So in essence Create a Customer class that
inherits from Person and has a collection of Orders. This is just a
quick observation.

Also the class Phone, you want your classes to have a meaning
representation of the actual logical/physical object they represent. A
phone has a PhoneNumber associtatd with it but the Phone is not a
PhoneNumber. A PhoneNumber has an area code, coutry code, etc. and may
have a value function that returns a FormattedString of all the fields
that were collected.

JO