# Inheritance in other notation

Hi everybody! I’ve got a problem with ingeritance. If there is a
notation like ‘class Square’, we can write class Rectangle like ‘class
Rectangle<Square’. But how it will be here?

Square = Struct.new(:x,:y,:a) do
include Domieszka
def pole
p = a**2
end
def obwod
o = 4*a
end
def pole=(a)
self.a = a
end
def obwod=(a)
self.a = a
end
end

Rectangle<Square = Struct.new(:x,:y,:b) do
include Domieszka
def pole
p = a*b
end
end

luk malcik [email protected] wrote:

o = 4a
Rectangle<Square = Struct.new(:x,:y,:b) do
include Domieszka
def pole
p = a
b
end
end

The constant Square is a class effectively equivalent to conventionally
created classes, so you don’t have to do anything special to make
Rectangle descend from it. Just do it as you originally expected:

class Rectangle < Square

end

-Jeremy

On Sat, Feb 4, 2012 at 7:03 AM, Robert K.
[email protected]wrote:

Which leaves us with the “minor” issue that a rectangle is not a
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Probably neither should inherit from the other since they break Liskov
Substitution Principle.

rect.x = 2
rect.y = 4

Now what is the value of rect.x? When rectangle, this will be 2. When
square, will it be 4? Squares don’t have setters/getters for individual
sides since their sides must change together.

On Sat, Feb 4, 2012 at 2:14 AM, Jeremy B. [email protected] wrote:

The constant Square is a class effectively equivalent to conventionally created
classes, so you don’t have to do anything special to make Rectangle descend from
it. Just do it as you originally expected:

class Rectangle < Square

end

Which leaves us with the “minor” issue that a rectangle is not a
square - it’s the other way round. Yeah, I know, implementation
inheritance vs. conceptual inheritance. But OP should be aware of
this.

Kind regards

robert

On Sat, Feb 4, 2012 at 3:56 PM, Josh C. [email protected] wrote:

end

Which leaves us with the “minor” issue that a rectangle is not a
square - it’s the other way round. Yeah, I know, implementation
inheritance vs. conceptual inheritance. But OP should be aware of
this.

Probably neither should inherit from the other since they break Liskov
Substitution Principle.

Good point! But classes Rectangle and Square need not necessarily
implement the mathematical idea of them - or not completely.

rect.x = 2
rect.y = 4

Now what is the value of rect.x? When rectangle, this will be 2. When
square, will it be 4? Squares don’t have setters/getters for individual
sides since their sides must change together.

Well, or setters change all in the same way. It all depends for what
you need those classes and how you model it. Kind regards

robert