Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!bcyclone04.am1.xlned.com!bcyclone04.am1.xlned.com!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: How to properly apply OOP in the bouncing ball code
Date: Mon, 11 May 2015 20:24:32 -0400
Organization: IISS Elusive Unicorn
References: <009ceef8-066d-4d92-a6c9-761e86584e75@googlegroups.com> <45313faa-d256-4fa4-9e37-4b8dd85e1681@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.383.1431390292.12865.python-list@python.org>
Lines: 63
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:90423

On Mon, 11 May 2015 08:33:56 -0700 (PDT), zipher
<dreamingforward@gmail.com> declaimed the following:

>On Friday, May 8, 2015 at 10:40:46 AM UTC-5, Tommy C wrote:
>> I'm trying to apply OOP in this bouncing ball code in order to have multiple balls bouncing around the screen. The objective of this code is to create a method called settings, which controls all the settings for the screen and the bouncing behaviour of multiple balls, under the class Ball. However, I keep on getting errors related to attributes (e.g., speed). I'm new to OOP in Python so your help will be much appreciated. Thanks in advance.
>
>You are making a error that few in the programming community have caught up to.  OOP design for *data abstraction* is a completely different beast that OOP for *simulation*.  The confusion is around the use of the word "object" which both denotes a physical world item and a virtual one detached from reality.
>
>I would say that Python might not be the right fit, but instead a language dedicated to simulation.

	The danger there is that a "language dedicated to simulation" might
mean "discrete event" simulation -- which would be an even worse fit to a
problem of particle motion simulation.

For the OP:

	In simple terms, attributes will appear in the methods of the object
class as "self.attribute" (presuming you use the normal practice of using
"self" in the method signature). Names that don't have the "self." prefix
appearing in a method are just temporary local storage (they disappear when
the method exits).

	Ball objects would have a velocity (which, properly, is a speed AND a
direction -- presuming a 2-D world, dX/time-unit and dY/time-unit is
probably easier to track than dDistance/time-unit and Azimuth; that is
10pixelX/sec, 5pixelY/sec is easier than [not the same velocity, just
numbers for an example] 12pixels @ 30degrees)... Other potential attributes
are (for graphical display) color and/or (for text output) name; radius...

	The "world" would contain the dimensions of the, uhm, world (and if it
is bounded [walls, balls bounce off] or open [no walls, balls that go off
the edge are lost] or closed [no walls, balls that go off one edge reappear
on the other... Ever play Asteroids?].

	The world would contain a list of Ball objects.

	Now -- who manages the position of the balls? Should a ball know where
it is, or is that only a matter for the world to know? This gets into
design aspects that may have viable answers on either side. If the ball
knows its position, the world has to ask each ball for the position (and
radius) and then ask each other ball is ballX (pos/radius) has bumped into
it. If the world keeps the positions, it has to pass them in to the balls
to update based on velocity, but it can (after asking for radius) compute
if any ball has hit another.

	I suspect I'd write this with the balls knowing their position --
making a simple ball.update(time_delta) [time_delta allows the world to
control the granularity of time steps, as long as it uses the same
time_delta for all balls per cycle]. Update would have the ball compute its
new position. The world would then query the ball for new location to
update the display... The world would also ask other balls if they've been
impacted.

	NOTE: this scheme does have an implied priority -- no mutual impactors.
Conway's Game of Life commonly uses a double buffered mode -- all nodes are
updated [into "next generation"] based on the "current" generation
conditions. To do that with the balls means .update has to generate a
"next" position -- THEN you handle all collisions based on "next", before
moving all "next" into "current" to start the next cycle.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/