|
Preface
The
What is better? Smarter programmers or safer programming environments?
is the impetus for this article. After I stuck my foot in it
(again), saying that .NET and MFC are not frameworks, Paul Watson asked
one of the two obvious questions--"what is a framework?" (the other
obvious question being, "If .NET and MFC are not frameworks, then what are
they?") Well, Paul's question is an excellent one (and the better of
the two, I think), and it led me down this road in an attempt to put my
money where my mouth is, as it were. So, here
goes. I'd like to hear your opinions as to whether you
agree or disagree with my analysis, what areas you'd like to have explored
in further detail, and whether you think this fits in your own
experiences. I've tried to keep this article brief (isn't that a
welcome change?), and I'll leave it to the reader responses to determine
if there's anything that needs elaboration.
Introduction
From my perspective, a framework does several things:
- it makes it easier to work with complex technologies
- it ties together a bunch of discrete objects/components into
something more useful
- it forces the team (or just me) to implement code in a way that
promotes consistent coding, fewer bugs, and more flexible applications
- everyone can easily test and debug the code, even code that they
didn't write
If I look at this list of vague framework requirements, I come up with
a set of specific classifications that define a framework:
- wrappers. A wrapper:
- simplifies an interface to a technology
- reduces/eliminates repetitive tasks
- increases application flexibility through abstraction
- are often re-usable regardless of high level design considerations
- architectures. An architecture:
- manages a collection of discrete objects
- implements a set of specific design elements
- methodologies: A methodology:
- enforces the adherence to a consistent design approach
- decouples object dependencies
- are often re-usable regardless application requirements
So, before talking about frameworks, we need to talk about wrappers,
architectures, and methodologies. After that, I'm not sure what will
be left to say about frameworks!
A Framework Is...
A Wrapper

A wrapper is way of repackaging a function or set of functions (related
or not) to achieve one or more of the following goals (probably
incomplete):
- Simplification of use
- Consistency in interface
- Enhancement of core functionality
- Collecting discrete processes into a logical association (an object)
It's easy to fall into the idea that everything is a wrapper, just like
saying "everything is relative" (which is untrue, because that statement
itself is an absolute), but if you think about it, not everything is a
wrapper. Most of MFC and .NET are wrappers are the core API's.
Some are laughably so, providing classes that merely wrap messages into
inline methods. Other wrappers are more complex. For example,
I've written a wrapper for the Visio COM object that takes all the grunt
work out of using Visio's primitive functions (primitive in the sense of
"fundamental", as opposed to "poorly implemented") to do basic things like
drop shapes, connect shapes, and read a shape collection.
But then, you get into implementation that truly provides new
functionality. Yes, it utilizes other objects, other API's, even
other wrappers, but it isn't a wrapper in itself because it does something
totally new, rather than just adding to, subtracting from, or managing a
collection of existing work. A wrapper modifies existing
behavior. There's a lot of code out there that creates new behavior
(thus becoming subject to
An Architecture

An architecture is a style that incorporates specific design
elements. Obviously, a framework needs to have a design. Its
architecture is separate from the collection of wrappers that it
implements and from the enforcement of a specific implementation
methodology. MFC's document-view classes are an architecture.
Essentially, an architecture implements associations between
objects--inheritance, container, proxy, collection, etc.
Architectures have the interesting attribute that, if you don't like them,
you can usually ignore them or replace them (at least at the beginning of
a project). Architectures can and are useful because they create a
re-usable structure (a collection of objects) that provide some enhanced
functionality, but once you start using them, you're pretty much stuck
with them unless you do some major refactoring.
A Methodology

Let's look at this word:
- Method - a way of doing something
- -ology - in a "scientific" manner--designed, consistent, repeatable,
testable, proven
or, if you want to look it up in the dictionary: A body of
practices, procedures, and rules used by those who work in a
discipline.
OK, we've all worked with design methodologies, but not too many people
have worked with a framework that implements a particular
methodology. I don't think arguing that MFC is a methodology (with
exceptions) is the right way to think about classes. While a class
specifies visibility, interface, and inheritance usage, and these, along
with language syntax, can certainly be classified as "a body of practices,
procedures, and rules", saying that a class or a collection of classes is
a methodology is like saying that a bunch of leaves make a tree. A
methodology fills in the supporting structure. Is MFC's message
mapping implementation a methodology? Mostly, yes. While I
view it primarily as an architecture that wraps the underlying API, and
you don't have to use it if you don't want to, in some cases you pretty
much can't avoid using it, especially when you want to define specialized
message handlers. You have to use the method that MFC implements in
order to specify and override the base class implementation. And
since this is an application wide issue, it fits better into the
definition of a methodology than a wrapper (which it is) or an
architecture (which it is). So, things can be fuzzy, and sometimes
they can feel like splitting hairs, but it doesn't detract from the value
of looking at methodology as a classification.
While architectures deal with the associations between things, a
methodology deals with the interaction between things. The first is
a passive relationship and the second is an activity. Most of the
methodology that I implement is in the activity of communicating between
objects, managing data persistence, responding to user events, etc.
Within those activities are architectures that associate interrelated
objects.
Design Patterns
Design patterns are both architectures and methodologies. The
structural patterns are more architecture, when the creational and
behavioral patterns are more methodologies because their usage enforces a
particular method of interaction. However you implement, say,
behavioral patterns, you're entire application has to adhere to that
implementation. However, I will say this one thing--design patterns
are in a category that I would call "lightweight methodologies".
They are not necessarily heavy handed about how components and objects
interact with each other.
Heavyweight Frameworks
The Application
Automation Layer that I've written about (you really didn't think I'd
write about frameworks without mentioning the AAL, did you?) is what I'd
call a heavyweight framework. It strictly enforces (to within the
reasonable realm of the possible) component management, data interaction,
the usage of external XML files for GUI definitions, scripting driven
functional programming, etc. Now, you may all say that this is
excessive, but I must disagree. We need frameworks like this to
improve quality, consistency, and usability. Furthermore, a
heavyweight framework can (and has been proven to) allow even junior
programmers to be productive in a large scale development effort with
minimal guidance. Why? Because the framework doesn't provide a
lot of room for, well, screwing up. Even as an experienced
programmer, it helps me from screwing up (for example, taking shortcuts)
as well!
Thoughts About Frameworks
Rather Black & White, Isn't It?
At some point, a framework becomes all three simply out of
necessity. You can't implement a methodology without implementing
wrappers and an architecture. Like any other kind of programming,
abstract concepts don't necessarily translate directly into concrete
implementation, and the same is true for the
wrapper-architecture-methodology view. But it's still useful to look
at these two topics separately so that, come implementation time, we can
make better decisions regarding the goals of the framework we are
implementing. For example, the issue of re-use regarding wrapper vs.
architecture vs. methodology is different because the focus of the re-use
is different. For wrappers, the focus of the re-use is the process,
whereas for an architecture, it is the associations between objects,
whereas for a methodology, the focus of the re-use is in the interactions
between objects.
Why Should A Framework Enforce A Methodology?
Well, I wanted to avoid analogies to architecture and buildings, but
this seems like such a good place for one, but, I'm sure you can figure
out the rest of what I can say! So why say it? Well, sometimes
it's important to pour a thought down on paper so it becomes a bit more
concrete (no pun intended). If you only have wrappers, your team (or
just you) is left to build the application in whatever way their
experiences (or lack thereof) have taught them. In the end (if you
even get to the end), you've got a collection of different styles,
approaches, and solutions that have no consistency. This is hard to
debug, hard to maintain, and hard to extend. And you when you're
done, you almost certainly don't want to repeat the experience. A
framework that enforces a methodology, on the other hand, tells each
programmer how to do important things like interface with other
objects/components/technologies, how to manage and persist data, and how
to avoid crossing application layers (as examples). The resulting
application is easy to debug, easy to maintain, and very flexible.
Code Reviews
Code reviews are fine, but they're misapplied if you use them to fix
coding consistency issues. It's like health--you want to be
proactive in preventing disease (dis-ease, ha ha ha), rather than taking a
handful of pills after you get sick. So, code reviews should be used
to prevent sickness rather than to cure a sick implementation. This
means, a code review should always look at whether the framework
methodology is being applied properly, is itself appropriate, and that the
code is, in other ways, handling its requirements correctly.
Unit Testing
If your methodology includes unit testing (and thus a framework to
support this methodology), the issue of meeting requirements becomes
preventative--the unit tests prevent the code from becoming sick in the
first place. However, unit tests can be a lot like the new age idea
of using magnets to cure arthritis--they can be quite useless. And
I'm not going to write about good unit tests here--you can read my
articles on unit testing if you're interested.
Agile Methods
OK, touchy subject with very opinionated people in all camps. So,
I'm going to skirt around the issue and say only that agile methods talk
about how to manage a project more than they talk about how to design the
objects or implement the actual code. This is why they're not much
help, in my opinion. What I've found is that just about every job,
customer, or article requires a unique approach. There is no
cookie-cutter method for working with a customer, figuring out what the
application needs to do, and managing the process of implementation.
There is, however, considerable re-use achievable in how each application
is designed, and the framework and wrappers that are used to reduce
implementation time. Agile methods on the other hand are really good
as ideas you can use to work with the customer or other people in the
company.
What About Creativity?
This argument (which, believe it or not, I've heard many times) holds
no water for me. A two year old can be creative with paint and a
canvas, but you won't get the Mona Lisa. An trained artist uses a
method which allows him to channel his creative forces into creating his
work within the confines of the chosen method. Even Jackson Pollock
had a method to his paintings, although they do look a bit like what a two
year old would do. The point is, a good methodology actually frees
you from the mundane task of figuring out basic things, so you can apply
your creativity in better user interface design, better performing
functions, smoother user experience by using threads, etc. The
result is something aesthetically pleasing to the user. As a
programmer, I can immediately tell you when a product did not have a good
framework methodology because it is clunky, clumsy, rough in performance,
and most likely, buggy (and the biggest indicator of all--it got delivered
a year later than promised). Are you listening, Microsoft?
An Example: The Document-View Architecture
What would it take for the document-view architecture to be a true
framework? In my opinion, this would require an automatic coupling
between GUI controls and the document. The programmer need only
specify issues such as data lifetime, the control representing the data,
and the document (or documents!) containing the data. The framework
would then handle all persistence issues, data translation between the
representation of data in the document and the representation of the data
in the view, and would do so without requiring any coding. A
document-view implementation at this level wraps data translation,
provides an architecture for coupling data with documents, and enforces a
methodology by implementing and hiding the coupling between the GUI
control and the document.
What Does The Rest Of The World Say?
A framework is a set of common and prefabricated software building
blocks that programmers can use, extend or customize for specific
computing solutions. With frameworks developers do not have to start from
scratch each time they write an application. Frameworks are built from
collection of objects so both the design and code of the framework may be
reused. - JavaFramework.
That sounds like an architecture and a collection of wrappers.
OK, 2 out of 3.
A skeleton of an application into which developers plug in their
code and provides most of the common functionality. -- E. Gamma,
et al., "Design Patterns", Addison-Wesley, 1995
Well, now that's a radically different definition, and in my thinking
certainly incorporates the idea of a methodology, if for no other reason
than because the "skeleton" has to define how developers plug in their
code and how they interface with the common functionality provided by the
"skeleton". Implied here (but not necessarily) may also be how the
code intercommunicates.
A set of classes which defines a model of interaction among objects…
-- Moduleco
(of course, they totally blow it in the additional definitions)
OK, this falls into the category of a methodology because it clearly
enforces the interaction style between objects, but it leaves out the
wrapper and architectural aspects.
- A comprehensive, integrated class library
- An entire architecture is the unit of reuse
- Defines the control logic and class interactions of the
application's architecture
- Reduces "dog work" at the cost of some flexibility
--
Software
Engineering Associates, Inc
Hmm. OK, that encompasses the three things I'm talking
about--wrappers (integrated class library), architecture (an entire
architecture), and methodology (defines the control logic and class
interactions). Although, this may not exactly be what the authors
had in mind, especially when reading what they think a design
pattern is, but you never know.
So far, we've seen:
- building blocks
- skeleton
- interaction model
- all of the above (sort of).
Frankly, I'm not sure that there really is a good definition out
there. But really, the one I like best is from the authors of
Design Patterns:
"When you use a toolkit, you write the main body of the application
and call the code you want to reuse. When you use a framework, you
reuse the main body and write the code it calls."
"Not only can you build applications faster as a result, but the
applications have similar structures. They are easier to maintain,
and they seem more consistent o their users. On the other hand, you
lose some creative freedom, since many design decisions have been made for
you."
"If applications are hard to design, and toolkits are harder, then
frameworks are hardest of all. ...Any substantive change to the
framework's design would reduce its benefits considerably, since the
framework's main contribution to an application is the architecture it
defines. Therefore it's imperative to design the framework to be as
flexible and extensible as possible."
This doesn't formally spell out the idea of a framework consisting of
wrappers, architecture, and methodology, but it's certainly all there,
between the lines. And it provides a different definition for what
most of MFC and .NET really are--toolkits, not frameworks. Which is
the answer to the other question--what are MFC and .NET if not
frameworks?
Conclusion
By thinking about what a framework is, I think I've come up with a
fairly good analysis of the subject as an introductory topic. Maybe
what I'm talking about is something different from a framework, but in my
mind, this is what a framework should be and do. There are a lot of
different ideas out there as to what a framework is, so now you have mine
as
well.
You must Sign
In to use this message board. |
|
|
Msgs 1 to 25 of 34 (Total in Forum: 34) (Refresh) |
FirstPrevNext | |
|
 |
|
|
Interesting article about
frameworks. I'd like to know what the difference
between a framework and a model is.
Nxasanism "Amandla"
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
through this article i know
something about framework. and can you tell
me Borland delphi VCL is a framework or not!
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
There could be different kinds of
frameworks or frameworks could be used for
different purposes. Here is how we have defined
a framework for constructing
applications:
"An application services
framework provides a comprehensive set of
services that serve as the software
infrastructure for constructing applications. An
application services framework is the result of
applying a service-oriented design approach to
global application requirements."
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Marc, first of all good article. I
like how you actually provided your own
definitions and backed this up with some
research!
At first, I did not want to
post, but then again, I've always been a fan of
frameworks and OOA/OOD and I've had a lot of
experience in this area, so I figured I would
say a thing or two also. Additionally, a lot of
good posts where written - this could almost be
a 3 credit class.
First of all, the
question of “What is a framework” is a huge
question and opens up an even larger can of
worms. If the answers were easy, we'd all be out
of jobs - the fact that software is what it is
allows us to define higher and higher levels of
abstractions that allow us to debate these
things for ever and ever.
Since I'm
writing about my opinion, I figured I'd give a
definition (short) as well.
A Software
Framework is a set of components (APIs, classes,
objects, libs, scripts, other programs, design
patterns, you name it) and contracts that
provide developers with the building blocks to
write solution architectures (an application, a
component or another framework for that matter).
The key to the definition are tools and
a contract. The contract is what we all know
well with MFC and sometimes we hate it.
This is a very broad definition but it
SHOULD be. We don't criticize a language with
one keyword-token for not being able to possess
a real grammar, so why should we try to put a
specific set of rules around the definition of a
framework - and who really cares. Its just a
label that we give to (a) communicate what it is
and (b) to set some level of expectations for
the developer and author of they wish to make it
better and provides (c) an open architecture -
yes it does most of the work - but also allows a
"way out" - lets you control garbage collection
for example. Design Patterns fall into this
category as well - if someone wants to call what
they write (and I see it all the time in
CodeProject) an implementation of a design
pattern but no one can really use it - then its
still a design pattern in the skewed author's
eyes.
I think of MFC and .NET as
Frameworks for the record. I disagree with your
point about being able to persist the objects
and all.
Here are attributes that
Frameworks may have but this does not define
what a framework is.
The key to writing a
framework is that (a) you think about 100% of
applications (resulting solutions) that you
[Microsoft] want to support but because MFC and
.NET are products you only build for 85% and you
leave the rest for future versions. The guy who
wanted to write a framework and App at the same
time is trying to do the impossible, because (b)
a framework must be built and tested by writing
applications, much like a grammar is to be
tested by writing code. Frameworks also (c) tend
to implement a collection of design patterns and
well known computer science methodologies (I
agree with your methodology idea) rather than
specify only a contract. The key word here is
implementation. MVC is not an implementation, so
I don't think of it as a framework - however its
a pretty cool design pattern for overcoming
short-comings in MFC for example. Which leads me
to my next point, (d) Frameworks solve problems.
MFC does solve a problem but its not the be all
and end all to all problems - this is why
developers need to get off the "lets trash MFC"
band-wagon and wake up and write a better one if
they don't like it! A better explanation - you
might see a framework for supporting
Client/Server (a Paradigm), or another framework
for n-tier - the point again is that Frameworks
are the "implementation" that solves 85% of the
problem. You don't engage in writing a framework
unless you (e) intend to re-use it, much as your
first excuse to write a procedure in your first
Pascal program. You intended for it to be
re-used. A cool thing about having a "contract"
is that (f) the framework's base architecture
can be changed without affecting all the
applications that use it. For example, you can
add diagnostics to the base classes of all your
code or add a profiler and you don't break the
applications - this can be said of a "library"
as a person in this thread said but take into
consideration that (g) frameworks are usually
written by tool developers for non-tool
developers and the "library" drives the
soltuion, not the other way around - this is the
primary distinction. So, is the "C++" start-up
code a framework ? In a trivial sense, yes!
Having said this, its not always this way but
the point I want to make is that typically, you
get a framework from a third-party vendor and
you can build your solutions and get an update
and hopefully (if they did things correctly) it
does not break all your apps. The other cool
things are being able to do what MFC class
wizard and other tools do - peer inside your app
and help you write code conforming to the
framework's contract. You don't really do that
with a library, its just a bunch of methods. Not
sure if I hit on this point, but you usually see
a mature framework implementing several good
design patterns for you - and these things can
also be considered whole products. Perhaps you
can think of products that are like frameworks -
I think anything that provides a scripting
language could be considered - like Notes or VBA
for example.
A good framework allows the
developer to change the underlying architecture
if they really wanted to, otherwise developers
would just complain again because they can't
change something like the color (ok, I'm getting
sarcastic from reading other posts).
I
try to stay as general as possible and try not
to square peg a round hole when I'm describing
things because after all we want to model the
real world when we write software, so being
specifc means that you are specific about your
real-world experiences.
My major
counter-point to all the lazy people concerned
about MFC is that they provide 85% of the
solution for you but its left to the app
developer to do the rest by using the
framework's contract - override the method and
do the work, etc. To say that MFC should know
how to serialize all objects is like saying that
DCOM and .net remoting needs to be able to
provide standard marshaling for all objects,
etc. We would never get a product - we'd still
be waiting for Microsoft to develop .NET if that
was the case - remember, its 85% of everything
you need to do.
In my travels I see a
lot of people trash MFC - mostly because they
did not understand Windows Messages from good
old 1.0 and WndProc days. I see the same with
.NET and C# - the person who thinks that code
has to be native compiled code to be any good is
way off base. I happen to be writing a real-time
application in C# and I'm about 400% more
productive because of .NET. I see the same with
poorly developed patterns and it goes on and on.
To think these same people know how to make a
better MFC – pretty funny. [They] sometimes
don't even know how to write a well-written
class with one level of single inheritance.
I liked your article and I like how you
presented it and got people all excited about
it. It is after-all a wide-open question but I
like how you stuck it out there for everyone to
comment.
Marty Spallone Blue Object
Software,
LLC www.blueobject.net
|
Sign
In·View
Thread·PermaLink |
5.00/5 (1 vote)
| | | |
 |
|
|
Hi Marty,
Thanks for the
excellent comments! They should be part of the
article rather than the message board!
I
think your point about a framework being a set
of components and a contract. The contract can
be lightweight--expected function parameters,
call usage, expected return values-- or
heavyweight, which covers my ideas of enforcing
a design methodology.
I have a question,
based on what you said and what other people
have said, regarding:
A good framework
allows the developer to change the underlying
architecture if they really wanted to, otherwise
developers would just complain...
OK,
there's two issues here: clearly, a framework
shouldn't get in the way of the developer adding
functionality, but I definitely feel that
a framework should do all it can to enforce
form. Functionality is, for example, when
I try to write an application with a single menu
(File), and MFC asserts because in Microsoft's
world, a menu needs File, Edit, and View at a
minimum (yes, this assert is actually coded into
MFC).
Form is, for example, a design
pattern. In MFC's case, a good example of form
is the message dispatching architecture, which
can be defeated with PreMessage
something-or-other. But that's a relatively
simplistic example. If, for example, your
framework provides marshalling services for data
crossing component boundaries, and you implement
the lowest common demonitor (VB) to be
compatible with other component implementations,
then you are enforcing a form that the developer
absolutely must conform to.
So the
question is, just with MFC and .NET, why should
I care that a developer complains about how the
framework doesn't let him change the underlying
form? I think that's a good thing,
because after all, I wrote the framework to
prevent the developer from shooting
himself in the foot! By that reasoning, MFC's 3
menu item as a minimum assertion is actually a
good thing. 
Marc
Latest
AAL Article My
blog Join
my forum!
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Hey Marc, thanks for the quick
response. I agree with you - hey like I said - I
like to provide general solutions so that they
are as flexible as possible for everyone. Yes it
[framework] should enforce the contract but my
point is that in the 15% casem you may need a
way out and to roll your own or lets argue for
performance reasons, that you want/need to
provide custom marshaling but you want to attack
it at a layer deep inside the framework. Another
might be that you want to take out that MFC
assert that you talk about - you should be able
to do this because you now OWN the framework -
that is the beauty (much like open source I
guess). I'm not advocating this by any means -
actually, I think of the latter as a painful
experience - I'd rather live by the rules of the
framework and force app developers to find
abother way but from I write about all this as a
framework developer - one needs to make sure
they provide a way out or people will hate it or
worse, toss it out for something else.
Frameworks are cool - but as you say
there is an art to creating these rather
difficult architectures - they should be left
for the experienced writer and one that can see
it through to the benefits of supporting many
applications. The true test of course is time
and maybe there is a darwinian thing about them
also - may the best frameworks survive and the
bad ones die off. Long live C# but keep it fair
- we don't need any more C# developers - I'm
happy with the shortage.
p.s. I have been
doing C# for two years now and I keep being
impressed by the amount of framework support
that is there and the amount of time Microsoft
got it to market. I am a pure OO guy who took a
lot of classes and studied this stuff and I must
say C# is a winner and the .net framework will
continue to impress - just think how the Redmond
tools will be after a sparkling version 3 - I
bet better than people think. I've done a lot
owith remoting and created a cool Pub/Sub
component that really works great for my client
and its a pure play component which is nice.
Maybe they will allow me to post it on
CP.
Marty from CT.
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Cool article and responses. Yea I
am all for frameworks (or whatever you call MFC,
Stingray, .NET, etc.). I think they are great
& I enjoy coding within their paradigm -
it's part of the productivty you get from using
them. It’s like painting a picture – there’s
only so much you can do with paint and a canvas
but you can create some pretty impressive
results with them. It’s not like you can create
the matrix with them, but you wouldn’t expect to
either. You work within the boundaries and
limitations of your tools to some extent, and
following their rules, but we are mostly held
back by our own creativity.
However,
after reading all this stuff, I think I could
have written a whole framework with the amount
of time and brain power you guys put into
arguing what a framework even is. Who really
cares what you call it? Do you hear people
arguing about whether a Chalupa at Taco Bell is
more like a taco or a burrito? No they try it
out, if it tastes good they eat it! Same with
.NET – you try building some apps, if it works
& you like it you keep using it for bigger
& better things. If you find it too
restrictive or bulky, you put it aside for
something else.
How about we start
harnessing some of the energy on this board and
instead, brainstorm some cool components and
tools. Pick a topic for something to build &
design & let all these brainiacs loose for
ideas. We’ll let the marketing people decide
what to call the stuff once it's built 
P.S. I've worked with Marty in
the past & think we have created some great
stuff with all kinds of crazy tools. But by far
it is much more interesting solving problems and
designing solutions than it is to argue over
some programming nuance. It does provide some
good entertainment though
LocoSteve "Only two things
are infinite, the universe and human stupidity,
and I'm not sure about the former." -
Einstein
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
i'd like to hear your opinion
about the simultaneous development of the
framework *and* an application using
it.
consider this:
we have two
developers -- one is working on the framework
implementation and the other is programming "the
meat" of the application.
say the app is
using a wrapper for an edit control. then one
day all of these dawn with a nice custom context
menu (localized for instance).
next the
developers decide to implement additional menu
item which opens a custom built-in calculator --
a problem: the framework doesn't know which edit
controls are actually representing numeric
values.
the question is how can one
foresee framework further development this
minimize refactoring effort on the already
implemented application code?
i've been
implementing a custom framework for the past
year and something and know precisely what
you're talking about. the methodology
after-effect comes naturally and code start to
look "suspiciously" similar in different parts
of the app )
the most expensive part is
the constant refactoring effort as the framework
evolves. the application code starts to "age"
and the framework starts complicate as it
continues to support old implementations. at a
certain point in time a complete cleanup has to
be done (breaking old interfaces) and visibly
the development comes to a halt (from customers
perspective).
just my $.02
worth
cheers, </wqw>
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Vlad Vissoultchev
wrote: i'd like to hear your
opinion about the simultaneous development of
the framework *and* an application using
it.
This is about the only way to do
it, in my experience. The first time may be
painful, and actually you may end up throwing
out the framework because you learned a lot.
This is really dependent upon the experience of
the person implementing the
framework.
Vlad Vissoultchev
wrote: the most expensive part
is the constant refactoring effort as the
framework evolves. the application code starts
to "age" and the framework starts complicate as
it continues to support old implementations. at
a certain point in time a complete cleanup has
to be done (breaking old interfaces) and visibly
the development comes to a halt (from customers
perspective).
Well, not necessarily,
and here's why:
If the framework really
promotes componentization, meaning that your
application tiers are implemented as components
(and not necessarily 1 for 1--my AAL has several
presentation layer components--menus, forms,
print preview, to mention a few), then you can
easily replace a component with a new one
whenever you get the chance.
Now, if your
application is really just another set of
components, and it's the framework that provides
the minimal services necessary for the
components to interact, then again, if the
application starts to age, you can replace its
components. I don't do this very often, because
my applications tend to rely on very generic
components, some application specific code in
another component, and a lot of scripting to
glue it all together.
For example, when
Visio came out with their new version (even
before Microsoft bought them out), the COM
interface was annoyingly different. Since the
whole thing was wrapped up in a component, the
developers kept chunking along with the old
version while I wrote a new component wrapper.
The component wrapper had well defined
functionality (by its very nature), so I was
able to test each functionality out. When I was
done, I simply swapped the old component with
the new one (they were DLL's). Without changing
a line of application code (or even recompiling
the app), we were up and running with the new
version of Visio.
This really became an
advantage when we found out the some of the
engineers at the client site had the old Visio
and some had the new Visio. To the application
(automating satellite design and analysis), it
didn't matter because it simply loaded the
specified Visio interface component.
Does
that answer your question to some
degree?
Marc
Latest
AAL Article My
blog Join
my forum!
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
i must totally agree -- i'm
already experiencing these benefits on a daily
basis )
anyway, if you'd like to be
more specific just follow my discussion on the
edit control wrapper -- what i'd like to know is
how do you handle the lack of enough descriptive
data. in my sample case it is possible for the
framework to easily change the context menus of
all edit controls (or combos, or whatever) but
at some point it *might* need to differentiate
b/n numeric and plain-text edit
controls.
as this has not been forseen
beforehand (the wrapper is not initialized with
"edit control data type" param )) for the feature to start kicking a
considerable amount of refactoring has to be
done i.e. discerning numeric and plain-text edit
controls. whether it is an additional param or a
design-time property (VB?) it still might be
considerable amount of work (e.g. an enterprise
app with 300+ forms)
my sample is dealing
with UI components -- might happen virtually at
any tier.
how do you deal with the
unknown? how do you design for change (esp. the
framework
components)?
cheers, </wqw> p.s.
i must find some time to glance at the AAL
(sounds familiar, probably already did)
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Vlad Vissoultchev
wrote: what i'd like to know
is how do you handle the lack of enough
descriptive data. in my sample case it is
possible for the framework to easily change the
context menus of all edit controls (or combos,
or whatever) but at some point it *might* need
to differentiate b/n numeric and plain-text edit
controls.
OK, I can see your point,
but here's how I handled exactly this situation
when I came across it in my own
framework:
First off, I parameterize
everything--GUI, SQL strings, type of data
connection, etc. In the C++ version of the
framework, it's all handled with custom text
file script languages. There's a format for
specifying the GUI, one for workflows, one for
state machines, one for structures, one for data
packet contexts, and so forth.
In the C#
version, I've put everything into XML files.
Now, the disadvantage to this approach is that
you can't use a GUI designer, unless someone
were to write one for me (or I wrote one
myself). And I can't use those wizards that
generate all the data access stuff--connections,
data sets, data views, and so forth. The lack of
GUI designer and wizards really doesn't bother
me at all, anyways.
Anyways, I'll use the
C++ version as a demonstration, since it's
easier to read than XML.
I've got this
control defined in the script for the customer
to enter some rate information:
EDIT edRate at (170, 318) size (150, 20) storage allRate with options (rightjustify) end.
A
bit verbose, isn't it? Anyways, at some point we
realize that we want to allow only digits in
this control. So, I take the edit control class
and write a couple lines of additional code to
handle "numeric" as one of the options in the
options list. So now, the script looks like
this:
EDIT edRate at (170, 318) size (150, 20) storage allRate with options (rightjustify numeric) end.
And
all is good with the world, until somebody
discovers they can't enter fractional amounts!
So I add another option and write the
corresponding parser to allow for a decimal
point, and I call this option
"numericdp":
EDIT edRate at (170, 318) size (150, 20) storage allRate with options (rightjustify numericdp) end.
So,
note that I'm not creating a derived class or
anything. I think using derived classes for
specialization is inappropriate in many cases,
because the specialization takes you down a
certain path. Rather, the same control has now
learned new behaviors. To add this behavior to
my existing forms (and believe me, that is
exactly what I did), I simply went through all
my GUI scripts and added "numeric" or
"numericdp" to the appropriate edit boxes. About
10 minutes later, I was done, and I didn't
recompile a line of code other than the form
component's edit control.
So, to design
for change, I put the initial behaviors into the
wrappers, passing along the "options" list from
where ever it comes from--flat file, XML,
database table, etc. If I want a new behavior
for that control, I add it only to the
control.
Marc
Latest
AAL Article My
blog Join
my forum!
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Here.
.net
is or not a "framework", well. But one thing for
sure a Microsoft trap to constraint you to
Windows platform , you believe .net will cross to
Linux/AIX etc?
Read the link provided to
polish your TRUE C/C++ skill!
|
Sign
In·View
Thread·PermaLink |
1.00/5 (6 votes)
| | | |
 |
|
|
Interesting link. Thanks! Though I
found the link somewhat obsolete/outdated and a
bit too academic.
TW
wrote: But one thing for sure
a Microsoft trap to constraint you to Windows
platform , you believe .net will cross to
Linux/AIX etc?
Well, .NET is actively
being ported to Linux and C# is a standard. So,
it already has crossed this boundary.
As
to the other issue of constraining to one
platform, I guess I can only answer "so what?".
How does this possibly affect me? If I want (and
I really don't, but say I did) to program on a
MAC or Linux or whatever, I'd rather implement
an application using a framework that was
tailored for the OS and hardware. Anything else
results in a clunky kludge full of conditional
compiler directives and non-standard UI.
Yuck.
Marc
Latest
AAL Article My
blog Join
my forum!
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Obsolete? , well, one thing for sure you didn't
read at all. That's up to you, make sure you
live up to your mouth, DON'T USE IT.
C#
already crossed? Far before C#, Java is there
already, so, don't talk c0ck.
|
Sign
In·View
Thread·PermaLink |
1.00/5 (4 votes)
| | | |
 |
|
|
 |
|
|
May be you should read
"
Last modified 11:34:18 CDT 28 September 2006
"
So please let me know if the info
provided in this paper right or not. I have to
write a research paper based on framework for my
school. So is it right to use this paper or not
?
Thanks
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
 |
|
|
 |
|
|
If we stick to Gamma's definition
of a Framework, then MFC defenitely is a
framework. It dictates the architecture of your
applications much more than .NET does.
My
2c only
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Nemanja Trifunovic
wrote: If we stick to Gamma's
definition of a Framework, then MFC defenitely
is a framework. It dictates the architecture of
your applications much more than .NET
does.
How so? MFC does nothing for my
applications except provide some useful classes
and Win32 API wrappers. I get just as much use
out of 3rd party classes like Dundas and
Codejock, as well as CP. Are these all
frameworks? These aid in the development of
applications, not define how they are to be
designed.
- Nitron
"Those that say a task is impossible
shouldn't interrupt the ones who are doing it."
- Chinese Proverb
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Nitron
wrote: MFC does nothing for my
applications except provide some useful classes
and Win32 API wrappers.
What about
Document-View pattern and everything that comes
with it (RTTI, serialization,
notifications,...)? A typical MFC application is
usually made by deriving classes from CDocument,
CView and other classes - that's exactly what
Gamma describes as a framework:
You
customize a framework to a particular
application by creating application-specific
subclasses of abstract classes from the
framework
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Nemanja Trifunovic
wrote: What about
Document-View pattern and everything that comes
with it (RTTI, serialization,
notifications,...)? A typical MFC application is
usually made by deriving classes from CDocument,
CView and other classes - that's exactly what
Gamma describes as a framework:
Ok,
in this sense I would agree. But not all
applications are doc/view. I often use MFC when
dealing with 3rd party embedded software through
NT services or console applications. In which
case my framework is nothing more than the
console.
- Nitron
"Those that say a task is impossible
shouldn't interrupt the ones who are doing it."
- Chinese Proverb
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
Nitron
wrote: But not all
applications are doc/view.
...in
which case I would agree with you. I was talking
about Document-View based applications.
|
Sign
In·View
Thread·PermaLink |
| | | |
 |
|
|
 |
|
|
This is a good article, but I'll
have to disagree that .NET is not a
framework.
While it's true that MFC does
not enforce certain constraints indicitive of a
framework - certainly since developers can
seemlessly access the core Win32 API and do
anything in memory they want without going
through hoops - .NET does enforce such things.
But, as is always the case, one can access the
underlying architecture or direct memory if they
really want to. Most good developers know this
isn't a good idea for portability, but that
doesn't seem to be a problem right now and so it
is done on occasion. (I'm fooling around with
WndProc at this very moment!)
Depending
on the language, one can also access memory
directly in an unsafe context by pinning objects
in memory in order to grab addresses and
what-not. The same could be said for any API /
framework. Using JNI - which Java fully intended
to support - I can get access memory and other
JRE resources that Java couldn't necessarily get
because of the JRE's constraints.
The
same is true for .NET. Using unsafe contexts
requires unrestricted privileges. To say that
this is not enforcable is not true. One must
jump through hoops to get access to unenforcable
(i.e., by the CLR) routines.
As far as UI
contraints, I'll have to agree that they can't
be enforced. But would any good framework dare
put such constraints on developers? I do like
the AAL, but keep in mind it is a mere
option in which applications can be
developed - one of an infinite count. In most
cases, the wrapped common controls to provide a
base that most "developers" work from without
having to rewrite such basic controls (which was
quoted in your article as being a bad thing, and
rightly so). Most of these (I like to call them
code monkeys) will still with what they're given
in the BCL and will come up with beautiful and
ugly arrangements of such controls in a
container that is also in the
framework.
So, I do believe that .NET is
a true framework, Java along with that. MFC does
fulfill the wrapper requirement but doesn't
enforce much of anything else.
Maybe I'm
off the mark a little, but it's just my opinion.
In any case, I agree with the underlying
statements in your article and think it was very
well written!
-----BEGIN
GEEK CODE BLOCK----- Version:
3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++)
L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS--
PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++
DI++++ D+ G e++>+++ h---* r+++
y+++ -----END GEEK CODE
BLOCK-----
|
Sign
In·View
Thread·PermaLink |
| | | |
 | |
|
General News Question Answer Joke Rant Admin
|