Model-View-Controller — Misunderstood and Misused 221
paradox1x writes "Malcolm Tredinnick shares a terrific rant against the misunderstanding and misuse of the Model-View-Controller design pattern. In particular he takes issue with the notion that Django should be considered an MVC framework. He says that 'It's as valid as saying it's a "circus support mechanism," since the statement is both true, in some contexts, and false in others (you can definitely use Django-based code to help run your circus; stop looking so skeptical).' I'm not sure I agree with the entire piece, but it is a very good read." We recently discussed another look at the bending and stretching of MVC patterns in the world of Web development.
Pedantry (Score:5, Insightful)
Well, that's never happened before!
Indeed (Score:2)
Re: (Score:3, Funny)
I agree. This article was heavy on opinion and serves very little purpose. Who cares what this guy thinks about how certain, similar patterns are named?!
Well, in any case I'm very excited about this new "Circus Support Mechanism" (CSM) pattern... What's it do? I don't know! But it's cool!
Re: (Score:3, Funny)
Perhaps it's a new transport mechanism, designed to compress, transport and unpack data objects(we can call them "clowns"). The cool thing would be that you get more data out during the unpack stage than you'd ever think would fit in so small a transport (we could call that a "car"!).
There you go.
Re: (Score:2)
Web Frameworks (Score:5, Insightful)
The custom web framework my company uses helps program with the MVC pattern, but doesn't enforce it. Some developers are very consistent with separating the model, templating, and control structure. Some developers (not always the less experienced ones) often intermingle functionality and don't realize they're no longer within the MVC design. So our framework is nice that it's flexible, but it also will let you hang yourself. Most other frameworks, at least for PHP and Python, seem to be the same way.
Re:Web Frameworks (Score:4, Interesting)
Most other frameworks, at least for PHP and Python, seem to be the same way.
In fact, the only one that I can think of that is purposefully NOT that way is the Ruby on Rails framework which takes the path of "punishment" in the form of "ugly code" for those who attempt to deviate from the orthodoxy of the framework. In my opinion "punishing" developers for deviations is NOT the best way to promote your framework, but the Ruby on Rails disciples will not be convinced otherwise so I have given up trying.
Author is Pedantic (Score:5, Insightful)
And does quite a bit of complaining about Django without completely demonstrating his point. I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller" is, which is really the heart of the matter and where most people seem to disagree. His "model" of what MVC is is not explicated in his view, as represented by his blog post.
MVC is a pattern, not a set of rules, a coding style, house style, development framework, or development process. If you have three modules, one doing presentation, one doing state, and one mediating, you're doing MVC. What specific functions go where (is sorting on the model? is validation of this field in the view?) is specific to the problem domain.
IMHO
Re: (Score:2, Insightful)
The model should handle all data, the controller should handle processing and the container should handle higher level functioning for gathering the model, the view and the container.
See PHPulse [sourceforge.net] as a very simple example.
Re: (Score:3, Insightful)
How do you reconcile view caching with this idea? I'm not arguing with you, mind you, but I'm wondering that if there's a cache involved does that immediately negate calling the pattern MVC? Another violation of this is AJAX. It has logic as client-side as you can get.
I think what the TF author might be thinking is that MVC means exactly this pattern applied at this level, and not scaling the pattern up to web server / app server / database server. Or if that's it, then we shouldn't call it MVC but s
Re: (Score:3, Insightful)
I think the idea is that the view is interchangeable and isn't expected to do anything in order to allow the system to function but it can of course have extra functionality that is not necessary but increases the userfriendliness. The view can validate the user inputs to spare the user some grief but the controller should never expect the view to behave in any way.
Re: (Score:3, Informative)
Re:Author is Pedantic (Score:4, Interesting)
...the idea that the view should never contain logic at all is quite dogmatic and as such doesn't work well on the real world...
I think that's what the OP is trying to say when he comments that 'MVC is a pattern'. Patterns help solve particular problems, but when following the pattern in the most purist of the sense doesn't solve the problem (or gasp! make it bigger!) then being 'pure' doesn't make sense.
Take AlertBox [useit.com]. I think there some gems in his usability suggestions, but if you follow his guidance to the 't', you end up with a boring and un-user-friendly site like his.
Re: (Score:2)
Thus AJAX calls st
Re: (Score:2)
Re: (Score:2)
The view should do ZERO processing.
practicality beats purity.
Re: (Score:2)
Exactly. Reminds me of the old saying: "Dogmas are wrong, always.".
Django is a good example for the drawbacks of this approach since it went to the extreme and allows almost no logic in the templates - beyond the usual iteration and conditional constructs.
The result? It's a pain to develop with this part of django. Django constantly gets in the way here because you can't scribble even the smallest thing into a template to see if it works or "feels right", you have to fiddle with the controller or a custom
Re: (Score:2)
What good is a view that doesn't do any processing?
Let's look at this from a GUI application standpoint. Are you suggesting that drawing methods should live in the controller, or even the model? If so, what role does the view play?
As far as HTML generation is concerned, the place that you create the HTML is the view. You have to have at least some logic in this area unless your application is no more complicated than "Hello, World!"
Re: (Score:2)
AJAX needs to be treated as it's own MVC layer; as being separate but symbiotic with the server side. This is why jQuery is referred to as a framework... because it essentially is. Bu
Re: (Score:2)
Since Cocoa pushes MVC, I will use it as an example. The drawing I am talking about is the stuff that happens in the drawRect method to be shown on the screen. This, as far as I am concerned, is the view.
As I said, if you pushed that logic out into the controller as the grandparent suggests, why would MVC even need a V?
Re: (Score:2)
More frameworks need to follow the lead of PHPulse by doing it this wa
Re: (Score:3, Insightful)
Sounds exactly like how Rails does it, and has been doing since long before PHPulse was ever released.
Re: (Score:2)
In fact, most Ruby sites use PHP still in order to scale [shiflett.org]. And yet, somehow, Ruby fanatics still deny this to this day... sad really.
Re: (Score:2)
There is nothing about Rails that prevents it from scaling. Anyone who claims that Rails does not scale obviously does not understand what scaling means.
Also, I am certain I can write PHPulse code that does not scale.
Re: (Score:3, Insightful)
I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller"
It's always good to define one's terms before one begins to write about them. If you ask 10 different experienced developers what MVC is, you'll get 10 different answers. The problem with this article is that we never get what the author's interpretation of what MVC really is.
But no matter what one's definition of MVC, its like OOP. With OOP, it has been said that any substantially complex system is actually going to require some sort of implementation of OOP, even if its hopelessly half-assed. The same can
Re: (Score:2)
And assuming at least one of them has it right, that means 9 people are wrong. MVC (original or model 2, thats about as far as defining it needs to go) is a documented software design pattern. By definition, software design patterns are meant to be standard, documented (thats the main part) ways of solving a recurring problem.
You may have a Model, a View and a Controller without having MVC. MVC or MVC Model 2 mean som
Re:Author is Pedantic (Score:4, Interesting)
Design patterns ARE obvious ideas. They're just obvious ideas people agreed upon and put into books. They're not standards of the ISO/Ansi type, they're just heavily agreed upon. Call it a convention, if you will. They're not used as a "cookbook" solution to problem: they're used so we can communicate common ways of structuting code better.
For example, it is much easier to say "I implemented the picture processing code of images using the Strategy pattern" than to say "I implemented the picture processing code of my images using an algorythm that takes an object in parameter which implements a specific, common interface which involves a particular method that will handle the format-specific processing which will allow us to more easily plug in new formats in the future". Design patterns make up a vocabulary thats commonly agreed upon, thats language agnostic, that is very often taught in schools, etc etc etc.
Until people started taking MVC as anything involving a model, a view and a controller, I could say "MVC model 2" to anyone (in the know), and knew -exactly- what I meant. Not anymore in this case (thus this article), but it still holds true for the core design patterns as described in most design pattern books, the most well known being "Design Patterns: Elements of Reusable Object-Oriented Software", which is one of the most well known references in software development and architecture. But if I look up "Adapter design pattern" on Wikipedia, in my "Design Pattern with C# 3.0" book, in the book I described above, or in my best buddy's university notes (who went to a different college as me), it all described the -exact- same thing.
Hope that answer your question.
Re:Author is Pedantic (Score:5, Interesting)
Old-school developers liek myself have a significant problem with Design Pattern: they're new and confusing names for old ideas. Almost everything in the Gang of Four's book, for example, was some work-around for some limitation of C++. For example, I have to look up what the "strategy" pattern means, but I know how to pass a function in a language with first-class functions.
To anyone with a strong grounding in Computer Science, the Strategy pattern doesn't need a name - it's simply "The picture processing code of images takes a function as input".
And in any case mostof the fresh college hires I work with don't know what the "Stategy" pattern is (without looking it up) *either*, so giving it a name doesn't help the conversation at all. But I can tell them "don't hard-code your algorithm choices in a switch-case, store a pointer (function pointer, interface-typed pointer, whatever) as a member and call that" they understand both *what* I'm talking about and *why*.
With MVC in particular, it's received wisdom that all good GUI code is MVC, so of course all GUI code will be documented as ussing MVC. The clarity of term has been destroyed by the hype.
Re:Author is Pedantic (Score:4, Informative)
Seems like you have been mislead on a lot of concepts. Design patterns have ZERO (or very little) with the implementation. What they are about, is the intent. If most fresh college hires you see don't know Strategy, its time you look at hiring from different colleges, it is fairly standard, especially in software engineering degrees (a lot less in purist computer science schools, I'll admit).
Btw, while it is a possible implementation, it is actually uncommon (and not desirable) to implement Strategy by passing a function to a method, as that doesn't allow for a good upgrade path of the API (which is what Strategy is about).
Finally, not all good GUI code is MVC, far from it actually, as it doesn't apply well to event driven and composite application (the former is a large amount of desktop application, the later is also a lot of desktop application, and some heavily customizable web application package), in which case, one (out of many) prefered pattern is MVP, as MVC doesn't play well with the existing APIs and framework.
Finally, very few design patterns are "work around some limitations of C++", because, a gain, design patterns have nothing to do with the implementation, but everything to do with communication and intent. So Singleton in Ruby is actually built in, so you don't need to implement it at all. The concept of Singleton is still there when you talk about it. Observer in .NET doesn't need to be implemented, it is built in (multi-cast delegates). If your intent is to use Observer, thats still what is commonly talked about. And so on and so on.
They are more prevalent in certain fields than others, too. If you take a typical team that works on device drivers full time, you'll probably never find someone who has heard (much) about them, thats understandable.
Re:Author is Pedantic (Score:4, Insightful)
When I firt read Design Patterns 15-ish year sago, I was hoping for a book of insightful best practices, but instead found a bunch of ideas that were obvious to anyone skilled in the art, being given arbitrary names and then heavily obfuscated with UML. The majority of these "paterns" were things that were trivial to implement in (or just built into) other languages, but hard to do in C++. Somehow people thought this was ome major revelation. I still don't get that.
And IMO it did more harm than good, merely because people saw "singleton pattern" and reverted to heavy use of global storage claiming "it has to be OK, it's a design pattern". Sadly, that's the one that fresh college hires do seem to know.
Of course, I do work with device drivers and other "systems" code, not CRUD code, so maybe I'me just not in the right field to "get" these.
Wrong. (Score:4, Insightful)
Author is Pedantic
No he isn't. He critisizes the incorrect use and application of the term MVC and the misconception and the pointless enforcement of a wrong concept of MVC in places where it is often more than pointless to do so. Like in most modern web application scenarious.
And does quite a bit of complaining about Django without completely demonstrating his point.
No he doesn't. He uses Django as an example for all current hip Web FWs out there to emphasise the issue above. And he clearly states that before he even goes into Djangos documentation and concept of MVC.
Re:Wrong. (Score:5, Funny)
Author is Pedantic
No he isn't. He critisizes the incorrect use and application of the term MVC and the misconception and the pointless enforcement of a wrong concept of MVC in places where it is often more than pointless to do so. Like in most modern web application scenarious.
I think you just pretty much quoted the dictionary definition of a pedant [merriam-webster.com], specifically definition 2B.
Rather a lot like I'm doing now. </pedantic>
Re: (Score:2)
And he clearly states that before he even goes into Djangos documentation and concept of MVC.
He ignores Django's own take [djangoproject.com] on their differences with traditional MVC, and prefers to just bash a straw man.
Re: (Score:2)
Re: (Score:2)
What specific functions go where (is sorting on the model? is validation of this field in the view?) is specific to the problem domain.
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
"If you have three modules, one doing presentation, one doing state, and one mediating, you're doing MVC."
But if your presentation module is mediating with the state then you aren't.
Re: (Score:2, Insightful)
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
High latency or intermittent connection scenarios where you can't check back with the controller all the time and it's better to avoid unnecessary calls if you can tell the user that the input is invalid anyway? Sure, the controller would of course still do validation but that doesn't mean the view can't tell you what's wrong without needing to connect to the controller.
Re: (Score:2)
High latency or intermittent connection scenarios where you can't check back with the controller all the time and it's better to avoid unnecessary calls if you can tell the user that the input is invalid anyway?
But that's funadmentally not doing MVC anymore. You've got the presentation (view) module is doing validation (controller function).
Sure, the controller would of course still do validation but that doesn't mean the view can't tell you what's wrong without needing to connect to the controller.
The 'cor
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But now you're talking about the MVC Except pattern. In other words, it's MVC except for a few things we threw in there. So in the case you've cited, you've broken the MVC pattern.
That's not to say that what you're doing is wrong. In this case being slavish to a pattern creates worse software.
Re: (Score:2)
I'd be hard pressed to envision a scenario where field validation is logically a -view- function.
You've never programmed for a 3270 workstation, then. Basic field validation was part of it's firmware for the simple reason that users wanted fast, immediate feedback for basic errors (like trying to enter letters into a numeric field, or trying to put too many characters into a text field with a maximum size), and with block-mode communication between the workstation and the server that meant the workstation
Re: (Score:2)
Then they stuff up.
Re: (Score:2)
You've never programmed for a 3270 workstation, then. Basic field validation was part of it's firmware for the simple reason that users wanted fast, immediate feedback for basic errors (like trying to enter letters into a numeric field, or trying to put too many characters into a text field with a maximum size), and with block-mode communication between the workstation and the server that meant the workstation had to do that validation. You simply couldn't submit the entire form back to the server on each a
Re: (Score:2)
Field validation is not a view function, agreed.
The view is obviously allowed to understand what is being viewed. So the view can provide "friendly" services, like providing popup calendars on edit boxes, or even simple "pre-validation" on input fields. Hell, if you like the view can grab the correct service interface and lookup the damn 3D model of the widget being edited.
The controller should not rely on the view to perform any validation. As long as the controller controls the view only via its interface
Re: (Score:2)
Not really. MVC requires some very specific things from the layer that's doing the mediating. More often, you end up with something like MVP (Model-View-Presenter), or even something else entirely.
Re: (Score:3, Informative)
Author is Pedantic... And does quite a bit of complaining about Django without completely demonstrating his point.
Malcolm's blog assumes that the reader has a *very* good understanding of the django codebase. That's understandable, given that he rewrote most of the ORM prior to the recent 1.0 release, and most of his readers know it.
I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller" is, which is really the heart of the matter and where most people seem to disagree.
His basic point is that no one actually knows what the controller *is*. The term is so poorly applied that it loses all meaning.
Really, this is a long standing point in the django community, and can be traced back to the original authors of the framework. Because django uses three primar
Re: (Score:2)
I don't clearly understand the author's point of view either. Besides, everybody knows that Django is a Model-Template-View pattern and not a Model-View-Controller pattern anyway.
Patterns shmatterns. Django is awesome either way.
wait a second! (Score:5, Funny)
Wait a second, there's programmers that aren't using only pure algorithms, refined from the finest electrons, bred from the keyboard controller outputs of Bjarne Stroustroup himself? Well damn, standards are just slipping everywhere. What next, thinking of the web as a platform? Client-side security? Linux on the desktop?
Re:wait a second! (Score:5, Funny)
The purest algorithms never touch a keyboard; only pencil, paper, and thought.
Re: (Score:2)
The purest algorithms never touch a keyboard; only pencil, paper, and thought.
The purest algorithms wouldn't be constrained to any language that is composed of a finite set of symbols -- therefore, no pencil or paper. Probably no thought, either (at least, not limited human thoughts).
Re:wait a second! (Score:5, Funny)
Re: (Score:2)
Re:wait a second! (Score:4, Funny)
Paper is for sissies. If pressed, I just write it in the margin (provided there is sufficient space).
Re: (Score:2)
Welcome to the real world [is.gd], I guess.
Re: (Score:2)
I think you meant Don Knuth
Re: (Score:2)
huh? (Score:5, Funny)
Since when did they let long winded douchebags with nothing to say have blogs?
Re: (Score:3, Insightful)
I like the prologue (Score:5, Funny)
As I started reading, I discovered I don't care enough to read the whole thing.
But I thought the beginning was awesome: "You can disagree with me only if you are wrong."
Re: (Score:2)
There's an old way of using the term that refers to a way of making GUI desktop apps in an object-oriented language. There's a newer use of the term, or a synonym that describes a broadly similar way of structuring applications that is different in many key technical ways, but similar enough that a variety of people have felt comfortable applying the term.
Re: (Score:2)
"There's a newer use of the term, or a synonym that describes a broadly similar way of structuring applications that is different in many key technical ways"
In other words, there's a WRONG use of the term.
Re: (Score:2)
Django (Score:5, Insightful)
I was under the impression that the Django team don't consider it to be MVC themselves, but they've just given up the losing battle of explaining the difference to the masses who think that MVC is the only good way you can arrange 3 different tiers of an application. So they've shrugged their shoulders and effectively said "Fine. If you want Django to be MVC, it is MVC. Now drop it and let us get back to developing it.".
Re:Django (Score:5, Informative)
There's some evidence for that in their naming of the application layers:
Model
Template
View
Re: (Score:2, Informative)
Re: (Score:2, Informative)
If you're hungry for acronyms, you might say that Django is a "MTV" framework - that is, "model", "template", and "view." That breakdown makes much more sense.
At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.
Meh (Score:2, Informative)
I'm assuming he pulled the uncited quote from the django book: http://www.djangobook.com/en/1.0/chapter05/ [djangobook.com]
Here's another:
Taken together, these pieces loosely follow the Model-View-Controller (MVC) design pattern.
They don't seem to be too hung up on design pattern purity. Maybe it is different in IRC or the forums.
Re:Meh (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
MVC is good (Score:4, Insightful)
MVC is good. When you understand it at its simplest. But it doesn't need a 'framework', which is where the confusion creeps in. Java is on the one hand so popular, yet so hopelessly constrained in its possibilities and libraries, that apparently this confusion seems to have become 'unrecognisable' as it were: people automatically postfix 'framework' behind 'MVC' because it's so difficult to build web-applications in java without one (well it's not, but they don't usually know that either).
A framework is a meta-language in essence, it 'sits on top' of your project. Libraries OTOH are (usually) written in your own language and 'hang below' your project (i.e. you use them, instead of it using you). Both can provide MVC, but both can provide many other things as well.
I prefer libraries me. I like to know where a request comes in, and be there when it happens. That said, libraries that model my data storage in nice structures and provide templating for output are yummy. But that's all - I feel the programming language should be *my* bitch, not the other way around. So yeah, I've had to write my own template rendering code since the existing ones all had unnecessary limitations rooted in the theory that the template shouldn't contain any code (so how are we supposed to go about iterations, theorists ?) or any complex variables (yet your data modelling library provides for those, thanks a lot !). Took all of a monday afternoon that.
Re: (Score:2)
> (so how are we supposed to go about iterations, theorists ?)
Like you, I've written a number of template engines because I didn't like the limitations of existing ones (granted, this was in the mid to late 90s, so there weren't many to choose from).
After including iterators and conditionals in two different templating engines, I decided to try to design one without these programming constructs. I had seen too many UI designers find 'clever' uses for loops and conditionals and I wanted to see if it was
Re: (Score:2)
Re: (Score:2)
Sorry, but the thought of XSLT iterators and conditionals makes me shiver a bit. Nice if it works for you, though.
Praise the Lord! (Score:3)
This guy and his essay on the issue at hand is a breath of fresh air in a ongoing onslaught of web-developement misconceptions that increased tenfold ever since countless Java freaks joined the fray with the hype called Ruby on Rails.
I beg all people to read it and read it well. Please.
May I quote one part:
In the MVC pattern, the Model is the application object. It contains all the presentation-agnostic, data-centric logic, which is often labelled "the business logic".
Yes. Say it again. Halleluja!
I'm glad I'm not the only one (Score:2)
I'm glad I'm not the only one. When I first came across the web-based use of MVC I kept scratching my head and alternating between "WTF?" and "You keep using that word; I do not think it means what you think it does." After a while I realized that the web framework community had just latched onto MVC in a sort of cargo-cult fashion, without regard for it's prior meaning.
Not that it's the first time such a thing has happened. Think "structured" and "object oriented" or even "secure." For that matter, c
Breaking the MS WIndows monopoly (Score:2)
The issue I see MVC addressing is the transition from Model-View-Controller to Model-View (or Document-View) to just plain View, or widget, the MS Windows default state of affairs.
The temptation is to place all of the functionality into one entity -- a widget, an ActiveX control. Model, GUI presentation logic, how it interacts with everything else, all this is packaged into a unitary entity. Great for lock-in to a vendor or OS or platform.
In my thinking, controllers serve a useful purpose to break free of
MVC was/should be more than this (Score:2)
Yes, but there is (or at least was) more to it than that.
The model is/was supposed to house all of the details about how things interact, without regard to how you want to look at them (views) or mess with them (controllers).
Nowadays, models are more times than not just a sort of glorified persistence layer, describing the data in static terms and lacking the juicy details of how the data dances.
--MarkusQ
Re: (Score:2)
They only harm themselves too. I find most PHP frameworks are much more difficult to learn than they really should be simply because they muddy the waters so much with regards to what is in and where each of the components of MVC sits in their particular implementation.
HWND Duck; (Score:2, Funny)
If it walks like a duck, quacks like a duck, and runs on Windows, it must be an MVC application. --unattributed, possibly from Microsoftology, MCSE III
Bulshytt (Score:2, Insightful)
In web applications the generated HTML is the view. The template code and javascript are the controller. The model is anything and everything providing input to the template.
Just because something is painful or stupid doesn't make it any less MVC.
(What would break his precious pattern definition is putting data-mutating logic in the template, like every php application ever written. Which I guess is the only real value of MVC - it's a simple rule of thumb to prevent noobs from hurting themselves.)
Welcome to the club, old timer (Score:2)
This is the same rant that happens every time a good idea gets corrupted in IT by marketroids or half bright monkeys:
OOP, relational databases, software libre (which isn't the same as open source BTW, and I prefer the term "libre" since the word "free" is overloaded and hence misunderstood in the English language), distributed computing, WWW, XML or whatever.
One of the many reasons I have chosen a new career path.
terrible article (Score:2)
what a whiner.
Glossary? (Score:3)
Can we have a glossary or something? I've been programming (C, Assembly, some C++) for 10+ years and I have no idea what the author is talking about or any of the commenters here. Patterns? Templates??
Interesting MVC notes by creator of MVC (Score:3, Interesting)
Here are some interesting notes from Trygve M. H. Reenskaug, who originated the term "Model/View/Controller" while at Xerox PARC in the 70's.
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html [ifi.uio.no]
He seems to be a pretty remarkable character... still hacking at the age of 78, with a note on his new project:
Design Patterns - The Book (Score:2)
I don't really see why discussing MVC is as all that and a bag of chips as the author contends. I commonly use the concept of MVC with respect to Django and when I do I always reference this book:
Using the definitions as described in this book Django easily fits in the MVC design pattern.
People I work with "get it" and I've not encountered and confusion alluded too by the author when using the term as defined by the aforementioned book.
Langu
Have you every noticed? (Score:3, Insightful)
Have you ever noticed that guys that write subject matter such as this are the
ones that could not code themselves out of a paper bag?
mvc bla bla bla views bla bla bla models bla bla bla
Not the first to say it (Score:3)
I argued much the same thing [garfieldtech.com] in much less space 2 years ago. :-) Most "MVC" web frameworks are anything but, and it is disingenous to claim that they are. It's a marketing gimmick for people that don't actually know what they're talking about.
Re: (Score:3, Funny)
I am intrigued by your Model View First post!11! software design pattern, and would like to subscribe to your newsletter.
I assume this pattern first involves thinking 'how is first ppost formed?' then going on to create a goatschema for the model, and finally rendering the first post by re-arranging the letters in some amusing way, e.g. fr1st p0st!!1
Re: (Score:3, Interesting)
GUI engines are outgrowing objects in my opinion. Objects are fine when you have hundreds, but not bajillions.
May I ask what you mean by that? I only have GUI programming experience in AWT, Swing, and a little GTK, and from those objects seem very natural for GUI programming. Your description of events sounds pretty much like those frameworks handle events, except you do have to think about how the event loop works due to threading issues, which seems like it could be fixed in the context of OOP.
How would you rather they be handled?
Re: (Score:2)
Re: (Score:2)
Take your nice C program, with it's single global buffer, and try and run two execution threads through it in parallel.
Threading in this system is between OS level processes with their own address spaces. At least that way the middleware is doing some work for you.
Re: (Score:2)
Okay, give each thread a buffer. Not a big deal, although something you do have to remember to do.
It sounds like the problem is not with OOP, but with garbage collected languages with insufficiently intelligent allocators/garbage collectors. The solution seems to be to either use an unsafe language which allows direct control of memory (like C++) or make the allocator smarter, perhaps by including profiling in the optimization process (otherwise the optimizer might not get clued in that it should prepare sp
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"...but not the event engine. In essence, the "controller" needs to be hidden away, controlled by attributes only. Specific event handlers (functions or methods) are "called" by the event engine as needed."
The "event engine" is normally considered to be part of the framework. The bundle of specific event handlers for a given application is the real "controller".
Re: (Score:3, Insightful)
From Head First Design Patterns:
The beginner sees patterns everywhere. This is good. The beginner gets lots of experience with and practice using patterns. The beginner also thinks, "The more patterns I use, the better the design." The beginner will learn that this is not so, that all designs should be as simple as possible. Complexity and patterns should only be used where they are needed for practical extensibility.
As learning progresses, the intermediate mind starts to see where patterns are needed and w
Re: (Score:2)
I was at a rather fine presentation at a Java user conference once. It looked like a demonstration of Eclipse refactoring: everything was refactored into patterns. The guy new all the right key bindings and everything moved blindingly fast. Within half an hour fields were moved/introduced, factory methods and classes created, variables renamed: it was rather fun and impressive to look at.
Then - in the second half - he explained in depth that he just made a complete mess of a perfectly fine and simple *worki
Re: (Score:2)
Worse on the web. (Score:2)
I find this is more of a problem in web development than in classic application development. The problem stems from the fact that anyone can do HTML and many web "developers" have moved from that to languages like PHP that don't teach or enforce good use of OOP, type safety and other important concepts. It's not bad that PHP doesn't do that in itself, because it's still a good language for knowledgable, sensible programmers but that's not a large part of it's userbase unfortunately.
The problem is demonstrat