Last post May 12, 2020 10:53 AM by PatriceSc
May 11, 2020 10:43 AM|TheShuvo|LINK
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
Isn’t the same thing we actually do with an object.
May 12, 2020 08:23 AM|yij sun|LINK
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)
May 12, 2020 10:53 AM|PatriceSc|LINK
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.