Printable View
Did you not read the entire post?Quote:
Originally Posted by RhinoBull
faster how? processing; how about in the long run when there is maintenance to be done? Not so fast then, and if it's procedural there is ALWAYS maintenance that needs to be done.
Procedural does not always equate to faster.
The amount of maintenance that needs to be done depends on the requirements of the client. The time and effort involved to effect such maintenance depends on the flexibility of the architecture of the system. Both OO and procedural systems can vary hugely in this regard but OO designs lend themselves to rigid architectures. This can be bad for maintenance (or good - depending on the type of work required).
In other words, your procedural systems must have been badly designed.
Nice to see someone else who hates OOP and thinks it smells :D
OOP bundles together data and functions - this is highly undesirable and annoying. The concept used in for instance Haskell classes are much more flexible and useful, because the data is abstracted from a class.
However I don't agree, that abstractions are evil - it is OOP that corrupts the pure concept of abstraction, because of all the unnecessary overhead that polymorphism causes, which is why you have generic programming in the first place. What you would rather have is a mechanism that applies formal methods to prove that a function or a class (any type with specified operations/functions) really do what they are suppose to do. This would ensure that abtractions are not just abstractions by name.
Try not to confront - otherwise you might be talking to yourself... :rolleyes:Quote:
Originally Posted by drunkenmonkey
I remember (with some sheepish embarassment) my first meeting at my current workplace (3 years ago). It was to discuss a strict programming architecture that we were to apply to every single application we'd ever write - regardless of how big or small it was. :rolleyes: As I dimly recall, this involved at least 6 levels of abstraction and over 36 subclasses. It took 2 hours to explain how it all worked.
At the time, I wasn't very enthusiastic about the idea, but back then I couldn't put my finger on why. After reading Penagate's original posting, I realise why - it was OO Design and abstraction gone mad. A perfect example of Architecture Astronauts at work. And another lesson that there's no such thing as a Silver Bullet.
I Like OO programming :)
It save me time by producing a lot of reusable code to me. :bigyello:
and I can easily find the propperty's or Methods I need without reading complete manuals.
Maybe I still remember writing assembly, and programs hanging together with goto's.
And OO is a means to a purpose not a purpose on it self... just like normalising databases is.:wave:
Well I don't know it sounded like you were doing the same. I thought that's how you all talked to each other here?:rolleyes:Quote:
Originally Posted by RhinoBull
OOP is just one tool in the architects toolbox. Granted it can be over used, and quite often by those who have no sense about when and where it is good, and when it is not.
However, the accomplished analyst will pick it from a far wider palette of design architectures based on the job at hand.
The overriding problem is that there are far too many incompetent developers out there who don't deserve the name.
That being said, I think the shift towards multi core/processor systems will soon bring about a paradigm shift towards a newer design pattern that overcomes some of the problems OOP has in this kind of environment. But again, this will just add another tool to the box.
But reusable code could be produced without any OOP at all. Not that I am aginst OOP - it's just a matter of fact that OOP isn't necessary in this case.Quote:
Originally Posted by Dnereb
I like that quote... :)Quote:
Originally Posted by Dnereb
This may be a bit old for some of the folks here, but to summarize PG, he is opposed to Small Talk.
Even .NET has a core capacity for pseudo non-OO code in the module. Since a module is a shared class, it actually is OO, but you can simply ignore that unimportant fact if you want to. Considering that the head of VB7 (.NET2002) would agree with all PG has said, perhaps that is why this feature is in there. That project manager told me that OO can be horribly abused, and has led to some terrible spaghetti in the past (and I love spaghetti....just not in my code), and he was reluctant to give it any support. Personally, I use objects when they make sense, and don't use them when they don't. I've only used inheritance one time, so far.