Re: How Do You Plan An OO Project?

  • From: Jamal Mazrui <empower@xxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Fri, 21 Dec 2007 12:25:23 -0500 (EST)

If you need help along the way, Jim, just post the relevant code -- I
think folks would be glad to help from an OO perspective, and the
exercise would benefit others, too.  By the way, I have further improved
the PyBrace and PyDent features in an an EdSharp update posted today.  I
implemented some of your suggestions about brace and comment spacing.
Also, a .py file may be converted to PyDent without the intermediate
step of going to PyBrace.

Cheers,
Jamal
On Fri, 21 Dec 2007 james.homme@xxxxxxxxxxxx
wrote:

> Date: Fri, 21 Dec 2007 08:29:17 -0500
> From: james.homme@xxxxxxxxxxxx
> Reply-To: programmingblind@xxxxxxxxxxxxx
> To: programmingblind@xxxxxxxxxxxxx
> Subject: Re: How Do You Plan An OO Project?
>
> Hi Jamal,
> Thank you. And, you were correct. I get so anxious about doing things
> sometimes that I'm afraid to just give it a try. It's not like I'll blow up
> the world or anything if I make a mistake and have to try something
> different.
>
> Jim
> James D Homme, , Usability Engineering, Highmark Inc.,
> james.homme@xxxxxxxxxxxx, 412-544-1810
>
> "Never doubt that a thoughtful group of committed citizens can change the
> world.  Indeed, it is the only thing that ever has." -- Margaret Mead
>
>
>
>
>              "Jamal Mazrui"
>              <empower@xxxxxxxx
>              t>                                                         To
>              Sent by:                  programmingblind@xxxxxxxxxxxxx
>              programmingblind-                                          cc
>              bounce@freelists.
>              org                                                   Subject
>                                        Re: How Do You Plan An OO Project?
>
>              12/21/2007 08:30
>              AM
>
>
>              Please respond to
>              programmingblind@
>                freelists.org
>
>
>
>
>
>
> Let me clarify that I do not mean that only a short planning period is
> needed during the whole project.  I think one returns to planning again
> after doing some coding.  Essentially, I think programming with
> contemporary tools is an iterative rather than linear process.  In the
> distant past, programmers had to plan as much as possible ahead of time
> because writing, compiling, and editing code were relatively expensive use
> of resources.  Similarly, writers used to try to create a detailed outline
> by hand before going to a typewriter.  Now they generally start word
> processing after reflecting on a mental outline in their head, since it is
> much easier to revise the work after appraising where it is going and what
> structure is needed to get there.
>
> Simply by starting to code, one is forced to start planning.  What shall I
> name this class before typing it?  What method do I need to call?  What
> property do I need to check before doing something else?  By diving into
> the problem in a concrete rather than abstract way, one is confronted with
> subtleties and distinctions that would not otherwise have been apparent.
> After coding along in a particular direction for a while, one then might
> notice that naming conventions are not as consistent as they could be, so
> one does a search and replace and recommences with a clearer picture of
> how the code needs to be organized to solve the various subproblems at
> hand.  Between coding sessions, one's mind naturally reflects on the
> project so far and ideas sometimes arise about a more robust and powerful
> way of organizing the code.  So the next time one sits down, a backup is
> made for a known restoration point, and then one does some major revisions
> to the structure, aligning names as appropriate.  Sometimes a specific
> planning sidebar may be needed, e.g., opening another editing window and
> writing down all possible values of an enumeration that one decides is
> necessary, then sorting them alphabetically before adding the coding
> syntax needed to make this a construct that can be pasted into the main
> code or saved in a seperate file.
>
> Languages like Python are intended to facilitate this kind of a process.
>  Coding is quick since one does not need to specify types -- they are
> inferred.  High level constructs allow data structures and comparisons to
> be done conveniently.  Expressions or the whole program can be tested
> quickly in the interpreter.
>
> Jamal
>
> On Thu, 20 Dec 2007, tribble wrote:
>
> > Date: Thu, 20 Dec 2007 16:33:46 -0500
> > From: tribble <lauraeaves@xxxxxxxxx>
> > Reply-To: programmingblind@xxxxxxxxxxxxx
> > To: programmingblind@xxxxxxxxxxxxx
> > Subject: Re: How Do You Plan An OO Project?
> >
> > Hi Jim and Jamal and all --
> > When I was working on OO / C++, they had a popular language-independent
> > technique for the OO newbies and beyond for designing an OO program from
> > scratch.  It was called CRC cards -- now pretty old, but as I remember it
> > had some good ideas.  (This was before OO design tools were available.)
> > CRC i think stood for Classes, Responsibilities and contracts -- or if
> that
> > is inaccurate please let me know.  You would start with a very high level
> > document describing in English what you wanted the program to do, and
> then
> > run it through a program to extract all the words in the document, minus
> the
> > common words like "and", "the", and the like.
> > What you are left with are adjectives/adverbs, nouns and verbs etc.
> > You then go through the adjectives and determine which ones are likely
> > candidates for class names.  The nouns are object names and verbs are
> > methods.
> > Now you grab a gunch of index cards and write a class name on each card,
> and
> > determine by some nebulous process how they are related -- both in class
> > hierarchy and content.  You then write on each card the member methods
> and
> > somewhere record contracts between classes of what is expected of each
> > class, and which classes need to interact with which other classes.
> > This will result in a huge spec of the program which can then be
> translated
> > into code.
> > I know of at least 2 books on using CRC cards, one of which I read, but
> > honestly I have never used it myself.  Still the thought process seemed
> > interesting and plausible.
> > Anyway, hope that helps.
> > --le
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Jamal Mazrui" <empower@xxxxxxxxx>
> > To: <programmingblind@xxxxxxxxxxxxx>
> > Sent: Thursday, December 20, 2007 3:02 PM
> > Subject: Re: How Do You Plan An OO Project?
> >
> >
> > Although some planning is helpful, the philosophy of dynamic languages
> and
> > extreme programming with languages like Python is to dive into the
> coding,
> > learn as you go along about the problem and users, and quickly adapt to
> > respond to needs as they arise.  I would advise against spending more
> than
> > hour planning before starting the coding of the project you describe.
> > Actually writing, testing, and debugging code will usually be more
> > productive than planning in the same period of time.
> >
> > My two cents.
> > Jamal
> > On Thu,
> > 20 Dec 2007 james.homme@xxxxxxxxxxxx wrote:
> >
> > > Date: Thu, 20 Dec 2007 11:50:51 -0500
> > > From: james.homme@xxxxxxxxxxxx
> > > Reply-To: programmingblind@xxxxxxxxxxxxx
> > > To: programmingblind@xxxxxxxxxxxxx
> > > Subject: How Do You Plan An OO Project?
> > >
> > >
> > > Hi,
> > > I know how to write pseudocode for a procedure program. I had to do
> that
> > > when I was learning Cobol. We used things called structure charts. I
> made
> > > a
> > > text version of my structure charts that was vertical. Then, I'd refer
> to
> > > it when I was writing my procedures.
> > >
> > > Let's say I want to make an object oriented version of Tic Tac Toe. I
> > > would
> > > start with getting the rules to the game. Then, to figure out the
> objects
> > > my program has and how they would behave, how would I write my plan?
> > >
> > > I have some related questions, but I'd like to save them for another
> > > email.
> > >
> > > Thanks.
> > >
> > > Jim
> > >
> > > James D Homme, , Usability Engineering, Highmark Inc.,
> > > james.homme@xxxxxxxxxxxx, 412-544-1810
> > >
> > > "Never doubt that a thoughtful group of committed citizens can change
> the
> > > world.  Indeed, it is the only thing that ever has." -- Margaret Mead
> > >
> > > __________
> > > View the list's information and change your settings at
> > > //www.freelists.org/list/programmingblind
> > >
> > __________
> > View the list's information and change your settings at
> > //www.freelists.org/list/programmingblind
> >
> > __________
> > View the list's information and change your settings at
> > //www.freelists.org/list/programmingblind
> >
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
>
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
__________
View the list's information and change your settings at 
//www.freelists.org/list/programmingblind

Other related posts: