Well, to send your 5 bytes of "ROFL\n" example, the "good old no frills plain TCP communication" comes with > 40 bytes of headers as well (TCP and IP). That gives at least 800% overhead even without any kind of application protocol, so arguing that TCP/IP is "cheap" is to stretch the facts a bit.
If you're running servers that are to busy to run with standard application protocols (HTTP), maybe you need to drop the protocols below as well?:-)
Perhaps, but do you think most places *want* to stick with COBOL forever?
Developers? Some, but probably not the majority. The ones paying? Yes, as long as it is magnitudes cheaper than rewriting it all.
>And I personally would not go as far as calling the use of these products exceptions.
Well, OO designs tend to do in app code what database-centric shops do in the database. If you do X alot, then it is no longer an exception by definition. But that does not necessarily make it a "good" practice. Databases take care of a lot of stuff that I would hate to have to code up myself. And, relational is a powerful paradigm if you know how to use it.
Hmm, I get the feeling that you're continously try to mix the transaction question with the OO question? Transaction-handling middleware systems have been widely used for 30 years and it is only recently some of them have been based on OO. How can transactions over several databases and/or other systems not been seen as a "good" practice when several systems often are involved in transactions?
As a separate topic: Yes, perfectly correct, some designs sometimes do in app code what others do in database. For repetitive code (such as OO-to-relational mapping) sometimes one buys products to generate that code, much in the same way non OO projects uses certain tools or development environments that do the same stuff. Are you arguing that there is only one "good" way to do this?
The reason for using different approaches may be many. For example: Where do I put my eggs? At the db vendor? Myself? Some third-party product? Different answers for different situations. In systems I've worked with, different databases have been used for different customers depending on the machines they use, their expected transaction volume and the amount of money the customer was willing to put on the db-part of the system. In those cases, you want to keep away from doing neat stuff in the databases since you'll have to adapt or rewrite that code for a handful of products. Not productive.
Of course databases can do a lot of good stuff and I have never questioned that the relational paradigm is highly useful. But there really are several ways to do things and I can't see a reason for not choosing what is most proper for each situation?
I find that usually the language used changes also. Often a new GUI fad is used as a justification to start over, for good or bad. Things went from COBOL to VB to Web, etc. Perhaps this is not rational, but that is what is often done. The UI "feel" is often too different to just plug in one-to-one anyhow. Plug-and-play drop in of UI paradigm requires either too much indirection, or too strong a crystal ball.
I think (or rather worry) that the reason that they change language often is the reason I gave. Too coupled code made it cheaper to rewrite it all. Using a new language for the presentation and keeping the current working logic is not a problem if there is a separation.
A colleague was working as an architect for a bank. They had running (business critical) systems written in 25 (yes, twenty-five) different languages. Some of these languages was actually unknown to the all the currently employed developers (which to my surprise didn't really hurt them since they could communicate with these systems, get the data they needed from it and continue the processing elsewhere).
But to take a mainstream bank example: When you are internet-banking, the systems that are used are not rewritten. The html producing code communicates with other systems, most of them written in COBOL. More often today, some Java Enterprise middleware seems to end up in the middle of all things, mainly to encapsulate older systems and make it easier to communicate with them. But the COBOL code is still running in the bottom. 24/7. It just has to.
An easy way to see that this is the case is that with the Euro introduction in many European countries, COBOL programmers are (again) back on request.
Most transactions I face are done by the database. Sure, there are exceptions, but that is the case for anything. Show me that OO works better than procedural for such exceptions.
I never said that OO would do that better. And OO per see doesn't. I just answered your question if transaction handling wasn't the databases job. In many systems, it is some (OO or non OO based) middleware products job. And I personally would not go as far as calling the use of these products exceptions.
> OO is a lot about encapsulation.
Other OO fans will probably disagree. There is no consensus on what OO is "really about".
No, there is probably not any consensus (although I think most OO language designers would tell you that there was a good reason they added two or more access levels for the data). There are as many ways of treating OO as there are developers. But there are also as many ways of treating procedural code as there as developers. At least when I was doing all my development in procedural languages, there were huge differences in what things people valued and the practises they used. If that hasn't changed, I guess the situation is the same in both "camps"?
The "separation of presentation from logic" is often overdone in my opinion.
Allow me to disagree. The lack of separation between presentation and logic and/or data cost a lot of time and money.
Example: Think of a business like a bank of insurance company. A lot of their data structures and logic have been proved to work for decades. The last 15 years, companies like these have gone through a number of presentation changes: from console to console graphics to window managed systems (often a few different flavors/versions) to html and maybe to wap and soon to... (whatever the next big thing may be). The logic and data structures does not have to be touched just because people wants a new presentation - but only if separation was done properly. I've built systems which generated web-pages, pda-targeted pages and FrameMaker documents (for printed publications) - all from the same data. In such systems, mixing presentation and data/logic is a sure way to introduce problems.
Another example is the misuse of the RAD tools. RAD tools seem to tempt programmers to skip separation. Why? Well, you can just doubleclick on a button to end up in a "onButtonPressed" method where you can write code. This ease of this is of course good, but what is not good is that way too often the programmers seems to stop thinking and actually writes the logic code there instead of the call to the logic code (which is what should be written in such methods). So, what happens when the vendor stops supporting the tool? Or when a new important presentation technique shows up? Rewite the presentation? Yes, if separation was done properly. If not, you can look forward to rewriting it all.
It often results in having to make changes in TWO places instead of one when you add or alter UI elements, and you cannot switch from say desktop-targeted-HTML to PDA in a one-to-one manner anyhow.
Of course one needs to write new presentation code if you want to present your data in new ways. But logic for business rules and all the data and data structures does not have to be touched if the separation exists. That is truly important if stability of the system is of high priority and wasting time/money is of low priority.
Some of us think that OOP is oversold.
Since I became a bit curious about this opinion I visited your website (http://www.geocities.com/tablizer) and found a lot of interesting reading. In some ways I agree with your point altough the discussion seems to be very database-centric. I do agree that if the application layer only builds an OO-version of the data just to put it up and down to a relational database - then nothing is gained. If the applications are very db-centric and does not do much with the data except for presenting it to users and letting them add/edit/remove blocks of data - nothing is gained. That, however, does not make OO any less useful for a wide area of problems. But that is a discussion of its own. OO is a lot about encapsulation. Encapsulation promotes separation. Separation can definately be done without OO - but lack of separation frequently ends with disaster.
> Also, there was no system support for transactions
Isn't that the database's job?
Not always. If there is only one database or the transaction only has to span over interaction with one database - it could be the database's job. If the transaction involves more than one database and/or something else, i.e. an accounting system or a credit card system, then it can not be database's job.
Hasn't MVC been discredited? There are a lot of complaints about it in techie forums.
(Is there anything that hasn't been discredited?) MVC is about separation of concerns. The Model changes due to changes in the business, the View may change due changes in the business, but major View changes is often the result of either fashion or technical evolution. These concepts are held toghether by the Controller so they can remain separeted. MVC is useful when the need for separation exists.
To sum it all up: Don't forget separation. It is one of the most important things in software development.
Well, Feature Driven Design may be a variant of many things, but not a variant of UML. The Unified Modeling Language (UML) is a graphic language and not (even close) to a methodology.
It is used by many methodolgies for drawing pictures of i.e. relationship between objects or interactions between objects, but the UML itself is a language - nothing more, nothing less.
Slashdot Mirror
Well, to send your 5 bytes of "ROFL\n" example, the "good old no frills plain TCP communication" comes with > 40 bytes of headers as well (TCP and IP). That gives at least 800% overhead even without any kind of application protocol, so arguing that TCP/IP is "cheap" is to stretch the facts a bit.
:-)
If you're running servers that are to busy to run with standard application protocols (HTTP), maybe you need to drop the protocols below as well?
The local variables employed and not_dead are not initialized and we may never even enter the loop. ;)
Developers? Some, but probably not the majority. The ones paying? Yes, as long as it is magnitudes cheaper than rewriting it all.
>And I personally would not go as far as calling the use of these products exceptions.
Well, OO designs tend to do in app code what database-centric shops do in the database. If you do X alot, then it is no longer an exception by definition. But that does not necessarily make it a "good" practice. Databases take care of a lot of stuff that I would hate to have to code up myself. And, relational is a powerful paradigm if you know how to use it.
Hmm, I get the feeling that you're continously try to mix the transaction question with the OO question? Transaction-handling middleware systems have been widely used for 30 years and it is only recently some of them have been based on OO. How can transactions over several databases and/or other systems not been seen as a "good" practice when several systems often are involved in transactions?
As a separate topic: Yes, perfectly correct, some designs sometimes do in app code what others do in database. For repetitive code (such as OO-to-relational mapping) sometimes one buys products to generate that code, much in the same way non OO projects uses certain tools or development environments that do the same stuff. Are you arguing that there is only one "good" way to do this?
The reason for using different approaches may be many. For example: Where do I put my eggs? At the db vendor? Myself? Some third-party product? Different answers for different situations. In systems I've worked with, different databases have been used for different customers depending on the machines they use, their expected transaction volume and the amount of money the customer was willing to put on the db-part of the system. In those cases, you want to keep away from doing neat stuff in the databases since you'll have to adapt or rewrite that code for a handful of products. Not productive.
Of course databases can do a lot of good stuff and I have never questioned that the relational paradigm is highly useful. But there really are several ways to do things and I can't see a reason for not choosing what is most proper for each situation?
Cheers!
I think (or rather worry) that the reason that they change language often is the reason I gave. Too coupled code made it cheaper to rewrite it all. Using a new language for the presentation and keeping the current working logic is not a problem if there is a separation.
A colleague was working as an architect for a bank. They had running (business critical) systems written in 25 (yes, twenty-five) different languages. Some of these languages was actually unknown to the all the currently employed developers (which to my surprise didn't really hurt them since they could communicate with these systems, get the data they needed from it and continue the processing elsewhere).
But to take a mainstream bank example: When you are internet-banking, the systems that are used are not rewritten. The html producing code communicates with other systems, most of them written in COBOL. More often today, some Java Enterprise middleware seems to end up in the middle of all things, mainly to encapsulate older systems and make it easier to communicate with them. But the COBOL code is still running in the bottom. 24/7. It just has to.
An easy way to see that this is the case is that with the Euro introduction in many European countries, COBOL programmers are (again) back on request.
Most transactions I face are done by the database. Sure, there are exceptions, but that is the case for anything. Show me that OO works better than procedural for such exceptions.
I never said that OO would do that better. And OO per see doesn't. I just answered your question if transaction handling wasn't the databases job. In many systems, it is some (OO or non OO based) middleware products job. And I personally would not go as far as calling the use of these products exceptions.
> OO is a lot about encapsulation.
Other OO fans will probably disagree. There is no consensus on what OO is "really about".
No, there is probably not any consensus (although I think most OO language designers would tell you that there was a good reason they added two or more access levels for the data). There are as many ways of treating OO as there are developers. But there are also as many ways of treating procedural code as there as developers. At least when I was doing all my development in procedural languages, there were huge differences in what things people valued and the practises they used. If that hasn't changed, I guess the situation is the same in both "camps"?
The "separation of presentation from logic" is often overdone in my opinion.
Allow me to disagree. The lack of separation between presentation and logic and/or data cost a lot of time and money.
Example: Think of a business like a bank of insurance company. A lot of their data structures and logic have been proved to work for decades. The last 15 years, companies like these have gone through a number of presentation changes: from console to console graphics to window managed systems (often a few different flavors/versions) to html and maybe to wap and soon to ... (whatever the next big thing may be). The logic and data structures does not have to be touched just because people wants a new presentation - but only if separation was done properly. I've built systems which generated web-pages, pda-targeted pages and FrameMaker documents (for printed publications) - all from the same data. In such systems, mixing presentation and data/logic is a sure way to introduce problems.
Another example is the misuse of the RAD tools. RAD tools seem to tempt programmers to skip separation. Why? Well, you can just doubleclick on a button to end up in a "onButtonPressed" method where you can write code. This ease of this is of course good, but what is not good is that way too often the programmers seems to stop thinking and actually writes the logic code there instead of the call to the logic code (which is what should be written in such methods). So, what happens when the vendor stops supporting the tool? Or when a new important presentation technique shows up? Rewite the presentation? Yes, if separation was done properly. If not, you can look forward to rewriting it all.
It often results in having to make changes in TWO places instead of one when you add or alter UI elements, and you cannot switch from say desktop-targeted-HTML to PDA in a one-to-one manner anyhow.
Of course one needs to write new presentation code if you want to present your data in new ways. But logic for business rules and all the data and data structures does not have to be touched if the separation exists. That is truly important if stability of the system is of high priority and wasting time/money is of low priority.
Some of us think that OOP is oversold.
Since I became a bit curious about this opinion I visited your website (http://www.geocities.com/tablizer) and found a lot of interesting reading. In some ways I agree with your point altough the discussion seems to be very database-centric. I do agree that if the application layer only builds an OO-version of the data just to put it up and down to a relational database - then nothing is gained. If the applications are very db-centric and does not do much with the data except for presenting it to users and letting them add/edit/remove blocks of data - nothing is gained. That, however, does not make OO any less useful for a wide area of problems. But that is a discussion of its own. OO is a lot about encapsulation. Encapsulation promotes separation. Separation can definately be done without OO - but lack of separation frequently ends with disaster.
> Also, there was no system support for transactions
Isn't that the database's job?
Not always. If there is only one database or the transaction only has to span over interaction with one database - it could be the database's job. If the transaction involves more than one database and/or something else, i.e. an accounting system or a credit card system, then it can not be database's job.
Hasn't MVC been discredited? There are a lot of complaints about it in techie forums.
(Is there anything that hasn't been discredited?) MVC is about separation of concerns. The Model changes due to changes in the business, the View may change due changes in the business, but major View changes is often the result of either fashion or technical evolution. These concepts are held toghether by the Controller so they can remain separeted. MVC is useful when the need for separation exists.
To sum it all up: Don't forget separation. It is one of the most important things in software development.
Well, Feature Driven Design may be a variant of many things, but not a variant of UML. The Unified Modeling Language (UML) is a graphic language and not (even close) to a methodology.
It is used by many methodolgies for drawing pictures of i.e. relationship between objects or interactions between objects, but the UML itself is a language - nothing more, nothing less.