Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: JXStern on 14 Jan 2007 15:53 On 14 Jan 2007 11:49:42 -0800, "topmind" <topmind(a)technologist.com> wrote: >> It's an issue of what is done with the tools. The tools are fine. >> OK, static HTML with common controls limits what you can do, but >> here's a very BASIC thing that bugs me: everyone uses pull-downs, both >> for huge lists and for small lists, when it would often improve a GUI >> dramatically to use listboxes (scrolling list showing many at a time) >> instead. > >Sound like that is a case where one would want to use a two-column >table grid with the first column being a check-box and the second a >description. However, if there are thousands, then going to a "pop-up" >modal selection screen where one uses QBE etc. to pick them and then it >puts the picks back at the original screen. But this is tricky and >time-consuming to pull off with web browsers. Sure, fancy grids are a great way to go, but aren't supported in standard form across current browsers (hint, hint). And pop-ups to present a modal choice from complex data are a basic mechanism for rich-clients, don't believe they're enforceable with standard browser features, at some cost you can morph the current window into a modal choice one, but yeah it's work. But anyway it's so frequent to see the basic mistake made, the current timekeeping system I'm using is a prime example. Getting back to the main topic, it's just the case that a well-educated developer doesn't see it as encapsulating function in a component, so much as utilizing the available components. J.
From: topmind on 14 Jan 2007 17:48 JXStern wrote: > On 14 Jan 2007 11:49:42 -0800, "topmind" <topmind(a)technologist.com> > wrote: > > >> It's an issue of what is done with the tools. The tools are fine. > >> OK, static HTML with common controls limits what you can do, but > >> here's a very BASIC thing that bugs me: everyone uses pull-downs, both > >> for huge lists and for small lists, when it would often improve a GUI > >> dramatically to use listboxes (scrolling list showing many at a time) > >> instead. > > > >Sound like that is a case where one would want to use a two-column > >table grid with the first column being a check-box and the second a > >description. However, if there are thousands, then going to a "pop-up" > >modal selection screen where one uses QBE etc. to pick them and then it > >puts the picks back at the original screen. But this is tricky and > >time-consuming to pull off with web browsers. > > Sure, fancy grids are a great way to go, but aren't supported in > standard form across current browsers (hint, hint). And pop-ups to > present a modal choice from complex data are a basic mechanism for > rich-clients, don't believe they're enforceable with standard browser > features, at some cost you can morph the current window into a modal > choice one, but yeah it's work. > > But anyway it's so frequent to see the basic mistake made, the current > timekeeping system I'm using is a prime example. > > Getting back to the main topic, it's just the case that a > well-educated developer doesn't see it as encapsulating function in a > component, so much as utilizing the available components. This may be related: http://www.c2.com/cgi/wiki?HelpersInsteadOfWrappers As far as "list boxes", do you mean the kind that you have to press something like Ctrl-Shift to select an item? Those are goofy keystrokes. The browser makers should have used checkboxes next to the descriptions (IOW, tables :-) > > J. -T-
From: Robert Martin on 21 Jan 2007 09:53 On 2007-01-02 08:48:59 -0600, Thomas Gagne <tgagne(a)wide-open-west.com> said: > I suspect he and Martin Fowler (it is reported) both share the opinion > that if memory was both infinite and infallible that databases would be > unnecessary. Well, perhaps they would be if you never needed to share, > duplicate, or transport them. Database engines are powerful tools that are very useful for many different kinds of applications. In some cases whole applications can (and should) be written using nothing but the tool. I am in the mist of writing a two simple applications for small businesses at the moment. Both use a database back end. Both are web driven. Both have interesting business rules. One is written in Java, the other in Rails. My philosophy of programming guides me to ignore the database in the early portions of these designs. I was quite able to do that in the Java application, with very good results. But Rails is more tightly coupled to the database; and my inexperience with the framework caused me to aquiesce to this coupling. In short, I allowed the business rules and the database to become coupled. The Java applications worked out quite nicely. The business rule layer is indendent of the database layer and the GUI layer. They all work nicely together and the implementation was simple and fast. The Rails application has led to complications. There are forms I want to display that don't seem to corespond to any particlar database table, and yet the framework is tuned to the idea of one-form-one-table. I fell into this trap, and now I have to dig my way out. BTW, this is not a blast on Rails. I think if I had had a bit more experience with Rails I would have sidestepped this trap pretty easily, and simply separated the business rules from the database. To sum up. Though I agree that database engineers are powerful and necessary tools, and though I understand that they are often critical to the success of many project, from a design perspective they are details that need to be decoupled from the business and presentation rules of most applications. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: Robert Martin on 21 Jan 2007 10:28 On 2007-01-13 17:00:24 -0600, JXStern <JXSternChangeX2R(a)gte.net> said: > Page 351, second paragraph: "Instead of starting with the data of the > system, let's start by considering the behavior of the system. After > all, it is the system's behavior that we are being paid to create." > > Says who? Says me! ;-) The problem being discussed is Payroll. If we are writing a payroll application we are being paid to create payroll behaviors. I am quite happy to agree that there are applications that are more about data storage and provisioning, than any actual processing. But that was not the case under study. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: Robert Martin on 21 Jan 2007 10:30
On 2007-01-13 21:08:35 -0600, "topmind" <topmind(a)technologist.com> said: > RCM definitely appears to not be a RDBMS fan and is happier the more he > wraps it away. It has nothing to do with fan-dom. I consider RDBMSs to be valuable and important components of many systems. Like any component, it should be isolated from the others. This is just good software practice. (see Information Hiding). -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��| |