My first rant in a long time...
-
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?
-
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?
Although it is apparently an unpopular view I agree with you. I am currently on what should be a rather small scale embedded project but is a totally over engineered abortion. There are many layers that do nothing but pass on requests or data to other layers. The project is stuck in the "fix - new bug - fix - new bug" loop. It can't ship because it suffers from the water ballon problem - press over here and get a buldge over there. No one can see the whole picture and the side effects of changes are rampant. We are well prepared for any future eventuality. Too bad we can't meet present requirements. With so many layers we need a lot more people than we should. And they run wild because, although my company says all the right things about the software development process, the reality is it is followed haphazardly. Code reviews rarely occur and when they do they degenerate into discussions about variable names and the like because no one has the time to understand what the code really does. We could do that with static analysis tools. Requirements are a mess. We have little accurate documentation. The management wants fixes not new drawings. After all - analysis is over, implementation is over and we are in the bug fix phase. I will say that it is not totally OO's fault. You can screw it up in any language or methodology. OO just makes it easier. But I work with many young engineers (I'm the old man here) and this is all they know. They have the religion and have been told this is the only way to do things by professors most of whom never shipped a real product in their lives. Which is fine as long as you have the ability to apply it intelligently and the will power to execute it correctly. That's the end of my rant.
-
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!
1. I'm not sure I'd call Smalltalk or Simula obscure (OK, Simula maybe) - they've influenced most languages since. Notably C++ (which also predated Windows, I know because I used it back then on DOS - a "real" computer as far as I recall) was influenced by Simula. Smalltalk has influenced just about every modern OO language and in many ways was the first "real" OO language - in the way we define such things now. 3. Yes, I do ;-) (Unnumbered) - sorry, but from the style of your rant preceding it, all your criticisms seemed to apply to the style of projects you've worked on - the same management style would just have likely yielded the same problems whichever paradigm you used. To blame that on OO seems unjustified. I've seen many successful and failed projects, using many languages and development methodologies. Successful projects, in all cases had a clear architecture, was easy to read or well commented when needed (e.g. to circumvent bugs in the environment/compiler).
-
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?
"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!'" Challenge accepted! Seriously, I wrote a "smart client" application about five years ago for my company that had to have a Server database that synchronized data through a web service, to a user's computer that cached certain pieces of data on a user's computer so that they could make and print various reports from remote locations. One layer, (the reporting layer), worked rock-solid... until Windows Vista came out. Ever since then, the app has seemed to work less and less successfully with each new Windows Vista (to now Win 7) install. Almost 100% of the problems have been with the third-party reporting engine that I've had to consume (take a guess at which one that is). I work for a company that is excessively slow to change. Since bugs have crept up in the Reporting Layer due to the third-party library, I've been hassling management to let me re-write it using a better reporting tool. A lot has changed in 5 years and I am positive that there are better solutions. I've haven't yet received the approval to re-write the reporting layer but once I do (it really is just a matter of time) I will me quite glad that I can simply re-write the class that is drives the reporting process. Without that class, I'd have to spend a significant amount of time, dissecting the app looking for function dependencies and making sure that I understand each step of the pre-reporting process before changing any code. Subtle bugs creep in that way. With an OO model, I now know that I specifically developed the reporting layer as a class. All I need to do is export the classes signature and make a new class that contains the same variables and methods. Next, delete the old class code file and insert the new. Make sure that I have all my dependencies are copied into the outputted build and viola! On to testing! The difference between an OO solution and a procedural one would me that the replacement process will have taken possibly weeks (maybe even a month or more!) of additional time. I actually agree with your sentiment. I think it is an unfortunate truth that many developers learn about buzz "methodologies" and implement them because that's what everyone else is doing. An N-Tier system has to be better if there are more tiers, right? Isn't that the whole point of calling it "N" Tier? Flat out, absolutely wrong. IMHO, The idea behind a ti
-
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 don't use any OOP at all and prefer it that way. I use PowerBasic (Basic language compiler) and I write all my code using subroutines and functions and not a single object. One can have modular design without OOP. I believe it decreases code size significantly. I develop tools for programmers and currently my primary product is in its 5th generation. I like to use the Visual Basic runtimes to compare my runtimes (DLL's) to as far as size and functionality. The VB 5.0 and 6.0 primary runtime DLL is about 1.4 meg in size. It does not even support any of the common controls which require additional OCX's. Now the GUI engine I have developed (for use with Powerbasic to write Windows apps) is less than 1 meg in size (main runtime is 684 KB) and it contains the following: - complete GUI engine for Forms and nearly all of the built in controls in Windows, even most of the Common controls (ie. toolbars, treeviews, listviews, tab, etc.) and Richedit 1.0 and 2.0 controls. - drag and drop engine built in (build your own drag and drop visual designer using it) - subclassing engine - thread engine - print engine - graphics engine - ownerdraw and customdraw engines (customize controls the way you want) besides the above, the following custom controls are built in: - Canvas control which supports double buffers and DIB's (direct access to pixels) - Shape/Hot Spot control - Masked Edit control - Drag Handle control (for use with drag and drop engine) - MCI control - Files Listbox control - Property Listbox control - SplitterBar control the latest new custom control added is: - OpenGL based 3D Canvas control with a complete proprietary 3D script language built in (yes it is a real windows control) The Canvas control has a proprietary 2D Sprite engine built in (ie. move/show/hide Sprites, even with alphablending). There is also ... - Component (non-OOP based) engine (forms become reusable components) - Superclassing engine - Custom control engine - Layering engine (put controls on different layers and show/hide by layer) - Common Dialogs and a lot more. Now I don't use any OOP at all (no objects, no COM, no ActiveX), but it is very modular in design and reuses code as much as possible innternally. I haven't even reached the size of the main Visual Basic runtime yet and it packs in far more than you get in Visual Basic. The command set (API) is easy to use as well. Lastly you can simply copy your compiled EXE (using PowerBasic) with just one (or a few) runtime DLL's to any computer witho
-
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?"
I could give you way more more than one - but here are two. While OOA/OOP (and there is a difference) can, and too often is, overdone, it has practical usage. I had one project where I wrote a network monitoring system (in VB6). I had middleware. including a service, that monitored network equipment, including servers, using SNMP and WMI. One or more central monitoring UIs talked with the distributed systems. The distributed systems would push alerts back to the UIs, and the UIs could query the distributed systems. The UI install had only the UI components, and a set of interface DLLs that define the objects available from the distributed systems. The actual components for the distributed systems only resided there. I could have hacked up something using RPC calls and delimited strings, but using DCOM and objects was a better approach. I had one project where the business layer was OO, and in doing so all I needed to do to increase the number of users was to add another middleware server to the farm, and now I could handle a lot more users. The UI depended on a set of interfaces, and thus my UI could be a Win32 app and ASP (or now Win32, Win64, ASP.NET, Win7, etc.) No object oriented design is properly done without applying the KISS principle, IMHO. But trying to do distributed apps without OO is a waste of time, resources, and very hard to debug.
-
I can't but maybe that's why I'm working on a project where we just removed one of the 4 layers in the application, and are simplifying and whittling down things in the remaining code. You left out that not only does it slow down the application, it slows down the build and compile times too. :-D Also, each one of the devs ends up having a favorite layer and they write crazy complicated code in their favorite, and crap code in the others, nobody ends up owning or caring about the system as a whole. Or, the architect writes a ton of complicated data access code and turns a bunch of junior devs loose on the UI.
nobody ends up owning or caring about the system as a whole
That is where developer managers aren't doing their job.
-
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?
You may want to read this, http://blog.dmbcllc.com/2008/05/13/object-oriented-programming-has-failed-us/[^] someone else who agrees with your sentiments. I don't program for a living so I don't have much of an opinion either way. I can see some of the benefits of OOP; but I can also see how those benefits can be easily incorporated into structured programming.
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
-
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?
Sorry but OOP is a great tool. Your problem is the insane implementation. Turns out that just about anybody can turn the best ideas in the world into a steaming pile of crap. I feel your pain, my condolences.
-
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?
First thing, Object Oriented and Layered and not the same thing. Often they are both used, and often they are not. The science and art of Software Engineering is about managing complexity. Of course, if you have a very simple system, you will probably want a very simple software design - one or few layers, no object-oriented constructs. But, as your system grows with just the slightest complexity, be it hardware, timing, protocols, etc., you need some sort of layering or you'll have a huge mess of code. Layering and Object Oriented methods MANAGE COMPLEXITY. That's all they do. One example of layering not discussed in the thread is the ability to divide the work amongst a team by areas of expertise. Without layering, everyone would have to know everything. Does the USB protocol expert need to know about the application? Maybe not. Does the UI guy need to know about TCP/IP? Does the battery charger guy need to know about the application? Layering also makes testing much more thorough. You can test one layer independently from another. Of course, without layers, you could never integrate third party software libraries, stacks, etc. Object Oriented also thrives in this department. Take a nice library from someone and subclass their objects to your needs. So, I do believe that your software and the people you work with suck. No argument here. But, in my experience, thoughtful up-front design of layers of abstraction are the best, quickest, most efficient, and safest (I'm a medical device guy route. Stuart
-
The definition of layer is that it only sees the layer directly above and below it. So by layering, you can reduce the amount of the whole system that is seen from one single layer. This is just one way of reducing dependencies between parts of the code base, and this is a good thing (divide an conquer). Throwing all code in one namespace in one big file is not a very good approach. If your project's architecture is crap, it has nothing todo with OO or layering, it is caused by bad modelling by the architect.
Wout
wout de zeeuw wrote:
If your project's architecture is crap, it has nothing todo with OO or layering, it is caused by bad modelling by the architect.
:thumbsup: And someone who doesn't understand the difference when trying to figure out what's wrong with the project is programming like it's still '95. The OP wasn't a rant, it was a confession.
“The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.” ~ H.L. Mencken
-
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?
hi, like others already said, a system without abstraction is not maintainable. There are a lot of good examples out there, and most of them are working pretty well. Guess if you really want to know any, you would be pretty good in finding some. I have another question: What do you think would be the right approach? Functional? Procedural? Dynamic? Isn't it the task that has to accomplished that defines which is the best language and paradigm to use? I guess in your case you really should have an eye on some pretty well working (open source) projects. What about NHibernate? Eclipse? Mono? Is that all crap because of the architect in your team that wants to win the price of the worldwide-most-layers in a project? :) Holger