Re: [aus-dotnet] Many instance variables inside a class

    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
    • From: Alex Hoffman
    • Subject: Re: [aus-dotnet] Many instance variables inside a class
    • Date: Fri, 10 Dec 2004 13:00:04 +1100 
    > should always try to have more methods than properties in one's classes
    In the old days, for someone coming from say C to an OO language that was particularly true. Behavior in addition to representation in an "object" was a new thing then.
    Lots of properties aren't a bad thing, and given that a lot of .NET infrastructure is written around them, their use versus methods can be strategic.
    For example... properties == data binding == 2 way live representation of data/UI in WinForms (1 way in Web Forms) == loose coupling of underlying data from UI
    For example, you could have a method IsValid() that returns a bool to indicate a valid object. So now you can check if myObject.IsValid().
    But if you implement IsValid as a property, you can also data bind it to an arbitrary property on a Control - say an OK button's Enabled property in one line ... 
    
myButton.DataBindings.Add("Enabled", myBusinessObject, "IsValid");
    Now your button will automatically reflect your objects valid state - made possible essentially for free by exposing state through a property rather than a method. 
    
(BTW, I use a code region to group and hide large numbers of properties)

Alex Hoffman
http://weblogs.asp.net/ahoffman


Grant Maw said the following:

    Thanks all for the replies. Seems that having lots of properties might
not be such an evil thing to do after all (though I do recall reading
on some guru's blog that one should always try to have more methods
than properties in one's classes).

The class is daunting to new programmers who have never used it
before, so perhaps grouping related data into structs might be the
answer.

Cheers!

On Fri, 10 Dec 2004 11:30:19 +1100, David Kean <David.Kean@xxxxxxxxxxx> wrote:


    Well, you could break the Person down into 'properties' classes, however
classes with just data and no methods just feel wrong.

For example:

Instead of:

Person.Title
Person.FirstName
Person.MiddleName
Person.LastName

Have

Person.Name.Title
Person.Name.FirstName
Person.Name.MiddleName
Person.Name.LastName

Where Name is a instance class of a PersonName class with those
properties.

It will make Person a little easier to deal with, being confronted with
70 properties can be daunting.



-----Original Message-----
From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On
Behalf Of Grant Maw
Sent: Friday, 10 December 2004 11:23 AM
To: dotnet@xxxxxxxxxxx
Subject: Re: [aus-dotnet] Many instance variables inside a class

The data has already been normalised to 3NF. This is a massive database
and if we did not have normalised data the whole thing would have come
crashing down around our ears years ago.

All I'm after is a way to represent any entity that, by it's nature, has
lots and lots of data attached to it. It feels to me that having a class
with so many properties is using the class incorrectly - using it as a
bucket of bits rather than as a functional entity.

On Fri, 10 Dec 2004 11:16:28 +1100, David Kean <David.Kean@xxxxxxxxxxx>
wrote:


    Yep it's called normalizing!  70 columns for 1 table sounds way too
many, have you thought about looking at the database side first?



-----Original Message-----
From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On
Behalf Of Grant Maw
Sent: Friday, 10 December 2004 11:13 AM
To: dotnet@xxxxxxxxxxx
Subject: [aus-dotnet] Many instance variables inside a class

Hi all

I have a situation where I have a class called "Person" which, rather
obviously, holds the data and methods for working with the Person
entity in our app.

The DB entry for a person has some 70 columns and this has translated
into 70 properties of the Person class. There is one method to load
the data rom the DB, and another to update it. The update method does
all the validation and throws exceptions if any of the data violates
business rules.

The class works well so maybe I'm over-reacting here, but having a
class with such a large number of properties just feels wrong. I
haven't found anything in MSDN that explicitly deals with this
situation.

Is there a better way of dealing with situations where an entity has
lots of different properties?

Cheers

- Grant
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
"subscribe dotnet Your Name" in the body of the email to:
    imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com ###################################################################### 
    ###############

    


    Attention:
The information contained in this message and or attachments is

    
intended


    only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance

    
upon,


    this information by persons or entities other than the intended

    
recipient


    is prohibited. If you received this in error, please inform us by

    
email at


    postmaster@xxxxxxxxxxx and delete the material from any system.


    
########################################################################
#############


    _________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send

    
"subscribe dotnet Your Name" in the body of the email to:
imailsrv@xxxxxxxxxxx


    List managed by: http://www.stanski.com


    
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send
"subscribe dotnet Your Name" in the body of the email to:
imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com
#####################################################################################


Attention:
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please inform us by email at
postmaster@xxxxxxxxxxx and delete the material from any system.
#####################################################################################
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
List managed by: http://www.stanski.com


    
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
List managed by: http://www.stanski.com

    _________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
List managed by: http://www.stanski.com


    (Click here for more information on the aus-dotnet mailling list)