Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
in [OOP]
|
From: Patrick May on 27 Jan 2007 21:39 frebe73(a)gmail.com writes: >> 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'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.), and executing the application logic. Separating these concerns is good engineering practice because it makes the implementation of each responsibility simpler, easier to test, and easier to understand. >> > 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? Software should be designed to be testable. Software should be tested as thoroughly as possible to ensure quality. Running tests frequently identifies problems early and improves quality. All other things being equal, a design that supports frequent testing will result in better quality than one that does not. >> 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)? The simplest example is during the early stages of development. Neither the database schema nor the application architecture are stable. Application developers are designing and implementing their logic, database developers (who may be the same individuals filling a different role) are focused on normalizing data and ensuring adequate performance. The two sets of components are changing for different reasons. More generally, databases typically support multiple applications and systems. Changes to the database required by one application are often not required by other applications. The two should be insulated from each other. Even within a single application/database relationship, the schema can change independently of the application logic. Denormalization for performance is the canonical example of this. Views are one way of providing this insulation, but there is no particular reason to prefer them to the exclusion of all other alternatives. You can consider O-R mapping logic to be an application view instead of a SQL view. >> 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. You're assuming that it is a problem. Even when the application developers do have access to the database, the ability to mock it out provides value in development and testing. This ability provides the additional bonus of not having to install, maintain, and run an RDBMS on every development machine. > Installing a full database on a laptop has not been a problem for > the last 10 years. Oracle still has a pretty hefty footprint in terms of disk space and memory, and it will run slower than a mocked interface. It is certainly convenient to have it available, but when the design supports clear separation of concerns the developer can choose to test without it while developing new functionality. This decreases the testing overhead which encourages tests to be run more often. It also helps to ensure that the interfaces between various components are testable, which leads to better quality. >> 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. That's a broad claim. Are you asserting that all business logic should be implemented in SQL? That this is even possible? If this is how you prefer to work, what are you doing in comp.object? > The main responsibilities for the application are presentation and > communication. Actually, in an OSS the main responsibility is to ensure provision of telephone services to subscribers. The business rules and technical environment are complex. These are not CRUD systems. > Done the wrong way, the application is a big ball of mud trying to > reinvent a database. Another broad claim. Mixing business logic with storage information (i.e. database schemas) and transformation code is more deserving of the BBOM appellation. >> >> 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. Not true. These kinds of systems have to be designed to be resilient even when one or more components are unavailable. There can be no single points of failure, including databases. An example of this occurred at an MVNO a few months ago. Their MRP/ERP system went down, database and all, for more than fifteen hours. Their OMS continued accepting orders from the website, retailers, and in-house sales system during the outage. All other steps in the workflow remained functional. When the MRP/ERP system came back online, all of the pending orders were processed. We were able to achieve this level of resiliency by separating concerns and eliminating single points of failure in the system. 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: Daniel Parker on 27 Jan 2007 22:20 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? If a mutable object is mutated, is it the same value? 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. In which case your statement above does not follow. Daniel
From: frebe73 on 28 Jan 2007 00:56 > >> 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'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. > and executing the application logic. Separating these concerns is > good engineering practice because it makes the implementation of each > responsibility simpler, easier to test, and easier to understand. You still didn't provide any examples. > >> 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)? > The simplest example is during the early stages of development. > Neither the database schema nor the application architecture are > stable. Application developers are designing and implementing their > logic, database developers (who may be the same individuals filling a > different role) are focused on normalizing data and ensuring adequate > performance. The two sets of components are changing for different > reasons. Some example please... > More generally, databases typically support multiple applications > and systems. Changes to the database required by one application are > often not required by other applications. The two should be insulated > from each other. Some example please... > Even within a single application/database relationship, the > schema can change independently of the application logic. > Denormalization for performance is the canonical example of this. Some example please... > >> 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. > You're assuming that it is a problem. No, you pointed it out as a problem. > Even when the application > developers do have access to the database, the ability to mock it out > provides value in development and testing. Mocking out a database ain't trivial. Maybe it is of you only use the database for persistence, but otherwise... > This ability provides the > additional bonus of not having to install, maintain, and run an RDBMS > on every development machine. Installning, maintaining an running a RDBMS on every development machine is not a problem. > >> 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. > That's a broad claim. Are you asserting that all business logic > should be implemented in SQL? That this is even possible? If this is > how you prefer to work, what are you doing in comp.object? 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. > > The main responsibilities for the application are presentation and > > communication. > Actually, in an OSS the main responsibility is to ensure > provision of telephone services to subscribers. The business rules > and technical environment are complex. Relational algebra may perform complex tasks. > > Done the wrong way, the application is a big ball of mud trying to > > reinvent a database. > Another broad claim. Mixing business logic with storage > information (i.e. database schemas) and transformation code is more > deserving of the BBOM appellation. If set operation and predicate logic was about storage, your statement would be true. But it isn't. > >> 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. > > Not true. These kinds of systems have to be designed to be > resilient even when one or more components are unavailable. There can > be no single points of failure, including databases. An example of > this occurred at an MVNO a few months ago. Their MRP/ERP system went > down, database and all, for more than fifteen hours. Their OMS > continued accepting orders from the website, retailers, and in-house > sales system during the outage. All other steps in the workflow > remained functional. When the MRP/ERP system came back online, all of > the pending orders were processed. Now you are changing the subject. Vertical partitioning of applications are a very good thing in many aspects. If you have multiple subsystem only communicating with each other using asynchronous messages, one system can continue to perform its task while another system is down. But if you only have one system and you separate "business logic" and "persistence logic" in to horizontal layers, how can the "business logic" continue to work if the "persistence logic" doesn't? Fredrik Bertilsson http://mybase.sf.net
From: frebe73 on 28 Jan 2007 01:09 > >> Can you give an example of an application that would have an excessive > >> number of getemployeBySomeCriteria() methods that doesn't encroach on > >> becoming a report writer? > > > A HR application need data about employees in many different ways. RCM > > already gave you one example of a very specific criteria for finding > > employees. When a company needs to reduce the staff, it would be nice > > if the HR application had a feature to find employees eligible for > > early retirement, wouldn't it? > If there wasn't a requirement for the previous 30 years to find > employees eligible for early retirement why should we assume that > requirement should have been anticipated? Do one-off questions deserve > one-off solutions? You have to remember this is an example given by RCM. My examples are not once-in-a-lifetime scenarios. > > 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? > > Lets say we have a function sending information to > > insurance company about changes in salaries, we need a way to find > > employees with changed salary. How could you possible solve this only a > > few functions for finding employees? > Why do we assume the only way to find things is through a OO function? I wouldn't use OO functions (methods?) to perform such tasks at all. > 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. > >> 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 have seen systems like you describe above. The only way to > > access a lot of the information was to print it, or get it as a large > > PDF-file. It so 60's. > I don't think you have. And judging by your dismissive attitude towards > 1960s software technology I'm unsure you're aware of what happened then, > either. I know that some people still prefer a printed report instead of being able to browse the data on screen. I don't. I know that OO people still prefer the obsolete hierachial and network data model to the relational model. I don't. > > > If there really was a requirement for ad-hoc getEmployee() methods > > What's ad-hoc about set theory and predicate logic? > Nothing. But why not use a language more suited to set theory than an OOPL? Indeed. Did I claim the opposite somewhere? Fredrik Bertilsson http://mybase.sf.net
From: AndyW on 28 Jan 2007 02:23
On Sat, 27 Jan 2007 16:25:29 -0500, Thomas Gagne <tgagne(a)wide-open-west.com> wrote: >frebe73(a)gmail.com wrote: >>>> You claim that it is possible to only have a few number of >>>> getEmployeeBySomeCriteria methods with optimized SQL statements for >>>> every different way you might need to fetch employee data? That should >>>> only be possible for rather small applications. >>>> >>> Can you give an example of an application that would have an excessive >>> number of getemployeBySomeCriteria() methods that doesn't encroach on >>> becoming a report writer? >>> >> >> A HR application need data about employees in many different ways. RCM >> already gave you one example of a very specific criteria for finding >> employees. When a company needs to reduce the staff, it would be nice >> if the HR application had a feature to find employees eligible for >> early retirement, wouldn't it? >If there wasn't a requirement for the previous 30 years to find >employees eligible for early retirement why should we assume that >requirement should have been anticipated? Do one-off questions deserve >one-off solutions? > >Instead of bloating our systems with the accumulation of years of report >requests, what if the IT department was able to turn-around requests for >that kind of data fairly quickly? Perhaps the IT department could keep >track of the requests it gets and create a most-frequently-asked-for >reports page? >> 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. >> Lets say we have a function sending information to >> insurance company about changes in salaries, we need a way to find >> employees with changed salary. How could you possible solve this only a >> few functions for finding employees? >> >Why do we assume the only way to find things is through a OO function? >Why ignore the database and the simplicity of SQL? That statement worries me slightly because if read one way it implies that OO applications do not require the use of SQL. Yet I would suggest that the use of service routines (think of them like stored procedures) often do contain SQL. Service routines are not in my mind OO things, but they are found and used in OO applications and often make up an integral part of those applications. Anyhow, my rule of thumb is that if a set of data is suitable for working in lists and discrete structures, then SQL is the way to go. Andy |