Difference between object and variable?

[alkakumari]

<e-mail address deleted>

[weaknessforcats]

Nothing.

Variable is C/C++ program language terminology.

Object is Object Technology terminology (you know, the UML folks).

You will appear more as a programmer if you use variables and structs.

You will appear more as an object design person if you use objects and classes.

[Rabbit]

A variable holds a single piece of data while an object holds many variables and methods that act on those variables.

[weaknessforcats]

[quote]A variable holds a single piece of data while an object holds many variables and methods that act on those variables.[/qute]

The C Programming Language page 6 says: A C program whatever its size, consists of functions and variables.

The same is true for C++.

Both C and C++ languages create variables the same way: Allocate memory for the data. Keep the values unchanged unless directed by a function.

A method is an Object Technology term for an operation on a class using member variables. C++ does not use methods. It uses functions instead. The function arguments are variables. The class of C++ is a struct. The member functions of a C++ class are just functions with a pointer argument for the variable.

Write a C++ program using a class and get it working. Then change the class keyword to struct and rebuid the program. Nothing will happen. The code will compile and link as before.

C++ is not an object oriented language like Java. It does not support the Liskov Substitution and that makes C++ no object-oriented. Istead, it is a structural language derived from C that has object-oriented-like features added.

[Rabbit]

Those are concepts that are debated amongst computer scientists on what is truly considered object oriented languages.

Liskov substitution is not something that can be supported by the implementation of a language, it must be supported by careful design of the objects. Take for example a rectangle class, a subclass of that would be a square. Regardless of which language is used, if setter methods are used, it is in violation of the Liskov substituion principle.

[weaknessforcats]

The Liskov substitution is supported by Java and C#.

But not C++. The principle requires that a derived object can be substituted for a base object. C++ lets you substitute a pointer or reference of the derived object for a pointer or reference to a base object but you cannot substitute the object itself.

This has nothing to do with accessor methods.

[Rabbit]

If you have a Rectangle class in Java and create a Square subclass, you're saying that you can use the Square subclass in place of a Rectangle class without running into any problems?

If we use the formal definition of the Liskov Substitution Principle, which states that "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T," then the rectangle/square example is not compliant with LSP. Yet, it can be implemented in Java. LSP is not a feature of a language but a feature of carefully designed classes and subclasses.

[weaknessforcats]

Okay. So Rectangle has a draw property. Therefore,
draw(Rectangle object) draws a Rectangle. The substitution principle says that if Square derives from Rectangle, then substituting a Square object in
draw(Rectangle object) draws a square.

This works in C# but not C++. In C++ you need to use virtual functions plus pass not the object to the draw but only the address of the object. Note that a C++ reference (which as works here) just passes the address of the object. If you try substituting the derived object for the base object in C++ you get slicing.

[Rabbit]

A typical example that violates LSP is a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently. This problem cannot be easily fixed: if we can modify the setter methods in the Square class so that they preserve the Square invariant (i.e. keep the dimensions equal), then these methods will weaken (violate) the postconditions for the Rectangle setters, which state that dimensions can be modified independently. Violations of LSP, like this one, may or may not be a problem in practice, depending on the postconditions or invariants that are actually expected by the code that uses classes violating LSP. Mutability is a key issue here. If Square and Rectangle had only getter methods (i.e. they were immutable objects), then no violation of LSP could occur.

As you can see, LSP is a property of an implementation of a class. Not a property of a language. While a language may allow you to substitute one subclass for a parent class, it does not make the implementation of that class LSP compliant. The ability to make a substitution is not what LSP states. What LSP states is that you can make the substitution and every method will work as expected as if the parent class is being used.