psrc@mtunq.att.com (Paul S. R. Chisholm) (08/30/90)
Nuts! I'm well on my way into my second non-trivial C++ program. This one will bring me over the thousand statement* mark for the first time, and I'm learning some lessons. One of them is rather bitter. I like C++; it's a good language to do the coding phase of a software engineering effort in. It forces me to think about data types and initialization a lot more than any other language I've dealt with. I like that. Some of the semantics aren't obvious, and it's not always clear where to find the code that does some of the important stuff. I do find that constructors, by hiding lots of information from the calling routine, make my modules more cohesive. I like object-oriented programming. I wasn't satisfied with the ways I thought to apply it to my recursive descent parser, so I didn't. I did finally figure out how to make the objects I parsed all respond to a common "message" (member function), and I can see that's going to reduce the number of lines of code I write (and make the code more cohesive). But I'm *really* struggling with object-oriented design! I've *finally* become very comfortable with the top-down approach; I can hack out a few hundred statements of code at the rate of a hundred statements every day or two, including the time needed for design (and some specification). I walk down the calling tree, designing and coding as I go. Managing the intellectual process is very straightforward. OOD is different. I seem to need to keep everything in my head, design everything, and only then start coding. The only way I could get far enough to come up with an object-oriented design is do the bulk of a top-down design, and then notice the common elements! Even so, I don't really know where to start, or what the natural next steps are when I've finished one step. Anybody else experiencing this, or should I apply for a job flipping hamburgers at McDonalds? (*Really, not "statements", but "non-commentary source lines". A 1K NCSL program is fairly simple, but not trivial.) Paul S. R. Chisholm, AT&T Bell Laboratories att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
mjv@objects.mv.com (Michael J. Vilot) (09/05/90)
Paul Chisholm writes: > I seem to need to keep everything in my head, design everything, and only > then start coding. > ... > I don't really know where to start, or what the natural next steps are I became a fan of incremental development in 1981, when a project I worked on achieved some success with it. I usually work on larger systems (> 100K NCSL), and it's usually not possible to get all of the design into one head before writing any code. Having some way to record and communicate parts of the design (and a reasonable and consistent notation for it) is very helpful. In Grady Booch's ``Object Oriented Design with Applications,'' he describes a method he calls ``round trip gestalt design'' (or, analyze a little, design a little, code a little). You might want to take a look at it. Be aware, though -- waxing a floor a little at a time without an overall plan can leave you stranded in a corner! In a nutshell, the steps are: - Identify the classes and objects at the current level of abstraction - Identify the semantics of each class - Identify the relationships between the classes and objects - Implement the classes (in choosing implementations, you often encounter more classes and objects at the next level of abstraction, leading to a new round) There's also a notation and a rational alternative to the waterfall process model that we all know -- after 20 years of trying -- just doesn't work. While he's clearly made progress over the ``find the nouns and verbs'' approach Russ Abbott outlined in the early '80s, some people find the OOD method insufficiently precise or ``comprehensive.'' Still, the other methods I've seen are even more vague and ill-defined. He's at least got heuristics for evaluating whether what you're doing looks appropriate. And Grady's method has evolved over the past decade through application on ``real'' projects. So, until something better comes along, his approach seems to be a reasonable place to start. I've found it useful. > Anybody else experiencing this, ... ? I think a lot of people who have ``become very comfortable with the top-down approach'' experience a bit of vertigo as part of the ``paradigm shift'' folks like to talk about in the context of object-oriented anything. It may just be a consequence of old dogs learning new tricks -- I've noticed young children have less trouble with the ideas of classification and organizing objects than many of the engineers I work with! Of course design _is_ *hard*, but I find that OOD is easier than SA/SD because it is more direct -- I don't have to reorient my thinking from the world as a set of things to a set of bubble charts, and again reorient from bubbles to structure charts. On the other hand, this means that I have to cope with the essential complexity of the problem -- I can't hide behind the make-work of producing piles of paper. Oh well ;-} -- Mike Vilot, ObjectWare Inc, Nashua NH mjv@objects.mv.com (UUCP: ...!decvax!zinn!objects!mjv)
tom@ssd.csd.harris.com (Tom Horsley) (09/06/90)
Yep, OOD is hard. I have also recently started trying to use OOD both to
learn OOD and to learn C++ and a critical problem does turn out to be
picking the right classes (just like the best OOD books say).
I selected a fairly small program to start with that I figured would be just
about the right size for a learning experience. I am writing a C++ version
of 'diff'.
What I have so far works pretty well, but I am already on my second round of
re-writing the classes because I keep discovering that the classes I
initially came up with work well for the limited taks of comparing lines in
files, but with a little more abstraction, could serve as a much more
general sort of sequence comparator. I will probably do a third round before
I decide I am done, but then I will have a core set of classes that can be
used in a program like 'diff', or a program like 'patch', or in a system
like 'sccs' or 'rcs'. (Or, for that matter, in molecular biology).
Finding the right classes is hard, but when you find them, you feel really
good about the design. I think one of the major advantages of OOD is the
level of confidence you, as a programmer, can gain when you just know you
have picked good classes and the design is "right". No doubt, this feel gets
harder and harder to achieve as you scale up the size project you are
working on, time will tell :-).
--
======================================================================
domain: tahorsley@csd.harris.com USMail: Tom Horsley
uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle
Delray Beach, FL 33444
+==== Censorship is the only form of Obscenity ======================+
| (Wait, I forgot government tobacco subsidies...) |
+====================================================================+cory@three.mv.com (Cory Kempf) (09/10/90)
psrc@mtunq.att.com (Paul S. R. Chisholm) writes: >But I'm *really* struggling with object-oriented design! >I've *finally* become very comfortable with the top-down approach; > Managing the intellectual process is very >straightforward. The top down approach is nice for proceedural programming, but it is probably not the best for OOP. I have found that a bottom up method works better... Start out by identifying the objects. Figure out what properties they have, what messages they should receive, and how they should act. For example, a window might want idle time messages, mouse down messages, update messages, keydown messages, etc. Now look at all of those objects. Find objects that have things in common -- similar properties, similar messages, or similar actions. Often, you will notice that a certain object will need to be broken up into two or three subobjects, and others can be combined into a superobject. Keep working at this, and you will have an inheritance tree (several, usually). At the same time, you should be doing your containment tree. >OOD is different. I seem to need to keep everything in my head, design >everything, and only then start coding. This is quite true. Only I would add that after you start coding, you will find that you want to twiddle the design some more. This is, in general, good. > The only way I could get far >enough to come up with an object-oriented design is do the bulk of a >top-down design, and then notice the common elements! Even so, I don't >really know where to start, or what the natural next steps are when >I've finished one step. If you start with a top down proceedural approach, you will only be making more work for yourself, and will most likely not have a truly object oriented design. OOD is a different methodology. In general, you first need to identify the objects, then find commonality. Often I find that a CAD system helps. In fact, the wall of my office has two great big pictures (6 pages (reduced 50%) and 20 pages) of the design of my current project... I don't think that I could have seen the inheritance with out the CAD program. (I still need to do another week or two worth of design: I stopped to test key parts for feasability now I need to redesign a bit -- much better than re-coding) >Anybody else experiencing this, or should I apply for a job flipping >hamburgers at McDonalds? If you can handle looking at the world from a different direction, you shouldn't have too much trouble. Otherwise, I would suggest avoiding closing -- it is a real pain. :-) +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
cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (09/12/90)
We should all be pleased that the latest /Comm. of the ACM/ features OOD. -- O-------------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu | Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA V All the world is biscuit shaped. . .