Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Dmitry A. Kazakov on 28 Jan 2007 04:45 On 27 Jan 2007 19:20:41 -0800, Daniel Parker wrote: > On Jan 27, 4:20 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> On 27 Jan 2007 08:55:12 -0800, Daniel Parker wrote: >> >>> 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). >> > A relation is a value. > > But are you saying that an object _is_ a value? Of course I don't. I meant that if something could be a value, then we could make objects on that basis. > If a mutable object > is mutated, is it the same value? In the first approximation it is not, but it depends on the type of. See below. > Rather, it seems to make more sense > to say that an object _has_ a value, and that if it is mutated, it has > a different value. Yes. But, there can be different views of what is the value. We cannot talk about values indiscriminately (without types). When object is as usual identity + state and its state is the value, that is one view. But there could be other views. You can consider object with all its possible states and behavior as a single value (of a different type). As examples we could take pointers passed around, random generators, clocks, files. Everything depends on types and identities. P.S. I have, maybe a more extreme, opinion on that than politically correct Robert: RA is about specialized containers and thus deserves no any special treatment. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Patrick May on 28 Jan 2007 08:30 frebe73(a)gmail.com writes: >> I'm referring to the benefits of separating concerns. When SQL is >> embedded in other languages, OO or procedural, the code is >> responsible for at least three tasks: retrieving the data from one >> or more tables, transforming the data into a format suitable for >> the the application logic (variables, structures, objects, result >> sets, etc.), > > Relational algebra should be used for transforming data. Relations > is the only data structures that should be used. I think we can end this discussion right here. If you are seriously (and without providing any supporting argument, I note) asserting that database relations are the only data structure that should ever be used, our views on software development are too different to support constructive interaction. What are you doing on comp.object, anyway? Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: frebe73 on 28 Jan 2007 08:44 > >>> It is easy to imagine other examples of > >>> very specific ways of finding employees. Lets say we want to send every > >>> manager an email containing the employees having 30-, 40-, 50-year > >>> birthday next month. > > >> Sounds like a straight-forward SELECT statement, when crafted by a > >> knowledgeable programmer it won't result in Cartesian products or take > >> the database down to its knees. > > > Yes, but almost everything is a straight-foward select statement > > (assuming you have some knowledge in the area). Why would a Cartesian > > prodct take a database down to its knees? > Cartesian products that mistakingly return 100x the number of rows they > should often have a negative impact on the performance of a database > server. Good pages are pushed out of the cache for bad pages. Disks > waste IO on useless reads and ignore the requests of more profitable > queries. In other words, during the time we spend wrenching the > database for missing join clauses it is basically, on its knees. Cartesian products are a very important operator in relational algebra. But it is only a logical construct. If you have indexed your database correctly, the query engine doesn't have to work the way you describe above. > > <snip> > >> Why ignore the database and the simplicity of SQL? > > > I don't. Classes should not be used as data structures, relations are > > a much better choice. But classes can successfully be used for > > defining datatypes. After all, a relation is defined as a set of > > tuples of objects. > I guess the question is what kinds of datatypes are you referring to. > Dates, currency, strings, or more complicated objects (like anEmployee). First, objects should be immutable. Second, they should not be used as data structures. These rules would probably disqualify employees from being objects. What would an employee be for you? An employee no together with a name and address data? Is payment history part of the employee object? > >>>> All our reports have been implemented as > >>>> stored procedures and have been meticulously crafted to perform well and > >>>> balance to other reports. There are many similarly-named reports but > >>>> the user doesn't really see that because they navigate through the data > >>>> starting at the top-level and drilling-down. > > >>> Are there any significant difference between producing data on a paper, > >>> displaying it on a computer screen or using it in a thread sending > >>> e-mails? > > >> Not that I'm aware of. That's a presentation problem, isn't it? > > > So why do you use a significant different approach implementing > > reporting? > > I'm unsure what you mean. You entered this thread by questioning the need for finding employee data in many different ways, with the exception of report writing. My question is way do you make an exception for printing data on a paper? If a statement is valid, it would be valid regardless the data is shown on screen or printed on paper, unless there are a significant difference between these two ways of presenting data. > Do you mean using procedures vs. SQL? Since > procedures are mostly SQL there isn't that much difference. The biggest > one for reports is the simple parameterization a procedure allows. If > the request is to find employee's 50 years old, we'd parameterize the > 50 since it proved to be the most arbitrary parameter. Why not 51? 49? Are your claim that only by using procedures the age might be parameterized? Prepared statements maybe? Where do you think the number 50 come from in the first place? The database maybe? Why not joining the configuration table containing the age limit and use it in the where clause? It is no point in first reading the age limit and then pass it as parameter back to the database. Fredrik Bertilsson http://mybase.sf.net
From: frebe73 on 28 Jan 2007 09:04 > I think we can end this discussion right here. I see that you are out of arguments here... > If you are > seriously (and without providing any supporting argument, I note) > asserting that database relations are the only data structure that > should ever be used, our views on software development are too > different to support constructive interaction. Why don't you show the limitations with relations as data structures? There is nothing in the pre-relational data models (hierachial and network) that can't be easily solved in the relational model. > What are you doing on comp.object, anyway? 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? Fredrik Bertilsson http://mybase.sf.net
From: Patrick May on 28 Jan 2007 10:39
frebe73(a)gmail.com writes: >> I think we can end this discussion right here. > > I see that you are out of arguments here... Not at all. However, anyone who claims that relations are not only the only data structure necessary, but the only one that _should_ be used does not share enough common ground with me for further discussion to be fruitful. If I want to spend days beating my head against a wall, I can always jump into one of Bryce's threads. >> If you are seriously (and without providing any supporting >> argument, I note) asserting that database relations are the only >> data structure that should ever be used, our views on software >> development are too different to support constructive interaction. > > Why don't you show the limitations with relations as data > structures? Why don't you defend your claim that relations are the only data structure that should ever be used? Your claim is equivalent to asserting that all of the experienced software developers using other data structures to deliver real business value every day are ignorant or foolish. Do you really think that only you have seen the light? Isn't it just possible that other data structures exist for very good reasons? >> What are you doing on comp.object, anyway? > > I entered this thread because Robert Martin was giving harmful > advices about how to use a SQL database. Actually, he was giving the benefit of his experience in combining OO and relational models to deliver quality software. > Why are you guys givining advices on SQL development at comp.object, > anyway? Why don't you just stick to OODBMS? The only people here who limit themselves to a single approach are the relational one trick ponies. The rest of us want as many tools in our toolbox as possible. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) |