Re: More CChildFrame questions

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

No, each view is represented by a single object in the document, and that object has the
"several variables and arrays" in it. So one variable is required in the docment, the
(most likely pointer to the) value object that holds all the data.

Why do you think these variables all need to be in the document? Note that where you
store the values (a value object) and how you access the values (a pointer to a value
object) are not the same thing.

Suppose you have three ints to represent a trivial display:

int x;
int y;
int z;

then you would create

class DisplayInfo {
public:
int x;
int y;
int z;
};

and you would have in your document a SINGLE VARIABLE:
DisplayInfo info;
or
DisplayInfo * info;

Note that if you have multiple views, you could have
DisplayInfo * WhateverView;
DisplayInfo * SomeView;
DisplayInfo * AnotherView;

and so on. Where you thinking of doing
int WhateverView_x;
int WhateverView_y;
int WhateverView_z;
int SomeView_x;
int SomeView_y;
int SomeView_z;
???

That would be a bad design.

Note that if you "know UML" then why didn't UML tell you that your design was bad? This
is what I meant by "Voodoo design". You can create all the UML diagrams in the world, and
they don't tell you that you have confused two orthogonal concepts!

I've had to review designs done by "UML Experts" and they are uniformly bad designs.
Pretty pictures picturing bad designs doesn't contribute to the design process, and they
were convinced that because they had pretty pictures, they had good designs. One project
I worked on had a set of UML diagrams which ran for 20 pages claimed to enumerate all the
possible state transitions; we found six that they hadn't considered, and in fact were not
handled by their code; the only effort we had to spend was reading those 20 tedious pages
to make sure that each of our cases wasn't actually covered. But the diagrams were quite
pretty. Useless, but pretty.

We wrote the state machine as an FSM diagram and studied the code and realized that they
had not designed from a formal model, just an enumeration of all the states they had
thought of, and so we went back to verify that it all was consistent, and it wasn't. But
when we wrote our critique, the answer came back that "the design is complete and we have
the UML diagrams to prove it", and it took weeks of arguing with their manager that the
code was wrong before he was willing to accept that the code couldn't work. We finally
generated a test case that locked the code up into a non-recoverable state. Since this
code would run in an embedded system, this would have been a serious bug requiring a
massive recall, had it actually shipped.

I've hit a lot of UML "True Believers" and as far as I can tell, every one of them thought
that if they used UML their design would be correct, and in NO case have I found a correct
design as a result. In these cases, the code accurately reflected the design, and the
code was uniformly wrong. In addition, it usually reflected fundamental bad design such
as violation of abstraction boundaries, poor control constructs, poor data abstraction,
and so on.
joe

On Fri, 22 Jun 2007 11:00:42 +0100, "GT" <ContactGT_remove_@xxxxxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:d50m73h0jneqatmb0j791h2g2ruh6namsa@xxxxxxxxxx
I see no reason the document needs to be either complicated or require very
long names.
Consider that the document needs but a single variable for each view, such
as a
pointer-to-the-computed-graph-data. One variable, one name, the document
remains
trivial.

No - each of my 6 views have several variables and arrays. The 'computed
graph data', the scaling, the actual marker on the chart, the x scroll
factor, the x scroll factor and some other minor things. At present, to
improve readability and maintainability, the variable names are the same on
each view, so I will have to introduce some prefixing method to the variable
names when I move them into the doucment, thereby making the variable names
longer. I will have to use pointers to that data in my view class to point
back to the document variables, which will have to be declared public or
have get and set methods associated - this is all very untidy and not good
design! However it gives the advantage of separating the view class from its
own data, so the view class can be instantiated and destroyed without
concern for the data.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: exe error, works on some pcs but doesnt on others
    ... Make sure you have a .msi file to install it; create this using the install project ... the "wizard" is crippled (another piece of irresponsible design) ... int GetScreeny ... GdiplusStartupInput gdiplusStartupInput; ...
    (microsoft.public.vc.mfc)
  • Re: Test Driven Development Sample
    ... "Isaac Gouy" wrote in message ... > scores for a possibly incomplete sequence of valid throws - update the ... "how" aspect of the design. ... int FrameNum; ...
    (comp.object)
  • Re: Inheritance
    ... Yes I think you are right, it is a bad design. ... int wheels; ... class glider: public monoplane { ... Given this hierarchy, I can probably come up with actual planes that don't fit it. ...
    (microsoft.public.vc.mfc)
  • Re: [CodeGallery] MFC MD5 Calculator
    ... Then when they added types, internally, the compiler still thought they were int values, ... ANSI standard began to emerge that the language design ...
    (microsoft.public.vc.mfc)
  • Re: Interface usage best practices
    ... > The dynamics of the physical elements of the design. ... anything one does with software can be described with existing UML. ... >>and unambiguous semantics. ... On the standard side, the squiggle definitions and the organizational ...
    (comp.object)