Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Robert Martin on 30 Jan 2007 00:14 On 2007-01-27 23:56:27 -0600, frebe73(a)gmail.com said: > As much business logic as possible should be implemented in SQL. But > due to the limitations in the SQL language, it is not possible to > implement all business logic in SQL. The rest you have to implement in > the application. Now that we all agree that SQL is good for some things, and OO is good for others, all we have left to argue about is degree. -- 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 30 Jan 2007 00:16 On 2007-01-28 08:04:24 -0600, frebe73(a)gmail.com said: > I entered this thread because Robert Martin was giving harmful advices > about how to use a SQL database. Why are you guys givining advices on > SQL development at comp.object, anyway? Why don't you just stick to > OODBMS? Actually, we are giving advice about how to build OO applications that need to use an SQL database. -- 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 30 Jan 2007 00:21 On 2007-01-28 11:41:50 -0600, frebe73(a)gmail.com said: > The most common data structures used in current programming languages > are lists and maps Not so fast there partner. The most common data structure used in current programming language is: object. An object is a tuple, very similar to a table row. Objects can be connected into graphs through the use of pointers. Now I know you think this is a network database and you get all hot and bothered about that since the relational gods proved that network databases were demon spawn. But these aren't network databases. These are just transient networks of objects that are used to facilitate calculations and decision making. It is these graphs of objects that are the most common data structures in object oriented programs. -- 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: frebe73 on 30 Jan 2007 00:23 > > The most common data structures used in current programming > > languages are lists and maps, so I think we can limit ourself to > > these structures. > I think we can use that statement as evidence that you don't know > what you're talking about. Lists and maps may be the most commonly > used, but they by no means define the full set of data structures used > in production software. Did I claim that? You may pick any data structure and show the benefits compared to relational algebra. I just picked the two most common. > I've been in the industry for close to twenty years and started > out working on a CASE tool that supported all the common relational > modeling techniques at the time. Nice try with the condescension, > though. It's easier than actually defending your ridiculously broad > claims, isn't it? What is your point? CASE tools are flawed? The relational model is flawed? > > Because lists and map are more low-level they do also have > > performance benefits. In some scenarios (but not often in business > > applications), performance might force you to use them. Because most > > of the current mechanisms providing some sort of relational algrebra > > are running in a separate process from the rest of the application, > > there might be perfomance problems when making heavy use of > > relational algebra. The best solution for this problem is to use > > stored procedures to avoid the inter-process communication. Using > > low-level data structures on the application side is a bad idea for > > solving this problem. > More pronouncements from on high. You admit that there are > performance benefits to non-relational data structures, Yes. > but assert without basis that they should nonetheless never be used. No, read above. > (Hint: inter-process communication is not the only source of performance > problems.) But a very common one. Often people compare performance with RAM structures with databases that resides on a different machine connected by a slow network. > > It was possible to make working applications in the pre-relational > > era too. > We're doing it in the post-relational era, too. What data structures do you think will replace relations? Fredrik Bertilsson http://mybase.sf.net
From: Robert Martin on 30 Jan 2007 00:25
On 2007-01-28 11:41:50 -0600, frebe73(a)gmail.com said: > OO people claim that OO can be used for everything. So why don't you > use a OODBMS? What are the benefits with SQL databases that makes you > to use them instead? I think that time has shown that OODBMS has been a dead end. The arguments you relational guys have been making about RA have proven correct, and the industry has almost completely sided with you. Oh I know a few OODBMS hold-outs; but not many. The technology may make a comeback one day when RAM storage becomes cheaper than disk. We'll see. Most people who use relational databases use them as the back end to an OO middle and front end. Business rules (other than searching and corelating) are done in the middle layers by OO programs. Presentation is done by OO programs at the front end. Transport between system is done by OO programs in the middleware and front end. etc. -- 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� � � � � � � � ��| |