Of course the literature contains numerous definitions.
A similar question might be "what is a noun?".
Objects are "that which the nouns name" in the Pythonic paradigm. They
(the objects) live in memory at id() addresses ("like street addresses" I
might tell my students).
However, impressionable minds need more to hang a hat on that just boring
grammar words (like "noun"). In UML (universal markup language) we have
our customary symbols and diagrams:
https://atomicobject.com/resources/oo-programming/abstraction-and-identity
I often use a Creature -> Animal -> Mammal -> subclasses of Mammal
taxonomy, when introducing inheritance and what we call the MRO (method
resolution order).
Another association of "object" we might build upon is "polyhedron" or
"that which has shape".
class Polyhedron:
def __init__(self, v, f):
self.v = v
self.f = f
self.e = v + f - 2 # euler's law for polyhedra
def scale(self, factor):
"""
scale volume by factor, beget a new poly
"""
return type(self)(vol = self.volume * factor)
__mul__ = __rmul__ = scale
class Tetrahedron(Polyhedron):
def __init__(self, vol=1):
super().__init__(v=4, f=4)
self.volume = vol
class A(Tetrahedron):
def __init__(self):
super().__init__(vol=1/24)
class B(Tetrahedron):
def __init__(self):
super().__init__(vol=1/24)
# etc. (S, E, T)
class Cube(Polyhedron):
def __init__(self, vol=3):
super().__init__(v=8, f=6)
self.volume = vol
class Octahedron(Polyhedron):
def __init__(self, vol=4):
super().__init__(v=6, f=8)
self.volume = vol
etc. (longer list of subclasses).
If the Learning to Code curricula were to feature more source of this
nature, we could facilitate reaching out to the geometry teachers with an
intuitive picture of "dot notation" as a means of accessing "containers" of
a very literal kind, if abstract.
Associations around "object" have something concrete to build on, adding
generic methods such as rotate() -- about what axis? -- and translate() --
for moving the shape relative to others, or to an origin (could involve
creating a new shape at the new place, relative to the old).
We could easily add surface area as another attribute, along with default
edge length corresponding to our default volumes (YMMV in terms of what
defaults your curriculum chooses).
Indeed this is the right place to emphasize the power law, that changing
all edges by a factor of n, e.g. doubling them (n=2) changes area by n**2
and volume by n**3.
A selling point of the simple code base shown above is I'm not trying to do
anything vectorial yet i.e. the shapes are so far coordinate free.
We're free to turn to actual physical models and other media besides source
code, to flesh out the concepts we're talking about. OO wins. Geometry
wins. Dot notation wins. Python wins.
I've been taking this tack in my Youtubes lately, building up a stash for a
science fiction time when these ideas are more mainstream.
Not that this focus on Polyhedrons as paradigm objects is all that
esoteric. Square and Circle types have been common in textbooks at least.
There's a bias against "3D" and I suppose that's what I'm countering, as
speaking experientially, we do not live in Flatland.
The approach to coding I'm advocating is also encouragement for spatial,
not just planar, visualizations. Euclidean proofs may be more involved,
however we have other generalizations such as Euler's Law for Polyhedra and
Decartes' Deficit to introduce.
Having the OO experience tie in with spatial geometry more intimately
provides greater opportunities for imaginative play, and exercises the
computing machinery in ways it's already very good at.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig
