Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: Thomas Gagne on 19 Feb 2007 21:13 topmind wrote: > > I bet I could find counter scenarios for any scenario you present. > Any fool can do that. > Changes come from all directions, not just from pro-OO books. > There is nothing OO-specific about designing for change. I've used this same approach for systems written entirely in C. This is not about approaching things in an OO-way. It's not about inheritence, polymorphism, dynamic typing, class hierarchies or messages. It's about simple structured programming techniques that seem to escape people when relational databases and SQL are involved. -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: topmind on 19 Feb 2007 21:45 Thomas Gagne wrote: > topmind wrote: > > > > I bet I could find counter scenarios for any scenario you present. > > > Any fool can do that. > > Changes come from all directions, not just from pro-OO books. > > > There is nothing OO-specific about designing for change. I've used this > same approach for systems written entirely in C. This is not about > approaching things in an OO-way. It's not about inheritence, > polymorphism, dynamic typing, class hierarchies or messages. It's about > simple structured programming techniques that seem to escape people when > relational databases and SQL are involved. Yeah, we are all hung up in this evidence stuff. Cursed our damned science and logic education. (Cue Supertramp "Logical" song....) > > -- > Visit <http://blogs.instreamfinancial.com/anything.php> > to read my rants on technology and the finance industry. -T-
From: frebe on 20 Feb 2007 01:37 > >> Decoupling SQL statements may or may not increase the total > >> number of lines of code, depending on the size of the SQL statements > >> and the number of times they are reused. > > > Forcing all SQL statements into functions instead of only putting them > > into functions when suitable, will always increase LOC. > > >>>> As discussed elsewhere in the thread, even the hard of learning > >>>> Mr. Jacobs admits that lines of code is not a sufficient measure. > > >>> More lines of code takes longer time to write. More lines of code > >>> makes the code harder to read. > > >> This is not always, or even often, the case. Highly coupled big > >> balls of mud that mix different concerns are more difficult to > >> understand than well-factored, clean code. > > > But nobody have proved why separating all SQL statements would create > > cleaner or more well-factored code. > > You keep asking for proof without specifying the burden of proof. What > burden of proof would require for structured programming to prove it is > better to call functions than not to (as used to be the case) Regardless if your code contains SQL statements or not: Functions should be used to avoid having repeated fragments of code that are more complex than the function call itself. If the function is only called once or is as simple as the call to it, a function has no purpose. Function may also be used to enable recursion. > or that it > is better to let a filesystem handle file-io than an application to > manipulate disk structures directly (as also used to be the case)? A relational database already offer separation between logical and physical data structures. SQL already offer independence between database vendors. > >> Maintainability and extensibility are two NFRs that come > >> immediately to mind. Clean code is easier to maintain and extend. > > > In what what way is > > > createEmployee(x,y,z) > > > function createEmployee(x,y,z) { > > insert into employee values (x,y,z) > > } > > > cleaner than > > > insert into employee values (x,y,z) > > It is cleaner when createEmployee(x,y,z) is more realistically imagined: > > insert into employee... > insert into address ... > insert into employeeAddress ... > insert into employeeEmployee ... > insert into calendarResource ... > insert into payroll ... > insert into planParticipant ... > insert into benefitParticipant ... > insert into dependents ... How would the argument list to createEmployee look like? createEmployee(x1, x2, ....., x200) If you show the complete implementation of createEmployee, I can promise you that it is everything but clean. > and when another table is created that must know about new employees the > procedure can be updated without modifying application code. Sorry, I don't follow you here. > Or if > employees can be added from multiple applications it is better to have > isolated the code for adding them than to duplicate it. If the same fragment of code should be called from multiple points, a function is suitable. > >> Are you arguing that clean, well-designed code does not have > >> quality benefits? > > > No, but creating new functions with only one statement or functions > > that are only called only once, doesn't create cleaner or more well- > > designed code. > > Practically speaking that is rarely the case. My experience is exactly the opposite. Using view would also make the scenario more common. > And even if it occurred > more often than rarely, it is a better design that allows one > module/function/method to change independently of others that rely on it. If a SQL statement is simple, there are not many possibities to change it, without changing the semantics. /Fredrik
From: Jerry Coffin on 20 Feb 2007 23:10 In article <1171953479.656218.117930(a)v45g2000cwv.googlegroups.com>, frebe73(a)gmail.com says... [ ... ] > A relational database already offer separation between logical and > physical data structures. Given the number of truly relational databases around, the separtion is more between physical (but not really relational) and relational (but imaginary). > SQL already offer independence between database vendors. ....some independence for some operations. Virtually no large database application written for one SQL-based database will work directly on another without fairly serious work porting. Even small applications usually need at least a little work. If you're willing to restrict yourself sufficiently (e.g. to ODBC) you can get portability, but that places fairly substantial restrictions on the range of applications you can support. > > And even if it occurred > > more often than rarely, it is a better design that allows one > > module/function/method to change independently of others that rely on it. > > If a SQL statement is simple, there are not many possibities to change > it, without changing the semantics. This is only even arguably true for a very small number of possible statements. Just for an obvious example, if you restructure your database, you'll usually need to change the statements to maintain the same semantics (e.g. if you decide to split some data from one table into two). Yes, that particular change can (sometimes) be covered by creating a view that looks like the old table. That still only covers a small subset of possible changes. -- Later, Jerry. The universe is a figment of its own imagination.
From: Patrick May on 21 Feb 2007 20:14
"topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: >> >> The techniques used to decouple components and avoid big balls >> >> of mud offer significant benefits, particularly in addressing >> >> non-functional requirements. >> > >> > Can you prove this claim? >> >> Maintainability and extensibility are two NFRs that come >> immediately to mind. Clean code is easier to maintain and extend. >> Reliability is increased when code is designed to be easily >> testable, another characteristic of clean code. Horizontal and >> vertical scalability benefits from having clearly defined, >> decoupled components. Security is easier to implement and prove >> when components have single responsibilities. >> >> Are you arguing that clean, well-designed code does not have >> quality benefits? > > You go into brochure-mode here and redefine wrapping as "being > clean" in a Carl Rovian way. Perhaps you should be in marketing, not > software development. Referring to the importance of non-functional requirements is "brochure-mode"? Only someone whose experience is limited to simple CRUD systems would make a statement like that. Oh, wait.... >> > The benefits of decoupling SQL has to be considered unknown until >> > someone can prove them. But the disadvantages (more bloated code) >> > are easy to prove and has to be accepted as facts. >> >> The benefits are readily apparent to anyone who has developed >> any large, or even mid-sized, enterprise system. > > This is an argument-via-authority fallacy, not evidence. No, it's a recognition that a certain level of experience is required to understand the value of some techniques. Anyone interested in educating themselves can gain that experience. 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) |