Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!uunet!wang!bu-tyng!three!cory From: cory@three.mv.com (Cory Kempf) Newsgroups: comp.object Subject: Re: Should Shapes Display Themselves? [was: Display methods, pro or con...] Message-ID: <424@three.mv.com> Date: 15 Aug 90 00:41:05 GMT References: <1681@dinl.mmc.UUCP> <25966@bellcore.bellcore.com> Organization: EnigamI, Nashua, NH. Lines: 35 cline@cheetah.ece.clarkson.edu (Marshall Cline) writes: >QUESTION: Should a `Shape' be able to `draw' itself? >The usual answer is ABSOLUTELY. >However: what if I add a new terminal type? Or what if I want a textual >`view' (using MVC terminology) rather than a graphical `view'. The real >problem is: what if I want several views to coexist in the system at the >same time, so a Square is either `viewed' as a bunch of pixels, the name >"Square", or whatever, depending on which `view' it's being `drawn on'. It would seem to me that the advice that I was given when I was first learning Object Programming: Try to make your objects model a hardware implimentation. Your instincts are correct: The Shape should be able to draw itself. In reality, the Shape doesn't (usually) actually muck with the pixels on the screen, but rather tells the GraphicsDevice to perform some actions which acomplish the same task. From the description above, there are two classes of objects: Shapes and GraphicsDevices. The Shapes, when told to draw themselves tell the GraphicsDevices what commands need to be executed. The GD's would impliment a set of Graphics Primitive methods that would actually do the work. I don't know how that would work with the idea of showing the name of the original objecct, but I would not view that as being a drawing related task (e.g. instead of asking the Shape to draw itself, you would ask it to Name itself). +C -- Cory Kempf I do speak for the company (sometimes). The EnigamI Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory