locked
Deeply understanding Object and variable's role and similarity in OOP RRS feed

  • Question

  • User-778135100 posted

    Is conceptually in OOP variables and objects are the same or have same kind of effects. When a variable is used, let's say: string type variable, (and string actually means System.String) it is depended on another class String (and I think that, the namespace System.String has a mechanism to hold the value of the variable and does other defining process internally build, though I haven't seen it yet) and later we can do same operations to the variable with build in method of the class 'String' such as

    IndexOf(variable)   .

    Isn’t the same thing we actually do with an object.

    Monday, May 11, 2020 10:43 AM

All replies

  • User1535942433 posted

    Hi TheShuvo,

    Accroding to your description.as far as I think,they are different.

    1.A variable represents a storage location in memory. It has a name by which you can refer to it at compile time, and at execution time it has a value, which will always be compatible with its compile-time type. (For example, if you've got a Button variable, the value will always be a reference to an object of type Button or some subclass - or the null reference.)

    2.An object is a sort of separate entity. Importantly, the value of a variable or any expression is never an object, only a reference. An object effectively consists of:Fields (the state)
    A type reference (can never change through the lifetime of the object)
    A monitor (for synchronization)

    Best regards,

    Yijing Sun

    Tuesday, May 12, 2020 8:23 AM
  • User753101303 posted

    Hi,

    It's basically unrelated. A variable is just how you access the "value" on which you are working. It just happens that for OOP this "value" is often an object.

    The real difference is rather that OOP combines both data and operations done on data. For example if you look at win32 functions at https://docs.microsoft.com/en-us/windows/win32/winmsg/window-functions you see that :
    - almost all functions are using a hwnd (a integer identifying the window) that you have to keep
    - you can read/write "properties" on a window by calling a function accepting this handle and the proper values but you have to keep that as well if you want somewhere
    - technically speaking you could manage to pass a file handle rather than a window handle which will fail

    With an OOP approach all this is encapsulated using for example the https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.form?view=netcore-3.1 class. It stores the "Handle" for you behind the scene and as a developer this object alone IS the window.

    A side effect is that for #1 the code editor doesn't have any context so if you type Get, it could show ALL methods starting by Get. With an OOP language you start with the object variable and so the IDE can show all method starting with Get applicable to this type of object.

    Tuesday, May 12, 2020 10:53 AM