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 five voted you because I think you are generally right, but I’m not agreeing with this one:
Johnny J. wrote:
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.
The point is not in changing the database, you are right that this is not very likely to happen, but you don’t want in a bug system all developers to make their own calls to the database using their different skill’s levels and different approaches. So using a separate tear for the connectivity is a good idea for big projects. It’s also wasting a time for a little projects tho.
There is only one Ashley Judd and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
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?
There is a time and a place for abstraction and layering. Some projects are just too small to bother with all of that. I'm working on a C# project right now, but end using the language like a procedural language due to the design. There are exceptions where we do use OO. Layering is great if you need it. Another project I worked on leveraged a data layer to make them DBMS independent. While this is great if they need to switch platforms, there is overhead for setting this abstraction up. Further more, when doing complex SQL queries, there are language specific items that you should/could leverage to speed up the queries. Instead, their SQL is generic and slower than it could be. Hogan
-
Johnny J. wrote:
Can anyone give me ONE example where layered code has proved to be a major advantage?
It is definitelly a major advantage to the overpaid "software architects" who "architected" the whole mess.
modified on Tuesday, January 25, 2011 11:13 AM
two words my friend, Job Security :^)
Yusuf May I help you?
-
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 challenge you - you can't.
Three real examples:- I started on a product about 10 years back primarily for SQL Server database. The database access was totally separated into a separate layer (we could not have just used OLEDB/ADO.NET/ODBC). Then sales people came out with this requirement for supporting Oracle. 3 weeks of hard work and we had the Oracle support. Very recently sales people came up with support for DB2, and that was also done. Thankfully, the database access was totally separated into a layer. While developing a major version of the project, we wanted to support Active Script languages (VBScript and JavaScript). The old version already had a proprietary scripting language. By encapsulating scripting into its own layer, I was able to support the proprietary language for the old clients while the new clients used the new scripting language support. And when CodeDOM became hot, I was able to add support for CodeDOM and .NET based scripting support. I was moving to .NET from a C++/COM based system. I did create a "remoting layer" so that the remote access technology was not hardwired into application logic. What it allowed me to do was to have a UI based on latest .NET controls and an Web application which used either COM underneath while we were moving to WCF. In all three cases, I was glad that the application had layers.
-
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?
This challenge you will lose. I have just finished a web application at work which indeed has a layered archtecture. It is just going into productive use. At first we surely had performance issues. No wonder, since the application's purpose is to provide with customized downloads of business data from a database. Some of our last tests included downloading the entire database, serialized into one huge XML of several gigabytes. It finished this test without error and in a reasonable time. Of course a bit of optimization was required on several levels, but the possible delay through calls between the layers was the least of our concerns. Anyway, I have been programmnig for a while as well. My first programs where machine codes which I typed in with the hex keypad. From time to time I still start my old computer and do just that again, just for fun. Please believe me when I say, that I have some experience writing code for a very weak processor and with a few kilobytes RAM. To put things into perspective: Recently I calculated that the old machine would need about four days to read a DVD. Just read it from start to end, not store the data in any way or even process it. More than 20 years ago I thought in a similar way about object orientation. Reading your post, I'm now very happy I took the time to take a closer look and found out for myself that object orientation has more to offer than yet another way to type your code. No insult intended, but whining how good things used to be is a good sign that you have become a fossil. And you admit it yourself: You don't even want to understand this 'new' stuff, but on the other side you tell us how bad it is. So please, tell us, how exactly do you judge these things without understanding them?
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.
-
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?
Got an example we just finished last year: The project had 3 layers - Presentation/Service/Data Access with Domain Models being used as the parameter/return values (there was little direct editing going on so we didn't need scads of view models). Our data access layer was an abstraction on top of Linq to SQL. When we got to a point where we needed some features that L2S didn't provide (not to mention the technology being deprecated in favor of EF), we decided to migrate to NHibernate. We re-wrote our data access layer, had to tweak our services a tiny bit, and Bob's-your-uncle. And several times during the development, I did, in fact, say out loud "Thank God we had that L2S stuff wrapped in its own layer!"
-
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?
So what you'd really like is for that button click handler you're looking at to explicitly write to the data base, talk to the corporate server, wait for the response, search the data base using the results, update the display with the results of the data base search, disable three buttons on another dialog, enable a menu item if a checkbox on a second dialog is checked, write three entries to the debug logs on Tuesday, close the data base connection (unless the server failed to return results), log the user out from department server, log the user into the Sales server (unless the user type is Admin, based on a data base entry in HR), ...
Software Zen:
delete this; -
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?
Here is one example: we have a web application that has to run somewhat time-consuming tasks (like 1 minute). Those cannot be handled during a web request, so we have to launch an async process to do that and the web page polls the status every now and then (or the user simply navigates away). So far we run these async tasks inside the web servers (not the best idea) using an abstract task runner. Now we want to move the async tasks execution outside the servers, onto dedicated machines. The code that launches and polls tasks won't change a bit, thanks to the fact that we explicitly have an abstraction layer. Also, we develop ScrewTurn Wiki, an open-source application. Data is accessed via an abstraction layer (a generic Storage Provider interface) and you can swap SQL- and file-based storage providers AT RUNTIME, or use both (and yes, that's useful and used). Also, the SQL providers have an additional abstraction layer that allows to swap different DBMS behind the scenes. The rest of the application has no idea what's going on on the storage. I've been developing for only a few years, but this kind of things seem particularly obvious to me. The few times I had to program in a non-OO way, I just felt lost.
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe, but not a personality. [Charlie Brooker] ScrewTurn Wiki, Continuous Localization and My Startup
-
Here is one example: we have a web application that has to run somewhat time-consuming tasks (like 1 minute). Those cannot be handled during a web request, so we have to launch an async process to do that and the web page polls the status every now and then (or the user simply navigates away). So far we run these async tasks inside the web servers (not the best idea) using an abstract task runner. Now we want to move the async tasks execution outside the servers, onto dedicated machines. The code that launches and polls tasks won't change a bit, thanks to the fact that we explicitly have an abstraction layer. Also, we develop ScrewTurn Wiki, an open-source application. Data is accessed via an abstraction layer (a generic Storage Provider interface) and you can swap SQL- and file-based storage providers AT RUNTIME, or use both (and yes, that's useful and used). Also, the SQL providers have an additional abstraction layer that allows to swap different DBMS behind the scenes. The rest of the application has no idea what's going on on the storage. I've been developing for only a few years, but this kind of things seem particularly obvious to me. The few times I had to program in a non-OO way, I just felt lost.
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe, but not a personality. [Charlie Brooker] ScrewTurn Wiki, Continuous Localization and My Startup
With all that abstraction, I'm sure it will be no time at all before the desktop edition is upgraded to 3.0, right? :rolleyes: By the way, thanks for making ScrewTurn Wiki. I'm getting all my coworkers hooked on it now. :)
-
I've got several architecture books at home that I've never really read. I should pick one up and get stuck into it. :-D
Pete
Peter Mulholland wrote:
I should pick one up and get stuck into it.
Don't do that. Use it for its proper purpose. Propping up a wonky coffee table.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus!
-
Here is one example: we have a web application that has to run somewhat time-consuming tasks (like 1 minute). Those cannot be handled during a web request, so we have to launch an async process to do that and the web page polls the status every now and then (or the user simply navigates away). So far we run these async tasks inside the web servers (not the best idea) using an abstract task runner. Now we want to move the async tasks execution outside the servers, onto dedicated machines. The code that launches and polls tasks won't change a bit, thanks to the fact that we explicitly have an abstraction layer. Also, we develop ScrewTurn Wiki, an open-source application. Data is accessed via an abstraction layer (a generic Storage Provider interface) and you can swap SQL- and file-based storage providers AT RUNTIME, or use both (and yes, that's useful and used). Also, the SQL providers have an additional abstraction layer that allows to swap different DBMS behind the scenes. The rest of the application has no idea what's going on on the storage. I've been developing for only a few years, but this kind of things seem particularly obvious to me. The few times I had to program in a non-OO way, I just felt lost.
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe, but not a personality. [Charlie Brooker] ScrewTurn Wiki, Continuous Localization and My Startup
You felt lost when having to do something in the oldschool way? That's understandable. Further up I wrote about my old self-built computer, which I still have and (occasionally) write some code for. The limited resources, especially the weak processors and the tiny RAM required another way to write code. I actually found a C compiler for the old machine. It works, but the compiled code is very impractical. To make things short: The old CPU (which roughly can execute 200000 instructions per second) uses about 30% of its capacity to call functions, push parameters on the stack and clean up after returning. That's too big a slice from a too small cake. And the compiled code very quickly eats up my tiny 4k RAM. Coding like we would do it today simply does not work here. But that's no problem, since the programs themselves were much smaller and less complex than those today. Making as much as possible out of very little is slowly becoming a lost art, so far I would even agree with the original post. You would not believe what you can get when you pick out a performance critical part of a C++ program and optimize it in the oldschool way with assembly code. But still, object orientation, good design and also discipline are not bad at all. They are the best ways up to now to deal with the ever growing size and complexity of the applications.
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.
-
With all that abstraction, I'm sure it will be no time at all before the desktop edition is upgraded to 3.0, right? :rolleyes: By the way, thanks for making ScrewTurn Wiki. I'm getting all my coworkers hooked on it now. :)
Oh well, the problem with the Desktop Edition is that we lack resources to build and maintain the installer, which is far from being simple. Also, I'd avoid XP like the plague and building the installer would require me to test it under XP too... :D
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe, but not a personality. [Charlie Brooker] ScrewTurn Wiki, Continuous Localization and My Startup
-
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.
Andy Brummer wrote:
You left out that not only does it slow down the application, it slows down the build and compile times too.
You're right, I forgot that - another good point!
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!
-
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. It really comes down to architecting the solution. I find that too many times people just jump in to the coding without really thinking about the problem they are trying to solve. Then they just graft change after change on top of each other until you get the mess that you are dealing with now. Like anything else in software development, object orientation is another tool in the toolbox. At times it is the right tool to use, in others it is not. It is the RESPONSIBILITY of the developer to choose the right tool for the job, just like a mechanic working on a car, or a doctor working on a person.
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!
-
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.