Why MFC still is not OO library ? 
Author Message
 Why MFC still is not OO library ?

    Hello,

    Yes... encapsulation, polymorphism, inheritance are
basic terms of Object Orented Design...

    So do you think that MFC are made using them ?
    I don't think so ....

--
Irmantas



Tue, 01 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

This discussion has gone on several threads across several newsgroups. I
think MFC is what it is because, MFC is primarily a windows developers
framework in C++. Its just a thin wrapper to Win APIs. and It was never
proclaimed to be otherwise. Its not meant to be OO Framework. This is just
to let C++ programmers use C++ to program for windows. I read somewhere that
in the beginning, it was designed to be true OO framework. Then MS realized
that  many Windows programmers would like to use their existing knowledge
about Win API so they retracted and made MFC a wrapper. There are other OO
frameworks which use OOD if programmers wanted true OO framework.

--
Girish Bharadwaj [VC++/MVP]


Quote:

>    Hello,

>    Yes... encapsulation, polymorphism, inheritance are
>basic terms of Object Orented Design...

>    So do you think that MFC are made using them ?
>    I don't think so ....

>--
>Irmantas



Tue, 01 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Quote:

>     Yes... encapsulation, polymorphism, inheritance are
> basic terms of Object Orented Design...

>     So do you think that MFC are made using them ?
>     I don't think so ....

OK, I'll bite.  Why don't you think so?  Are you familiar with the
**__VERY__** "OO" work being done on Patterns?  Have you looked at how many of
the major OO design patterns are present in MFC?

What is more important to you--creating applications or purity of language
usage?

<set flame on>
Sure, MFC "violates" some ultra-legalistic interpretations of encapsulation
because some member variables are public and can be (and frequently are)
accessed directly instead of through accessor functions, but as to the rest of
the charge, that MFC doesn't use polymorphism or inheritance, that shows a
total ignorance of the structure of MFC and (IMO) also a total ignorance of
polymorphism and inheritance.
<set flame off>

If MFC isn't OO, then what would one look to for something that is? Something
that has shown by its track record of shipping successful applications that it
is "better"

Jim [VC/MFC MVP]
To send mail, change spam-me-not to msn



Tue, 01 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Quote:

>     Hello,

>     Yes... encapsulation, polymorphism, inheritance are
> basic terms of Object Orented Design...

>     So do you think that MFC are made using them ?
>     I don't think so ....

Irmantas,

As you know the basic principle of OOD is to find the basic realworld
objects and mirror them in "program" objects.

Now if you do programmig for a GUI you have a dilemma. On one hand you have
real world objects like "customer", "order" etc., on the other hand you
have "real world" objects like a Windows MDIFrame.

The dilemma is that these objects do not necessarily match :)
At least it will be a bad idea to try and match them at any cost.

One idea of OO is that if you model the real world, the program will
"automatically" make sense (if the real world makes sense :o).

In a Windows program this means for the "data processing" stuff the
customers and orders (boring. really.) are the real world, but for the
Windows stuff Windows is the real world. And since Windows is not really
object oriented, MFC was condemned to not be truely object oriented either.
or it would have failed to mirror it's "real world".

Does this make sense?

Anyway, I have a feeling that many programmers that try to mix their OOD
with their GUI run into real problems. That's why I answered your posting.
:o) I'm sure you'll get more practical points of view.

cU
--

                        http://djuga.home.ml.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Retriever 1.0 is out:   http://retriever.home.ml.org

Shareware image viewer, thumbnailer & database
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Tue, 01 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Hello,

One of the stated design goals of MFC is to be a thin wrapper on the Windows
API.   The emphasis on "thin".  MS was not aiming at object-oriented purity
so it is no surprise one does not find this characteristic within it.

Joe O'


Quote:

>    Hello,

>    Yes... encapsulation, polymorphism, inheritance are
>basic terms of Object Orented Design...

>    So do you think that MFC are made using them ?
>    I don't think so ....

>--
>Irmantas



Tue, 01 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Programming in MFC might be "object: oriented, but it is not
"structured".

In the old days, there used to be what was called "spaghetti"
programming. Use of "goto" statements (fortran, Cobol etc), used to
create strands of spaghetti in program listings as programmers tried
to follow the program logic.

Unfortunately, the plate of spaghetti has now been replaced by a bowl
of rice. Program objects do not relate to real-world objects (which
they should, I believe) in a structured environment. In the
document/view architecture, the same real-world object (for example, a
string of text on the screen), is represented internally in multiple
places - in the document file, in the view file, and perhaps in the
resource file.

Purists might argue that they are different objects in each case, but
there is nothing intuitive in that approach. If the problem is to read
some data from a file, do some processing, and then display the
results graphically, all that code should reside in the same place,
and be structured so that someone asked to go and change that code can
examine it and be led through the logic (in a structured and logical
way).

Programming for Windows is really maintenance programming. You are
presented with a really complicated program which has just "grown like
Topsy" over the years, and are told to amend it to add some new
functionality. Because the program is so complicated and undocumented,
you cannot examine the overall structure to ensure that what you are
doing is really the best approach, but instead, isolate your attention
to just your little bit and modify that. How often, when you are
following a MFC Help thread, do you suddenly find yourself in the
middle of the Windows API Help (from which sometimes there is no
escape).

I don't think Windows will be with us forever. It is just getting too
complicated and out of control.

***************************************************************

***************************************************************



Wed, 02 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Quote:

>In the old days, there used to be what was called "spaghetti"
>programming. Use of "goto" statements (Fortran, Cobol etc), used to
>create strands of spaghetti in program listings as programmers tried
>to follow the program logic.

I've had to maintain some of that early code and I can testify to how
bad it could be. But when I learned COBOL in 1970 I quickly saw that
"Perform", and "Perform thru" were a much better way to go.
Competitent COBOL programmers did not write spaghetti code.  

Quote:
>they should, I believe) in a structured environment. In the
>document/view architecture, the same real-world object (for example, a
>string of text on the screen), is represented internally in multiple
>places - in the document file, in the view file, and perhaps in the
>resource file.
>there is nothing intuitive in that approach. If the problem is to read
>some data from a file, do some processing, and then display the
>results graphically, all that code should reside in the same place,
>and be structured so that someone asked to go and change that code can
>examine it and be led through the logic (in a structured and logical
>way).

I strongly disagree here. The Document/View architecture is nothing
more than the combination of several highly regarded successful design
patterns that are intended to give a better, more understandable
structure to complex applications.  

If it (doc/view) is used properly (ie. work _with_ the developers,
understand the intent of the pattern and integrate your own design
with the pattern), it is far more understandable and easier to
maintain than the oversimplified picture of "read some data, do some
processing, display the results".  Yes, there are some extremely
simple examples that do only that, but real-world apps rapidly become
more complex, and it is in those situations that the benefits of
something like the document/view architecture begin to overtake the
drawback of the learning curve.

Quote:
>Programming for Windows is really maintenance programming.

No, wrong.  Somebody had to create the program to begin with.  But I
agree that since there are now so many programs there is a lot of
maintenance to be done.

Quote:
> You are
>presented with a really complicated program which has just "grown like
>Topsy" over the years, and are told to amend it to add some new
>functionality. Because the program is so complicated and undocumented,

Breakin in here.  First, if the program is undocumented and hard to
follow that is the fault of whoever wrote it to begin with. I've long
had a principle for evaluating programmers that says that anyone who
claims to be a professional programmer has to write understandable,
well documented code.  If their code is poorly documented that is a
sign that they aren't a professional, meerely a wannabe hacker.  

We had a guy at our company a few years ago.  Really, quite a smart
young fellow.  Finished his Masters degree while working for me, smart
as a whip, really conceited about his considerable ability, able to
churn out huge volumes of work because of his youthful energy combined
with his considerable talent, and resentful of the more senior people
who wanted him to employ just a bit more discipline in what he did.
He _never_ commented his code, nor did he make any effort to leave
behind anything that would help those who had to maintain it.  Nor did
he make any effort to utilize simple, immediately understandable
structures--he mainly wanted to show how clever he was and how much he
could churn out in a short time. He was greatly approved of by those
who he produced his efforts for because they had their solution in a
short time, but woe to the people who had to maintain it after he
left.  That is a most unprofessional approach. Soon after he finished
his degree he got an offer from a big, well regarded software company
to work as a high-level consultant with them.  I pity anyone who has
to work with this young snot, unless he has learned since then,
because he could care less about whoever has to maintain what he
leaves behind.  I've run into him a couple of times over the years,
and his arrogance hasn't abated, so I have no reason to believe he is
any more of a professional now than he was then--just a talented
hacker.

I've written that long diatribe to illustrate the fact that if you
find yourself having to work on a pile of crap, don't blame MFC--blame
the unprofessional hacker who created the doo-doo you are stuck with.
MFC, properly understood and used, gives structure to complex
situations, it doesn't obscure the structure.

Quote:
>you cannot examine the overall structure to ensure that what you are
>doing is really the best approach, but instead, isolate your attention
>to just your little bit and modify that.

If doc/view is properly used that is exactly what you _can_ do.  For
example, if you are making changes to the way a particular string is
displayed, you can just focus on the view and how it is displayed
there without having to worry if you're affecting how it is read and
saved.   If you change how the string is stored on disk you can just
focus on the document without having to worry if the view will still
display it properly.  That is, if the developer who went ahead of you
did their job.

I recently "returned" to a fairly complex MFC program that I deployed
in our company almost 2 years ago now.  Some changes had been
requested, plus we had an accumulation of minor bugs that had shown
up.  I've been quite happy with now easy it has been to get back into
the code and with my ability to change the relevant portions without
seeing 'gotchas propagated into unexpected areas of the app.  One big
reason for this is that I stuck to and worked with the doc/view design
instead of trying to work around it.

Enough of that.

I'm going to be offline for about a week.  Hopefully the trees at
Crested Butte will let me ski in peace.  



Wed, 02 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

I always get amused by these debates.  For example, by some religions
(e.g., Smalltalk), you do not have OO unless you have dynamic typing.
What this means is that you cannot possibly tell what a Smalltalk
program means until you execute it.  And there is no hope of "type
checking".  To others, polymorphism seems central.  Microsoft hasn't
done as good a job as possible of polymorphism, but I think that was
due to serious lack of experience.  They have further compromised the
OO nature by "optimizing" certain features, no matter how absurd the
concept is (for example, if you call a CWnd method, it doesn't
actually execute the method with your parameters; instead it picks up
whatever random trash is left around in the last message, and this
makes absolutely no sense whatsoever.  But it makes the DLL "smaller
and faster".  That is, it is more important to be small and fast than
correct).

But the real issue is the one of mapping the "real" objects.  We
simply don't have languages that allow us to regroup objects across
different views of organization (for example, problem domain,
implementation domain), and until we do the whole concept of OO is
more marketing hype than technical definition.
                                        joe

On Fri, 13 Feb 1998 17:55:58 -0500, "Joseph M. O'Leary"

Quote:

>Hello,

>One of the stated design goals of MFC is to be a thin wrapper on the Windows
>API.   The emphasis on "thin".  MS was not aiming at object-oriented purity
>so it is no surprise one does not find this characteristic within it.

>Joe O'



>>    Hello,

>>    Yes... encapsulation, polymorphism, inheritance are
>>basic terms of Object Orented Design...

>>    So do you think that MFC are made using them ?
>>    I don't think so ....

>>--
>>Irmantas

Joseph M. Newcomer

http://www3.pgh.net/~newcomer


Thu, 03 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

[ a long exposition on the benefits of MFC, with case studies ]

I agree with Jim totally on the benefits of structured programming, but I am
not so sanguine about MFC.

MFC is really only set up to follow a few application patterns. Doc/View
architecture is fine for a word-processing program, where documents and
views follow accepted definitions, but if the concepts are soft or
idiosyncratic in any way, I find myself fighting doc/view, trying to force a
relationship that MFC doesn't expect. CRecordView gives me the same
problem...it is only designed to show a single record at a time, and if I
want to show a record-selection box or consolidate several records on one
screen, I run into problems. MFC isn't very versatile.

Really, the key is encapsulation. It doesn't have to be doc/view
encapsulation, but your classes must have a strong sense of identity. You
have to say "this part takes care of this, and that part takes care of that,
and never shall the twain meet".

Personally, I feel that stuff (that's a technical term, BTW) should be
divided primarily by category rather than whether it falls under document or
view. For example, let's have an edit box which is supposed to take a phone
number. In a strict doc/view interpretation, I would have an edit box as
part of the view, which takes the phone number and submits it to the
document for evaluation. If the document finds it wanting (improper format
or something), then it should notify the view, which will notify the user.
Just think of the complexity of doing it that way.

What we would actually do, of course, is subclass the edit box and handle
all the work there, only submitting the final, valid phone number to the
document when the dialog box is closed or something. That is exactly what I
think we *should* do -- the edit box encapsulates all there is to being a
phone number, and only an easily transportable final version is passed to
and fro.

-- Agent



Tue, 08 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Quote:
> Personally, I feel that stuff (that's a technical term, BTW) should be
> divided primarily by category rather than whether it falls under document
or
> view. For example, let's have an edit box which is supposed to take a
phone
> number. In a strict doc/view interpretation, I would have an edit box as
> part of the view, which takes the phone number and submits it to the
> document for evaluation. If the document finds it wanting (improper
format
> or something), then it should notify the view, which will notify the
user.
> Just think of the complexity of doing it that way.

> What we would actually do, of course, is subclass the edit box and handle
> all the work there, only submitting the final, valid phone number to the
> document when the dialog box is closed or something. That is exactly what
I
> think we *should* do -- the edit box encapsulates all there is to being a
> phone number, and only an easily transportable final version is passed to
> and fro.

> -- Agent

Don't interpret more into the Doc/View stuff than there is to it. The key
is that you can have one document with several views.
Whatever is only needed in one view and needs not be serialized can remain
in the view (or in the control's class). Only if several views share
functionality it makes sense to do it in the document.

The phone number example is a different problem. For a phone number format
it makes sense to have the edit class do that, but there are "evaluations"
that _have_ to be centralized.
Eg. figure a control that takes a discount value (money). From the users
point of view the _control_ should say "Beeeeep. Max. discount is 15%" (if
you entered 20%). But from the programs point of view this value is checked
against the customers record in the database and the policy on discounts
the company has. It would be obviously inappropriate for the CEdit control
to check against the database itself....

This type of validation rules is called policies, and a company will have
policies on everything...even phone numbers. So it makes sense to
centralize even simple validations, eg. to change the policy for phone
numbers in the databas without having to change the programs source code.  

(sorry for the suada but I really like such discussions :o)

cU
--

                        http://djuga.home.ml.org



Wed, 09 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Quote:

> I am not so sanguine about MFC.

> MFC is really only set up to follow a few application patterns. Doc/View
> architecture is fine for a word-processing program, where documents and
> views follow accepted definitions, but if the concepts are soft or
> idiosyncratic in any way, I find myself fighting doc/view

I think one of the biggest flaws in MFC is the decision to call the
architecture "doc"/view.  People get hung up on "document" as if it had to
represent something like a word-processing document or spreadsheet.  Not so,
not so. Just think of it as "data/view."  

Quote:
> Personally, I feel that stuff (that's a technical term, BTW)

<grin>

Quote:
> divided primarily by category rather than whether it falls under document or
> view. For example, let's have an edit box which is supposed to take a phone
> number. In a strict doc/view interpretation, I would have an edit box as
> part of the view, which takes the phone number and submits it to the
> document for evaluation. If the document finds it wanting (improper format
> or something), then it should notify the view, which will notify the user.
> Just think of the complexity of doing it that way.

I frequently use a pattern in which my "object" (whatever it might be) is
responsible for validating its data.  For example, my "object" might be a row
in a CRecordSet, in which case the RecordSet class contains the validation
logic.  Just because MFC doesn't include classes for every special case one
could imagine doesn't mean you can't roll your own and drop them in--in fact,
it isn't all that hard, once you understand the architecture well enough to
work with the library instead of against it.

Jim [VC/MFC MVP]
To send mail, change spam-me-not to msn



Fri, 11 Aug 2000 03:00:00 GMT  
 Why MFC still is not OO library ?

Actually, MFC also has a number of architectural problems which are
particularly evident in its doc view implementation. The decision to
simplify MVC so that MFC programmers have an easier time for simpler cases
probably cannot be faulted. However, IMHO, the actually partitioning of the
classes was not always well thought out. In particular, more thought should
perhaps have been devoted to how template / manager / document view
cooperate. At the moment there are some {*filter*} features, for example in SDI,
which have to be coded around in a rather ugly fashion. It should be easier
to move dynamically from MDI to SDI and vice versa than it is.

Leo

Quote:


>> I am not so sanguine about MFC.

>> MFC is really only set up to follow a few application patterns. Doc/View
>> architecture is fine for a word-processing program, where documents and
>> views follow accepted definitions, but if the concepts are soft or
>> idiosyncratic in any way, I find myself fighting doc/view

>I think one of the biggest flaws in MFC is the decision to call the
>architecture "doc"/view.  People get hung up on "document" as if it had to
>represent something like a word-processing document or spreadsheet.  Not
so,
>not so. Just think of it as "data/view."

>> Personally, I feel that stuff (that's a technical term, BTW)
><grin>

>> divided primarily by category rather than whether it falls under document
or
>> view. For example, let's have an edit box which is supposed to take a
phone
>> number. In a strict doc/view interpretation, I would have an edit box as
>> part of the view, which takes the phone number and submits it to the
>> document for evaluation. If the document finds it wanting (improper
format
>> or something), then it should notify the view, which will notify the
user.
>> Just think of the complexity of doing it that way.

>I frequently use a pattern in which my "object" (whatever it might be) is
>responsible for validating its data.  For example, my "object" might be a
row
>in a CRecordSet, in which case the RecordSet class contains the validation
>logic.  Just because MFC doesn't include classes for every special case one
>could imagine doesn't mean you can't roll your own and drop them in--in
fact,
>it isn't all that hard, once you understand the architecture well enough to
>work with the library instead of against it.

>Jim [VC/MFC MVP]
>To send mail, change spam-me-not to msn



Tue, 15 Aug 2000 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Why am I not getting correct position?

2. Why am I not intercepting Enter key (VK_RETURN)

3. Why am I not getting a LIB?

4. Why MSDN library can not work inside Visual C++

5. Free OO seminar in Denver, CO on best new OO design and reengineering tool in 97

6. OO C using defines and special libraries?

7. Why no MFC AppWizard (static library)?

8. C# events not very OO

9. C is not OO.

10. Fortran IMSL will not link w/ MFC, WHY????

11. Why set_terminate is not working in MFC under VC 7.0

12. Why BOOL and not bool in MFC?

 

 
Powered by phpBB® Forum Software