📄 modelfirst.html
字号:
<head><title>Model First</title></head><body><h1><img src="logo.gif"> Model First</h1>Often a system is about the model, not about the GUI. Take payroll for example, because it happens to be on my mind. The database structure is complex and full of historical information, the payment rules are baroque, the reporting requirements comprehensive. We take in three SQL datasets, a handful of different file formats, and export around 12000 bytes per person. The risk in payroll is not getting people paid correctly.
<p><p><p>Similarly for programs like air traffic control, process control,telephone switching, operating systems. The risk is that the model won't work. In such a system, concentrate your work initially on the model. Have no GUI at all if you can get away with it - otherwise a <a href="SpartanUserInterface.html">SpartanUserInterface</a>. --<a href="RonJeffries.html">RonJeffries</a> See Also <a href="http://c2.com/cgi/wiki?EarlyPrototyping">EarlyPrototyping</a> --<a href="http://c2.com/cgi/wiki?RaySchneider">RaySchneider</a>
<p><hr>
<p>I know that this can be hard for new (and maybe not so new) OOers to accept at first.
<p><p><p>Not too long ago I was working through the VW tutorial with a newbie. It was a pretty simple problem - implement a checking account with all the normal stuff that a checking account has and knows how to do.
<p><p><p>The problem was that the tutorial started with the GUI. The focus was very clearly on the user interface - not on the domain.
<p><p><p>So I skipped all of the sections until I got to the ones involving the domain. Then we (the newbie and I) implemented the domain without any GUIs. We used workspaces, inspectors, and debuggers.
<p><p><p>When we were finished, the system was working. But my partner still had a hard time separating his idea of the system from the user interface.
<p><p><p>For him, the system was the user interface. --<a href="http://c2.com/cgi/wiki?AnnAnderson">AnnAnderson</a>
<p><p><p><hr>
<p><p><p>At KSC I use an analogy when I talk about the order of building things. First of all, imagine that Applications are like hamburgers -- there's a bun and the hamburger. The "bun" is the GUI and database code that supports the "meat" -- which is the domain. When you make a hamburger, first you must prepare the meat, then you place it in the bun. After all, who can argue with McDonald<a href="http://c2.com/cgi/wiki?edit=McDonald">?</a>'s?
<p><p><p><a href="http://c2.com/cgi/wiki?KyleBrown">KyleBrown</a>
<p><p><p>P.S. Seriously, this is something we cover in the very first day of the the <a href="http://c2.com/cgi/wiki?SmalltalkApprenticeProgram">SmalltalkApprenticeProgram</a>. A student has to understand this to "grok" the way in which we teach Smalltalk (domain coding, then gui coding). The pattern <a href="http://c2.com/cgi/wiki?FourLayerArchitecture">FourLayerArchitecture</a> describes some of the logic behind this. A paper I wrote [1] speaks about it more in depth
<p><p><p><p><p><hr>
<p><p>While I agree about the postponement of the full blown GUI, I'd like to point out that a user interface is frequently useful. That is, a user interface written for the developers.
<p>For example: right now, I am working on a set of algorithms for data processing. Basically, they take in lots of time-stamped "truck at location (x,y)" tuples and they try (well, that may be a bit anthropomorphic) to spot patterns in the data.
<p>The first thing I wrote was a a visualization component. Being able to graph data and to have the system throw up some overlays when it thinks it's found something is *invaluable* in telling me when ideas are good or not (and for spotting logical errors in code).
<p><p><p>The visualization component has nothing to do with the eventual applications. It is a piece of GUI code, and throwaway GUI code at that. But it lets me peer down into the model in a coherent way and is an enormously useful tool.
<p><a href="http://c2.com/cgi/wiki?WilliamGrosso">WilliamGrosso</a>
<p><hr>
<p><p><p>I always start to worry when I hear development strategies that place the user interface last (after designing/implementing the guts). You just can't tack on interfaces... On the other hand, for applications that involve mostly background work (where the user is peripheral), it makes since to concentrate on the guts first. There is a balance... we (programmers), historically, tend to focus on the guts side. Nowadays, we are told we need to pay more attention to the user's perspective.
<p><p><p>There is no one hard fast rule. It really depends on the application at hand. Here is a good rule of thumb:
<p><p><p><strong>Any application that involves <a href="http://c2.com/cgi/wiki?DirectManipulation">DirectManipulation</a>, and the end user as a fundamental part of the system's operation (i.e. the user is the controlling entity), should be developed from the <em>user's perspective</em>.</strong>
<p><p><p>As a programmer, I care about the engine behind my spreadsheet or wordprocessor. But, ultimately, as a user I really only care about my interface with the application. (The user also uses the interface to judge whether the software is correct. The criteria is usually usability.)
<p><p><p>If your air traffic control system has the user in an important role (such as determining who should land, and when), then that is the place to start. Of course the guts should work, but the guts are useless if the interface is not correct. If the interface is simple, work it out (let the users play with it) and put it away until later. Now you can work on the guts.
<p><p><p>-- <a href="http://c2.com/cgi/wiki?ToddCoram">ToddCoram</a>
<p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -