Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: Patrick May on 21 Feb 2007 20:40 "frebe" <frebe73(a)gmail.com> writes: >> >> 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. Actually, several people have pointed out the value of separating concerns. The retrieval, transformation, and use of data are conceptually different; combining them in a single lexical unit reduces the understandability of that unit. >> >> 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. > > 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) Even in this simple example, the name of the function is more descriptive than the SQL statement. It can also be re-used without exposing the database schema throughout the application. >> Reliability is increased when code is designed to be easily >> testable, another characteristic of clean code. > > Doesn't the SQL statements need to be tested too? Of course. Isolating it from the application functionality makes it easier to test both in isolation. >> Horizontal and vertical scalability benefits from having clearly >> defined, decoupled components. > > The decoupling you are talkning about is only about creating extra > layer inside an existing process. How can scalability benefit from > this? Not at all. I'm discussing decoupling in the general sense, of which encapsulating SQL is only one, albeit important, aspect. Both horizontal and vertical scalability benefit from the existence of decoupled, well-encapsulated components. >> Security is easier to implement and prove when components have >> single responsibilities. > > Do you have some examples of this? One of the primary difficulties with implementing security correctly is the difficult to understand interactions between complex components. Having a single responsibility for each component simplifies analysis and testing considerably. >> 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. In general, I agree. However, failing to isolate concerns does not result in clean code, either. >> The "bloat" you claim has yet to be demonstrated when comparing >> like with like rather than your naive lines of code metric. > > If the bloat if obvious in a very small example, why wouldn't it be > obvious in a larger application? Small examples tend to focus on the implementation of the technique, resulting in larger perceived overhead. In a larger application, the benefits of certain techniques become more apparent. 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: Patrick May on 21 Feb 2007 20:43 "topmind" <topmind(a)technologist.com> writes: > Thomas Gagne wrote: >> 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 ... >> >> and when another table is created that must know about new >> employees the procedure can be updated without modifying >> application code. Or if employees can be added from multiple >> applications it is better to have isolated the code for adding them >> than to duplicate it. > > In that case I would agree, but because it is an *entire* task in > itself, not just part of a task. But that is not the typical use of > SQL. > > Plus, it is a bit of a suspicious design. In most cases there are CRUD > screens to enter each of those *one* at a time. No, there most certainly are not. This is the case only in simple CRUD applications. Your limited experience is showing again. 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: topmind on 22 Feb 2007 11:22 Patrick May wrote: > "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.... That is not evidence that wrapping and/or OOP is better, that is sophmoric personal puffery on your part. You have been given ample opportunity to show that wrapping and/or OO make your allegedly complex common biz processes better. Instead you just claim it and claim that dissenters are dumb. Show we are dumb, don't just claim it. Web braggers are a dime-a-dozen. The ego-to-evidence ratio is probably around 1,000. > > >> > 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. You need experience presenting inspectable evidence. You get an "F" here. We need yet more closed-door anecdotes like a hole in the head. Turn your alleged experience into a coharent self-standing argument. My experience tells me that heavily wrapping SQL can make code more difficult to change, and I already gave scenarios where this is the case. You have to change two named units instead of one. > Sincerely, > > Patrick > > ------------------------------------------------------------------------ -T-
From: topmind on 22 Feb 2007 11:41 Patrick May wrote: > "frebe" <frebe73(a)gmail.com> writes: > >> >> 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. > > Actually, several people have pointed out the value of separating > concerns. The retrieval, transformation, and use of data are > conceptually different; combining them in a single lexical unit > reduces the understandability of that unit. "Understandability" is different per person. Individual's brains are different due to recombinant DNA. What throws off one person does not throw off another, and visa versa. Your argument is essentially a pyschological one, not really a logical, imperical one. Now, if wrapping works for you, that is fine by me. It is the universal extrapolation that bothers me. The necessary extrapolation to every developer is what you have not demonstrated. > > >> >> 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. > > > > 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) > > Even in this simple example, the name of the function is more > descriptive than the SQL statement. It can also be re-used without > exposing the database schema throughout the application. Personally, I would often prefer an inline comment. Too many nitty gritty methods/functions makes it harder for me to find and read the "real" functions. Too many croutons makes it hard to find the meat. And it creates the need to change two named units instead of one, as already described. That is objectively more work. If you follow hand and eye movements, you will see it takes longer to visit and change both. http://en.wikipedia.org/wiki/Time_and_motion_study > > >> Reliability is increased when code is designed to be easily > >> testable, another characteristic of clean code. > > > > Doesn't the SQL statements need to be tested too? > > Of course. Isolating it from the application functionality makes > it easier to test both in isolation. > You haven't demonstrated a need to test them in isolation. Often testing them together is fine. > >> Horizontal and vertical scalability benefits from having clearly > >> defined, decoupled components. > > > > The decoupling you are talkning about is only about creating extra > > layer inside an existing process. How can scalability benefit from > > this? > > Not at all. I'm discussing decoupling in the general sense, of > which encapsulating SQL is only one, albeit important, aspect. Both > horizontal and vertical scalability benefit from the existence of > decoupled, well-encapsulated components. It *increases* coupling by having a function (wrapped SQL) that is tightly coupled to the calling routine. It is a one-off function. > > >> Security is easier to implement and prove when components have > >> single responsibilities. > > > > Do you have some examples of this? > > One of the primary difficulties with implementing security > correctly is the difficult to understand interactions between complex > components. Having a single responsibility for each component > simplifies analysis and testing considerably. I think he meant code. > > >> 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. > > In general, I agree. However, failing to isolate concerns does > not result in clean code, either. Then how come you don't do this: function addFooAndBar(foo, bar) { return(foo + bar); } .... x = addFooAndBar(foo, bar); .... Instead of x = foo + bar; > > >> The "bloat" you claim has yet to be demonstrated when comparing > >> like with like rather than your naive lines of code metric. > > > > If the bloat if obvious in a very small example, why wouldn't it be > > obvious in a larger application? > > Small examples tend to focus on the implementation of the > technique, resulting in larger perceived overhead. In a larger > application, the benefits of certain techniques become more apparent. More appearent everywhere except here. If you split your code into relatively independent smallish tasks or apps, then there is no "big application". Perhaps you or your paradigm are poor at partitioning. Divide-and-Conquer. I've seen a top 5 company in size do just that using procedural/relational. Maybe you really do need all that buerocracy in your code if you create a giant ball of classes and the Mother of All EXE's. > > Sincerely, > > Patrick > -T-
From: topmind on 22 Feb 2007 11:53
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Thomas Gagne wrote: > >> 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 ... > >> > >> and when another table is created that must know about new > >> employees the procedure can be updated without modifying > >> application code. Or if employees can be added from multiple > >> applications it is better to have isolated the code for adding them > >> than to duplicate it. > > > > In that case I would agree, but because it is an *entire* task in > > itself, not just part of a task. But that is not the typical use of > > SQL. > > > > Plus, it is a bit of a suspicious design. In most cases there are CRUD > > screens to enter each of those *one* at a time. > > No, there most certainly are not. This is the case only in > simple CRUD applications. Your limited experience is showing again. Why don't you show me wrong by presenting a real-world examples, instead of self-puffery? I'd bet money that most companies don't enter employees and medical benefits and 401k investment portfolios all in a single *monolithic transaction*. A minor problem could prevent the *entire* thing from being accepted, causing wasted data entry time and effort, making the company less profitable. Perhaps you are the ahole that designs those web pages that make you enter a bunch of stuff, only to have it all rejected and lost because of some nitty problem such that one has to retype it all. And, the longer it is stored if its rejected, the more stailer the info becomes. Lookups of medical plan account codes, 401k investment options or rates, etc. can become outdated if the whole big monolithic transaction sits waiting for one small thing to be fixed. Divide-and- Conquer works with transactions also. Systems are more interactive if stuff is submitted peicmeal such that small problems are identified early such that they don't become big problems. > > Sincerely, > > Patrick > > ------------------------------------------------------------------------ -T- |