Re: Method.property string by StumpedSteve
StumpedSteve
Thu Jul 06 09:59:02 CDT 2006
Joanna
Thanks for being patient with me. I still cannot find my â??missing linkâ?? to
put this together. Maybe itâ??s true, â??You canâ??t teach an old dog new tricks!â??
Iâ??d like to take just a few more moments of your time. Maybe I am attempting
something that is incorrect, or my methodology is skewed. I would like to
throw out my thought path and have you take a look.
I have several areas of my program where I have to retrieve data from a
database. I retain the data in table objects where each area can manipulate
it to suit depending on user interface. I have several working methods to
retrieve this data, assemble SQL statements, retrieve the data column number
(given a name), and data (given a row). I would however, like to streamline
this into an OOP â??likeâ?? presentation. I have drawn a map of the outcome that
I would like to share; Iâ??ll try to be brief.
GetData(SQL, Area) method to retrieve the data and store it in the â??areasâ??
data table object.
GetData(Area).Col(ColumnName) Overloaded GetData and property Col returns
the column number from the given table object {Area} of the given column name.
GetData(Area).Col(col Number).Row(RowNumber) Overload Col to set or get the
property value Row of the given area object, at the given Col.
Seems do-able doesnâ??t it?
I think that by your instruction I would make a shared (static) Col property
within the GetData Class that would return the Column position from the given
column name.
Then would I instantiate the Col class from within the GetData Class to call
the overloaded Shared Method "Col" and place the Shared (static) Row property
in the Col Class? Or could I inherit the GetData class? I have tried all
but havenâ??t succeeded in any. If I knew the correct path I would find the
proper syntax. (I doubt that I can overload a method and a property of the
same name so Iâ??ll need to massage that some.)
Steve
--
You donâ??t know everything you donâ??t know! Donâ??t you wish youâ??d paid better
attention in school?
"Joanna Carter [TeamB]" wrote:
> "StumpedSteve" <StumpedSteve@discussions.microsoft.com> a écrit dans le
> message de news: BF004E9C-8826-4623-964B-72967BF83704@microsoft.com...
>
> | Instance variable I am familiar with although instance properties I am
> not.
> | Although I know the genre used for defining one entity usually crosses
> over
> | to another. So I would guess that instance properties have a limited
> scope
> | within the class they reside, although, again, I don't find any reference
> to
> | it in my books. So I would have to ask; would I set the scope of a
> resident
> | property to "friend" so it could be accessed across class borders?
> |
> | While in my limited exposure to VB.net I have not used shared properties I
> | understand them to be accessible without instantiating the class they
> reside.
> | They share their allegiance to the class as well as the instantiated
> object.
> | I also understand that the have a whole new "kettle" of rules that must be
> | followed. I also know that there is a lot I don't know about them, and
> what
> | I think I know may be misinterpreted.
>
> Let me start by just going over some basics :
>
> A class is like a cookie cutter, an object or instance is like the cookies
> that the cutter creates.
>
> Classes can contain fields, methods properties and events. These are known
> as members and can be either static or instance members.
>
> Static members belong to the "cookie cutter" (class) and, as you rightly
> say, can be accessed without having to create an instance of the class.
>
> Fields hold state and should usually only be of private visibility. This
> then means that we need a mechanism that allows us to expose the values in
> these fields. One mechanism is to add public accessor methods :
>
> public class Person
> {
> private string name;
>
> public string GetName()
> {
> return name;
> }
>
> public void SetName(string value)
> {
> name = value;
> // fire notification event or something
> }
> }
>
> This then requires us to call these methods in code like this :
>
> {
> Person p = new Person();
>
> p.SetName("Joanna");
>
> Console.WriteLine(p.GetName());
> }
>
> Properties allow us to talk to fields without making those fields public,
> but still allowing us to use a "field" syntax.
>
> public class Person
> {
> private string name;
>
> public string Name
> {
> get { return name; }
> set
> {
> name = value;
> // fire notification event or something
> }
> }
> }
>
> This then allows us to call these properties in code like this :
>
> {
> Person p = new Person();
>
> p.Name = "Joanna";
>
> Console.WriteLine(p.Name);
> }
>
> So you can think of properties as a sort of virtual field that also allows
> us to execute additional or consequential code when reading/writing a value
> from/to an object.
>
> You can also use a property to restrict a "field" to being read-only, or
> even write-only !
>
> public class Person
> {
> private DateTime dateOfBirth;
>
> public TimeSpan Age
> {
> get
> {
> return DateTime.Now = dateOfBirth; // pseudocode
> }
> }
>
> public DateTime DateOfBirth
> {
> set { dateOfBirth = value; }
> }
> }
>
> Properties can also be virtual or even abstract, which means that we can add
> or change what happens when a value is read/written in derived classes :
>
> public class Base
> {
> private string value;
>
> public virtual string Value
> {
> get { return value; }
> set { this.value = value; }
> }
> }
>
> public class Derived : Base
> {
> public override string Value
> {
> get { return base.Value; }
> set
> {
> base.Value = value;
> // do something more
> }
> }
> }
>
> Does that help ? If you need further help, then just ask.
>
> Joanna
>
> --
> Joanna Carter [TeamB]
> Consultant Software Engineer
>
>
>
>