Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: frebe73 on 27 Jan 2007 12:05 > When SQL is mixed with non-relational code, > anyone reading the code has to change context repeatedly from database > access to translation to application logic. This is less readable. Can you please give some example? Are you talkning about the fact that some environments force you to write SQL statements as strings? Or the fact that interfaces like JDBC is too low-level? > > I don't understand why OO people insits testing their application > > without the database. > 1. It's faster, which means more tests get run, which means higher > quality. Are really test performance a factor that should have impact on how to design software? > 2. The database schema and the application logic change for different > reasons. Decoupling the two minimizes the impact of those > changes. Do you have some examples of such change (that could not be solved using views)? > 3. The database isn't always available to application developers, > particularly when working remotely or off the network. (While it > is possible to install a subset of the database on a laptop, it's > much easier to simply mock it out.) If the database isn't availible for developers, I suggest solving that problem instead of changing the way you design software. Installing a full database on a laptop has not been a problem for the last 10 years. Eclipse uses more memory and CPU on my laptop than my SQL Server, Oracle, Postgres and MySQL instances together. > Do you consider telco OSS/BSS systems to be business > applications? Trading systems? Order management systems? I've > worked on all of these relatively recently, they all make use of an > RDBMS, but by no means are they a thin layer babysitting it. I consider them business applications. Done the right way the major part of the business logic is implemented using constraints, views and triggers. The main responsibilities for the application are presentation and communication. Done the wrong way, the application is a big ball of mud trying to reinvent a database. Without data-aware GUI widgets, the presentation layer also tend to be a big ball of mud. > >> 3. Either side can be deployed independently of the other (meaning > >> at differen times) allowing me to fix bugs, or add features, to one > >> side without redeploying the other. etc. > > > Views (and stored procedures) are deployeable indepentently of the > > application. But I not sure I understand why deploying different > > parts of the application indepently is so very important. > It is absolutely essential in large, or even medium-sized > systems, both in development and deployment. Maintainability and > extensibility are core non-functional requirements. The financial > impact and risk to the business of "Shut down everything and > reinstall." is not a viable mechanism for meeting those NFRs. But horizontal layers doesn't help. If you shut down the database or presentation layer, you don't have very much application to run anyway. Fredrik Bertilsson http://mybase.sf.net
From: Dmitry A. Kazakov on 27 Jan 2007 16:20 On 27 Jan 2007 08:55:12 -0800, Daniel Parker wrote: > On Jan 27, 4:05 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >> Relation is an operation over objects in a model which would implement RA. > > I don't know what that means. In RA, a relation is defined as a set, > whose members are tuples. It meant the characteristic function of, which is a Boolean-valued operation. > Operations (restriction, join, projection > etc.) can be applied to relations, which produce other relations. Which is an even better example than mine, that relations can be values (and thus objects). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 27 Jan 2007 16:22 AndyW wrote: > On 25 Jan 2007 20:42:58 -0800, "topmind" <topmind(a)technologist.com> > wrote: > > > > >Robert Martin wrote: > >> On 2007-01-23 18:11:25 -0600, "topmind" <topmind(a)technologist.com> said: > >> > >> >> We can argue about whether the net work is greater or > >> >> less. From my point of view it is significantly less since I can > >> >> forget about the SQL and Schema while dealing with the business rules > >> >> and interface. > >> > > >> > SQL = biz logic. > >> > >> Here's a simple business problem for you to code in SQL: > >> http://bossavit.com/cgi-bin/dojo.pl?HarryPotterKata > > > >It looks like one of those programming contest puzzles, kind of like > >Towers of Hanoi. I'll perhaps consider it, but after we finish with > >payroll stuff. > > > >> > >> > ...repetition of claim does not make it true... > >> > >> I'm glad you finally agree. > >> > >> > Those who know how to use SQL and RDBMS effective can > >> > shorten and simplify code because OO is crappy and inconsistent at > >> > collection handling and meta-tizing attribute management. > >> > >> Those who know software engineering know how to use SQL and RDBMS and > >> OO together to create the best systems. > > > >Those who know software engineering either admit something is a > >subjective personal preference when it is, OR offer CLEAR evidence of > >why OO makes it better and don't just use the single change scenario > >favored by OO. > > There are two examples I like to use, one applies to SQL/Procedural > and the other applies more to OODB/OO. > > The scenario works best if one imagines one is developing a solution > for a medium sized mobile telco with a subscriber base of about 80 > million connections. > > I would suggest the FindCustomer architecture pattern is ideal for the > SQL environment because it is in effect a batch operation (as compared > to the next example) of structured data. > > The second is that of a real time rating and billing solution for > mobile calls (from CDR generation to the application of plans, > subscriptions, specials etc) and I think this example is more suitable > to an Object Oriented environment (including DB) because apart from > being in real time, works mainly with a non-structured data > environment. Why do you consider it "unstructured"? What is an example scenario you have in mind? > > Andy -T-
From: topmind on 27 Jan 2007 16:24 AndyW wrote: > > > >And, your rudeness made me sorry I bought your damned book and put > >money into your patronizing little pocket. > > > >OO needs good teachers, not mean preachers. > > > >-T- > > > >> > >> -- > >> Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com > > > Now now ladies - no need for the handbag fight. Kiss my gurdle!
From: topmind on 27 Jan 2007 16:36
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Robert Martin wrote: > >> Tsk tsk. More disparagement, and even a bit of elitism! ("You > >> OO'ers." As if there were some kind of unholy alliance or shadowy > >> cabal!) > > > > What term would you prefer? > > I suggest "developers who understand and have experience with > multiple paradigms and who therefore can make the appropriate > engineering trade-offs to achieve their customers' goals and provide > the maximum business value given the specific problem domain and > context." You could shorten that to "well-rounded programmers" if you > like. Everybody claims they are, but few prove it by showing clearly how they are comparing stuff. Professor Weinrich (sp?) was just about the only debator I know who was fairly good at explaining their betterment beliefs in a semi-scientific way. > > I don't know anyone who understands object-orientation who also > insists that it is the one true and only approach to use in all > situations. That "one trick pony" attitude seems to be prevalent only > among those who know only one trick. The mix preferences are all over the map. Some seem to really like it. It may indeed be a personal preference and OO fits their brain better than other paradigms. I won't dispute that. I only dispute the claims or implications that OO is objectively better. The more I look at it all, the more I am convince that a lot of it is about psychology. Experience in both programming and the domain helps, but people tend to lean toward certain techiques. For example, I used to line up parameters of calls to the same functions into columns before I ever got a chance to use table-centric technologies. Tables are in my blood. > > >> We OO'ers live in a world where we need to deploy systems in pieces > >> and on different schedules. > > > > That is why us p/r-ers split things up into "task" modules where > > each task is mostly connected only via the tables. > > This approach is not unique to nor was it invented by procedural > or relational programmers. It is a standard design technique used in > a variety of paradigms. See message-oriented middleware, SOA (Jini in > particular), and even CORBA for examples. It is not a matter of invention credit, but general design philosophy. Procedural uses task as its primary code divider. OO uses a potpurri of divisions, and this is partly why I find it so messy. It lacks consistent design rules and organizational discipline. It is a big soup of classes. It needs a concept bigger in scale than classes to organize it, but there is no such convention that works so far. > > Sincerely, > > Patrick > -T- |