No, there is no easy answer to this problem in a way that jives with all doctrines and also works in practice.
OO is ambiguous as to whether a "subclass" of an object is specialization of the parent object or a generalization. In practice, most subclasses are a generalizations and specializations introduce all sorts of problems, especially enforcing constraints.
This naturally comes down to OO trying to shoe-horn (at least) four related-but-not-necessarily-identifical activities together: code/data encapsulation, program design, code-reuse, and modeling (the translation of real-world objects-and-categories to code).
The net result is that OO languages, tools and methods can be useful for writing large program and can give you effects that are better than the alternatives but that the pronouncement of OO gurus wind-up sounding idiotic and following the book to the letter can create situations that negate the particular benefits of OO.
By Liskov substitution principle, or with the set view of types, subclasses are always specializations / subsets, unless you're introducing some kind of home-baked type system built on top of the existing type system.
I would classify the parts of OO differently. I think your second and fourth activities are the same, but one models abstract concepts, and the other models concepts of concrete things. I wouldn't bring in code reuse at this level; every practical programming paradigm tries to include code reuse. It's the mechanism that's a distinguishing feature, and the mechanism OO uses is a combination of subtype polymorphism and dynamic dispatch. It's a baked-in version of the function table / union|variant record idiom from procedural programming, and it has a transposed expression in sum types and pattern matching in functional programming: OO limits the addition of new (virtual) methods (on the base) but accepts the creation of new types (even at runtime), while FP limits the creation of new types (in most implementations I've seen) but accepts the addition of new methods (which costs some in discoverability in modern IDEs, and has namespace implications).
By Liskov substitution principle, or with the set view of types, subclasses are always specializations / subsets, unless you're introducing some kind of home-baked type system built on top of the existing type system.
So, does that mean that subclasses shouldn't have extra member variable in the way that a square doesn't have any extra member variables in inheriting?? I know that there are some systems which try to do something like this - Darwin and Date's Third Manifesto, for example, though they don't try to say they're doing OO. And, of course, this is far away from what most people do in defining objects.
The various tools and approaches are useful and your particular take on it might make it consistent if it was generally accepted. But at this point, the many confusions about what OO are set in people's minds. What's being defined now is Agile - which is naturally another semi-original, semi-useful, semi-contradictory toolset.
But hey, I guess my conclusion is it's all good if you don't take it too seriously and do stupid things just to satisfy some absurd constraint - like in the hay-day of OO when people let go of common sense and built these huge, fragile multiple inheritance trees that wound up not having the slight understanding of - or used ten separate, nested classes to define the complex numbers...
> does that mean that subclasses shouldn't have extra member variable
Not sure what you meant here. Extra members, whether they be properties, fields, methods, types, whatever, should be fine in subclasses. If it was removing members from the superclass, that would be problematic from a subtyping / polymorphic perspective, but adding members makes it more specific.
OO is ambiguous as to whether a "subclass" of an object is specialization of the parent object or a generalization. In practice, most subclasses are a generalizations and specializations introduce all sorts of problems, especially enforcing constraints.
This naturally comes down to OO trying to shoe-horn (at least) four related-but-not-necessarily-identifical activities together: code/data encapsulation, program design, code-reuse, and modeling (the translation of real-world objects-and-categories to code).
The net result is that OO languages, tools and methods can be useful for writing large program and can give you effects that are better than the alternatives but that the pronouncement of OO gurus wind-up sounding idiotic and following the book to the letter can create situations that negate the particular benefits of OO.