My first rant in a long time...
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
I think the problem is that most companies and people don't know how to use OOP programming correctly, or why it was created. You really need to read something like "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" or effective C++... or even begin here http://www.artima.com/intv/goldilocks.html. Without understanding these things completely... it becomes easy to jump on the bandwagon and dismiss the area entirely. Does anyone at these companies even know what a class invariant is? I bet most people writing class are not even thinking about writing their class as an invariant... yet its one of the most fundamental things to understand when writing good OO code. Note that I'm not arguing that everything should be written as OO, in fact that's another common miss-understanding. Understanding where OO is strong and where it is weak is key to becoming effective with OO techniques.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Can anyone give me ONE example where layered code has proved to be a major advantage? Sounds to me like you're working on an un-documented project. Bad. Can you imagine a protocol stack not being separated into layers? When you re-use code OO is a dream. A.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Johnny J. wrote:
And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped.
I definitely agree with this - although I love technology myself and like to experiment on new things.
Johnny J. wrote:
The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose.
It's obvious that the developers haven't cared - or haven't been encouraged to - document their code as they wrote it. You can't expect to keep track of everything in an OOP architecture without proper documentation.
Johnny J. wrote:
And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system.
If you keep going like this, you will have to bin the whole thing and start from scratch, using clear requirements and development strategies to achieve their accomplishment. Writing documentation as you develop is crucial to complex systems like the one you mention.
Johnny J. wrote:
I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage? I'm not talking about hypothetics like "Oh, what if we have to change to another type of database?" crap, because that is never going to happen in 99.9% of systems. Give me an example where someone has actually leaned back at a meeting and calmly said: "THANK GOD that we broke all the foobar code out in a separate foobar layer!" I challenge you - you can't.
Just think of SOA. As a result of proper layer separation you can make systems which use different technologies interoperate and achieve very complex results. Think of an Enterprise Service Bus (like th
-
David Knechtges wrote:
I can - I have an application that I layered using object orientation. I have been able to reuse two of the objects in 4 other projects unchanged, and another 3 objects in two other projects unchanged also.
Whereas I basically agree with you on this one, there's one big drawback. Changing the objects in one project might not be good for the rest of the projects. Or the requirements for the different projects regarding this specific object might move in different directions. Then you have to version and maintain different versions of the same object. But on the whole, I agree with you on that...
1f y0u c4n r34d 7h15 y0u r3411y n33d 70 g37 14!d Gotta run; I've got people to do and things to see... Don't tell my folks I'm a computer programmer - They think I'm a piano player in a cat house... Da mihi sis crustum Etruscum cum omnibus in eo!
Johnny J. wrote:
Then you have to version and maintain different versions of the same object
Well if they were different they wouldn't be the same object and anyway if you didn't 'layer' you would have to have two different objects anyway wouldn't you? Either way I pretty much agree with most of whats already been said (makes a change from the usual lounge blather :) )
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Downvoted (At least I'm letting you know) because: 1. Ignorance of history. The original OO language was Simula, dating back to the 1960's, so predating Windows (and even DOS) by a decade or two. The ideas were further formulated by Smalltalk and the Xerox Pal Alto research centre, who coincidentally developed much of the current user-interface system. 2. Layered architectures are not unique to OO programming. The Open Systems Interconnection (OSI) model, for example, uses a 7-layer architecture that has nothing to do with object-orientation. You've used this layered model as part of the process if posting your message, as it underlies the entire TCP/IP stack. Seems to work quite well to me. 3. You seem to be confusing badly run projects with the technologies used to implement them. Look up some works on OO development - particularly Kent Beck's book on Test Driven Development, and Martin Fowler's on Refactoring. It seems to me you should learn a development technique properly before criticising it.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
A few years back I was writing a phone application which used TAPI. The part that used TAPI was in a separate layer. Then I had a requirement to be able to communicate with an Alcatel PBX. The code had been tested against a Cisco, and worked there, but didn't work with Alcatel. After several days of debugging, and asking questions, an answer came from Alcatel: they didn't support everything that was needed. So I had to switch to using SIP. Luckily, because of the layering, I only had to rewrite that part, and didn't have to modify the core of the application. I do agree with the author however that all this layering is sometimes just in your way. To me this is all about finding the correct balance. Daniel
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Johnny J. wrote:
I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage? I'm not talking about hypothetics like "Oh, what if we have to change to another type of database?" crap, because that is never going to happen in 99.9% of systems. Give me an example where someone has actually leaned back at a meeting and calmly said: "THANK GOD that we broke all the foobar code out in a separate foobar layer!" I challenge you - you can't.
Multi-platform support. We have an application that needs to run on Windows XP machines and Windows Mobile 5.0-6.5 devices. The core functionality on each needs to be as close to "the same" as possible within the platform limitations, but they each need platform-suitable UIs. We built a core library that compiles to each platform, and a data object library also for both platforms separate to the core (so we can use the data model in other applications), and just drop a relevant UI on top of the methods and events exposed by the core.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Tell it like it is! If you want to read as well as rant, here's a nasty surprise forp OOPers. By the way: It's not hard to read stuff like "If y0u c4n r34d 7h15 ...", but we wonder what it would look like translated into Chinese. How do they do that, in Chinese? I've had people from the oddest places looking at a page of mine, "D0CTYPE HTML PUBL1C", which starts out with a D0CTYPE declaration: "h11p://vvvvvv.vv3.org/TR/1lmthxhtml1/TDT/1lmthxhtml1-str1ct.tdt" but google messed it up, and so does every browser that I know of. So that says, We can read; Browsers can't. Wallace Stevens wrote a poem about "The Man With The Blue Guitar", who "...plays things as they are." You may think Johnny J. isn't on top of things or really serious; but I think he is serious and is on top of things - and is playing things as they are.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
The fact that you have had bad experiences with code that was over OOed and layered doesn't mean that OO and layering are bad ideas in and of themselves. If you think object orientation is a "complication" to simple procedural and event driven code, you obviously don't understand the basic principles of OO. The troubles you are having in your current project are indicative of bad project management, not bad programming technology. There is good OOD and bad OOD... thats not OO's fault! Object Orientation is probably the single biggest simplifier in software development of the last 25 years. I am currently working on a project of over 200,000 lines of code split into three layers and over 250 classes, but I can explain how it works to a collegue in under 5 minutes flat. I challenge anyone to handle that level of complexity without OO!
-
The fact that you have had bad experiences with code that was over OOed and layered doesn't mean that OO and layering are bad ideas in and of themselves. If you think object orientation is a "complication" to simple procedural and event driven code, you obviously don't understand the basic principles of OO. The troubles you are having in your current project are indicative of bad project management, not bad programming technology. There is good OOD and bad OOD... thats not OO's fault! Object Orientation is probably the single biggest simplifier in software development of the last 25 years. I am currently working on a project of over 200,000 lines of code split into three layers and over 250 classes, but I can explain how it works to a collegue in under 5 minutes flat. I challenge anyone to handle that level of complexity without OO!
Large and complex programs have sucessfully been developed without OOD. You 'just' need to compensate whatever the language does not provide with more discipline in planning and coding. The practices of disciplined procedural programmers already bordered to object orientation, so object orientation was the next logical step. We shall see what the next logical step for disciplined object oriented programmers will be.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'. I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
-
Tell it like it is! If you want to read as well as rant, here's a nasty surprise forp OOPers. By the way: It's not hard to read stuff like "If y0u c4n r34d 7h15 ...", but we wonder what it would look like translated into Chinese. How do they do that, in Chinese? I've had people from the oddest places looking at a page of mine, "D0CTYPE HTML PUBL1C", which starts out with a D0CTYPE declaration: "h11p://vvvvvv.vv3.org/TR/1lmthxhtml1/TDT/1lmthxhtml1-str1ct.tdt" but google messed it up, and so does every browser that I know of. So that says, We can read; Browsers can't. Wallace Stevens wrote a poem about "The Man With The Blue Guitar", who "...plays things as they are." You may think Johnny J. isn't on top of things or really serious; but I think he is serious and is on top of things - and is playing things as they are.
Wow, what an informed, considered and articulate opinion that is. (The nasty surprise). Again, someone who evidently doesn't understand OOP ranting about it. The idiot even classes C as an OOP language.
modified on Wednesday, January 26, 2011 6:46 AM
-
Downvoted (At least I'm letting you know) because: 1. Ignorance of history. The original OO language was Simula, dating back to the 1960's, so predating Windows (and even DOS) by a decade or two. The ideas were further formulated by Smalltalk and the Xerox Pal Alto research centre, who coincidentally developed much of the current user-interface system. 2. Layered architectures are not unique to OO programming. The Open Systems Interconnection (OSI) model, for example, uses a 7-layer architecture that has nothing to do with object-orientation. You've used this layered model as part of the process if posting your message, as it underlies the entire TCP/IP stack. Seems to work quite well to me. 3. You seem to be confusing badly run projects with the technologies used to implement them. Look up some works on OO development - particularly Kent Beck's book on Test Driven Development, and Martin Fowler's on Refactoring. It seems to me you should learn a development technique properly before criticising it.
My 5 for a great response.
Software Zen:
delete this; -
Downvoted (At least I'm letting you know) because: 1. Ignorance of history. The original OO language was Simula, dating back to the 1960's, so predating Windows (and even DOS) by a decade or two. The ideas were further formulated by Smalltalk and the Xerox Pal Alto research centre, who coincidentally developed much of the current user-interface system. 2. Layered architectures are not unique to OO programming. The Open Systems Interconnection (OSI) model, for example, uses a 7-layer architecture that has nothing to do with object-orientation. You've used this layered model as part of the process if posting your message, as it underlies the entire TCP/IP stack. Seems to work quite well to me. 3. You seem to be confusing badly run projects with the technologies used to implement them. Look up some works on OO development - particularly Kent Beck's book on Test Driven Development, and Martin Fowler's on Refactoring. It seems to me you should learn a development technique properly before criticising it.
Fair enough - I expected someone would, but your reasons are wrong: 1) I never claimed that my "account" was historically correct in all cases. I'm sure you're correct that some oo languages existed befor that, but I was talking in general about "normal" programming of "normal" computers - not including specialized and obscure languages and systems. 2) I did't say that either. I just bundled the two things together to rant against the both at the same time. 3) Who's to say where to draw that line? You have the truth yourself? (not numbered comment) Just because you know a technique doesn't mean you can't critsicise it. The fact that I critiscise OO is not a proof that I don't understand it. However, you're entitled to your opinion as well, and I'm not going to downvote your response...
1f y0u c4n r34d 7h15 y0u r3411y n33d 70 g37 14!d Gotta run; I've got people to do and things to see... Don't tell my folks I'm a computer programmer - They think I'm a piano player in a cat house... Da mihi sis crustum Etruscum cum omnibus in eo!
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
We clearly saw a boost in developer productivity in our small development shop. I was able to create a WCF layer that returns well thought out and easy to use objects from our legacy (and proprietary) non SQL based data store. Prior to doing this we had two developers who had written everything and 6 developers who were "afraid to touch the code." Now every developer codes against the service layer as an easy to use API. They don't have to deal with networking code, tons of string parsing to get at the data, or basic business logic. Our productivity went up substaintially allowing us to introduce a mobile, web, smartphone, tablet, and other "versions" of our client that those 6 developers have been able to build. Prior to building this WCF layer (really an API with built in networking) the developers would've been overwhelmed by having to deal with porting one, big, flat codebase into various presentation layers. Also, you dismiss the "changing the datastore" scenario but for us this is a true benefit. Like I said, we are using a proprietary datastore, having the middle layer (WCF) makes changing this much easier as one of our business requirements is that we cannot change all of the clients simultaneously in our customer's environments. So instead we can have the WCF layer look at the client type that is coming in and translate the data back and forth from the new format to the old and vice versa during migration periods. Seven layers sounds ridiculous and would be as overcomplicated as trying to deal with one huge, flat, piece of code that does everything. But I've found that having three intelligently designed layers (database, "application," presentation) works pretty well. Sean
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Nice rant. Here is a link to the only thing that should require 7 layers: This Has 7 Layers[^] I love objects and I use 3 layers. This keeps my projects nicely organized and I know where everything is at all times. That said, I couldn't name 7 separate layers if my life depended upon it. I cannot imagine how that could be anything but a confusing mess.
-
Nice rant. Here is a link to the only thing that should require 7 layers: This Has 7 Layers[^] I love objects and I use 3 layers. This keeps my projects nicely organized and I know where everything is at all times. That said, I couldn't name 7 separate layers if my life depended upon it. I cannot imagine how that could be anything but a confusing mess.
Thanks - And thanks for the cool link - that is indeed a valid reason for having seven layers... :)
1f y0u c4n r34d 7h15 y0u r3411y n33d 70 g37 14!d Gotta run; I've got people to do and things to see... Don't tell my folks I'm a computer programmer - They think I'm a piano player in a cat house... Da mihi sis crustum Etruscum cum omnibus in eo!
-
We clearly saw a boost in developer productivity in our small development shop. I was able to create a WCF layer that returns well thought out and easy to use objects from our legacy (and proprietary) non SQL based data store. Prior to doing this we had two developers who had written everything and 6 developers who were "afraid to touch the code." Now every developer codes against the service layer as an easy to use API. They don't have to deal with networking code, tons of string parsing to get at the data, or basic business logic. Our productivity went up substaintially allowing us to introduce a mobile, web, smartphone, tablet, and other "versions" of our client that those 6 developers have been able to build. Prior to building this WCF layer (really an API with built in networking) the developers would've been overwhelmed by having to deal with porting one, big, flat codebase into various presentation layers. Also, you dismiss the "changing the datastore" scenario but for us this is a true benefit. Like I said, we are using a proprietary datastore, having the middle layer (WCF) makes changing this much easier as one of our business requirements is that we cannot change all of the clients simultaneously in our customer's environments. So instead we can have the WCF layer look at the client type that is coming in and translate the data back and forth from the new format to the old and vice versa during migration periods. Seven layers sounds ridiculous and would be as overcomplicated as trying to deal with one huge, flat, piece of code that does everything. But I've found that having three intelligently designed layers (database, "application," presentation) works pretty well. Sean
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
hmmm...I don't know how you could possible get along without breaking it up into layers. It's nice to have a presentation tier, business tier, and data tier at the very least. If you do not have these three tiers and have your business logic, presentation, and data calls all in the same tier, you'll start running into problems when multiple applications call the same stored procedures, but then one of the applications logic changes and needs to call a different stored procedure. You'll have to go through all the application pages to ensure you have updated to the new stored proc. As opposed to the n-tier, you change it in one place. If your business logic changes for one process, you would have to update that process in all parts of your application rather than just one spot in the business tier. If you break it out into tiers, you can have multiple platforms (web, windows forms, smart phones, ect) use the same business tier, and data tier. When this is done, only 1/3 of the work would have to be done for each of the platforms. If you do not have an n-tier design, you're going to be hating it when they say that they need to move to a new platform because your presentation is all mixed in with your business and data. With OOP you can make your own exception handling logic in one place and reuse in multiple application. So when an exception happens, you can handle it in a certain way (e-mail error with stack trace, text message a group of people, write to system log, ect). Any time its requested to add an additional medium to the alert list, you change in one place and all applications are instantly working. There are an infinite number of examples as to why n-tier/OOP programming is better. One of the biggest reasons is code reuse as you can tell form my examples. I hope this helps your understanding.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Actually... We DID switch a fairly large database with thousands of tables with minimal impact on the application code. I agree with some of your sentiment though... Don't do it just to do it. I catch myself wanting to write things just to "round out" some class, but if there is not an immediate need, it means I would just be creating instant "dead" code for no reason. Also, why write test cases for something that is not needed yet? I will usually end up writing a few blocks of comments on what I was thinking and leave it at that. I have also seen some of my teammates' code that is 95% of what I want, but they failed to introduce one small step of separation and included some coupling that I thought was inappropriate. This made it impossible to use their code. In one instance, the 95% of the code was in the middle of something that would require a lot of painful testing with high risk of breaking something. What would you do?