Object oriented programming is the best way to develop softwares?
-
Recently I worked on a quite large C library and a C++ GUI application that uses this library. I realized that C is very easy to program and the program which we created was very straightforward without many indirections. The C++ application was also not using object oriented techniques heavily. It uses templates a lot and classes are created only when a state needs to be maintained. I also found it easy to make changes than a C#/Java application which has many layers and a lot of abstractions. So, what advantage OO programming style gives us? IMO, it is adding more complexities to the application and making the maintenance tough. I think, most of the OO applications that I saw was over engineered. I'd be interested to hear your thoughts on the above and the S/W development methods that worked well for you.
Best wishes, Navaneeth
Hi, OO is a concept you can use to your advantage. However what you do with OO you could also do without OO, although it may be harder without. The best example is the Visual Designer in Visual Studio, which allows you to build a Controls hierarchy for your GUI, simply by clicking and dragging. The main problem with OO seems to be people overcomplicate things; not using the simplest architecture that solves the problem is a common mistake (it does not require OO to do that, but it seems to help :laugh: ) :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
-
Recently I worked on a quite large C library and a C++ GUI application that uses this library. I realized that C is very easy to program and the program which we created was very straightforward without many indirections. The C++ application was also not using object oriented techniques heavily. It uses templates a lot and classes are created only when a state needs to be maintained. I also found it easy to make changes than a C#/Java application which has many layers and a lot of abstractions. So, what advantage OO programming style gives us? IMO, it is adding more complexities to the application and making the maintenance tough. I think, most of the OO applications that I saw was over engineered. I'd be interested to hear your thoughts on the above and the S/W development methods that worked well for you.
Best wishes, Navaneeth
My answer would be "it depends". I like the ideas of OO Design: encapsulation, polymorphism, etc. Encapsulation helps manage complexity. Polymorphism helps you to call the correct method based on passed types. Inheritance almost always results in a mess . Inheritance is that holy grail promising to allow massive amounts of code reuse. But it has been my experience that it only really works for simple objects. Can anyone really cite an example of application class libraries being re-used in a corporate world - across applications? I'm not talking about control classes or generic OS wrappers. I have never seen project B grab last year's project A classes and inherit anything. The application domain is just too specific.
Charlie Gilley You're going to tell me what I want to know, or I'm going to beat you to death in your own house. "Where liberty dwells, there is my country." B. Franklin, 1783
-
It is hard to demonstrate the advantage of OO over procedural programming in a simple example - because OO is mostly about dealing with the not-so-simple. The Complexity of programs is ever-increasing with the expectations of the users. It's a deadly cycle: We are always pushing the limits of what we can do, and then we have users that say "Uh, nice. Now can you make these two spin together?" The core concept to dealing with this is encapsulating complexity. That means any entity - be it a function, a class or a library - should be simpler on the outside than the inside. Sounds trivial, I know, but still to many classes are written that just decorate the complexity of the implementation with well-known patterns. This is the core requirement to make building things possible: We create a Foo, then we create a list of Foo's, then we put two of them side by side and let the user move Foo's around. When implementing the "move Foo to the left" code, we better don't have to deal with Foo's internal caching of network ressources0). This "making it simpler" is often described as invariants - guarantees made by the entity. No matter what you throw at them, that
maxfunction will always return the larger value. A function can make guarantees only about its parameters and about global state. Parameters are often just not enough1), and global state doesn't make it easy to build e.g. List of Foo's. In that sense, objects allow to encapsulate not only functionality, but also state, and they use a syntax that couples functionality to the state it manipulates2). So indeed, if you have little overall complexity, or just little data, a straightforward program will be simpler, and OO might just try to solve the more general problem you are not interested in. One rule of thumb was: procedural programs are maintainable up to around 10K lines of code, OO pushes that limit to 100K. Now languages and techniques have changed, so these numbers have, too. But the relation will roughly remain the same. 0) That encapsulate-and-build-on-top is never perfect, though. Joel describes that as leaky abstractions[^]. 1) From this POV, functional progrsamming just says "Parameters are enough, dear". 2) You can simulate OO techniques with plain old C: the data is hidden between handlpeterchen wrote:
because OO is mostly about dealing with the not-so-simple.
In many real world programs OO is making simple things more complicated, although the original intention is exactly the opposite.
My .NET Business Application Framework My Home Page My Younger Son & His "PET"
modified on Sunday, December 20, 2009 2:15 PM
-
Hi, OO is a concept you can use to your advantage. However what you do with OO you could also do without OO, although it may be harder without. The best example is the Visual Designer in Visual Studio, which allows you to build a Controls hierarchy for your GUI, simply by clicking and dragging. The main problem with OO seems to be people overcomplicate things; not using the simplest architecture that solves the problem is a common mistake (it does not require OO to do that, but it seems to help :laugh: ) :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Agree with you 100%.
My .NET Business Application Framework My Home Page My Younger Son & His "PET"
-
Recently I worked on a quite large C library and a C++ GUI application that uses this library. I realized that C is very easy to program and the program which we created was very straightforward without many indirections. The C++ application was also not using object oriented techniques heavily. It uses templates a lot and classes are created only when a state needs to be maintained. I also found it easy to make changes than a C#/Java application which has many layers and a lot of abstractions. So, what advantage OO programming style gives us? IMO, it is adding more complexities to the application and making the maintenance tough. I think, most of the OO applications that I saw was over engineered. I'd be interested to hear your thoughts on the above and the S/W development methods that worked well for you.
Best wishes, Navaneeth
Depends on what you are doing, really. The best use of OO hierarchies I know of is for desktop GUI libraries (Qt, WPF, etc...).
N a v a n e e t h wrote:
I think, most of the OO applications that I saw was over engineered.
I agree here. OOP does encourage overengineering, IMHO. Think of design patterns X|
-
Recently I worked on a quite large C library and a C++ GUI application that uses this library. I realized that C is very easy to program and the program which we created was very straightforward without many indirections. The C++ application was also not using object oriented techniques heavily. It uses templates a lot and classes are created only when a state needs to be maintained. I also found it easy to make changes than a C#/Java application which has many layers and a lot of abstractions. So, what advantage OO programming style gives us? IMO, it is adding more complexities to the application and making the maintenance tough. I think, most of the OO applications that I saw was over engineered. I'd be interested to hear your thoughts on the above and the S/W development methods that worked well for you.
Best wishes, Navaneeth
A few stray thoughts about this very interesting topic. 1. My cars tires do not inherit from "roundness," but they do rotate, inflate, deflate, and sometimes deflate very quickly; inflation and deflation could be, arguably, defined as "processes," with "having a blow out" seen as a special case of the process of deflation. Or is a "blow-out" a unique "event" ? Are processes a continuum, or do they have "granularity;" or do they have a hierarchy of levels at which you can, usefully, "divide" them into unique events ? Uh-oh : what is a "unique event" : is it a ranking on a probability scale of some type, some kind of bell-curve ? The car object is "constrained" to "have" tires only if you want the car to be "in the state" known as "moving without damage." The laws of physics constrain the car's entry into the "state of motion," and the principle of "entropy" suggests the car will cease motion at some point of equilibrium of forces in the absence of mechanical impetus. This state of "motion" constrained to be for almost all (but not all ?) cars never at 90 degree angles to the long axis of the car body. I use this deliberately stupid (what is someone who is being "deliberately stupid; ? : answer : "deliberately stupid" : that's recursive : did you notice you read that more than once ?) metaphor to express a "gut-level feeling" that so much of what we are dealing with in software now are events (often asynchronous) and interactions : processes and flows, transitions between states : grant me please the boon of allowing me to lump these temporarily into one plastic tupperware container I'll call "behaviors." Let me ask you : does O-O or o-o give you a rich palette for modeling and expressing events, behaviors, processes, flows, interactions ? I'm not sure. It's interesting to me that "design patterns" most often have noun-based names like "Visitor," "Observer." What does that mean ? Are "design patterns" closer to a modelling language for "behaviors" : I don't know. Remember "state machines" ? What is about them that they are seldom used ? Decision Tables to model very complex interactions of boolean conditions (inputs, rules) and resulting states (outputs, outcomes) : Why do they not rule the roost ? There was a lot of computer science research done (a long time ago, okay) that suggested that complex logical branching (nested if/else's, if you will) was where programmers tended to make big mistakes. Does C# and/or Visual Studio provide you with rich tools for programming very complex interactions of r
-
Recently I worked on a quite large C library and a C++ GUI application that uses this library. I realized that C is very easy to program and the program which we created was very straightforward without many indirections. The C++ application was also not using object oriented techniques heavily. It uses templates a lot and classes are created only when a state needs to be maintained. I also found it easy to make changes than a C#/Java application which has many layers and a lot of abstractions. So, what advantage OO programming style gives us? IMO, it is adding more complexities to the application and making the maintenance tough. I think, most of the OO applications that I saw was over engineered. I'd be interested to hear your thoughts on the above and the S/W development methods that worked well for you.
Best wishes, Navaneeth
N a v a n e e t h wrote:
IMO, it is adding more complexities to the application and making the maintenance tough. I think, most of the OO applications that I saw was over engineered.
I pretty much agree with you. About the only thing I use OO for is encapsulation, sometimes polymorphism, and rarely inheritance.
N a v a n e e t h wrote:
I'd be interested to hear your thoughts on the above and the S/W development methods that worked well for you.
Nowadays, I de-emphasize the structure of the application, opting for a fairly unstructured, loosely coupled collection of components, and I emphasize instead communication, multitasking, and ease of working with the building blocks. Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
Assembly is my "native" language, being the first I learned to love (though I had to write the assembler first). There aren't a whole lot of objects in that language, and I managed to get a lot done with it, so I have to agree that OOP isn't for every job. Nearly all of my profesional programming experience is in procedural languages and styles, and that never stopped me from getting the job done. We didn't need no stinkin' objects then. But times change... I do happen to like the OOP paradigm, though - it just makes sense. As you say, most OOP solutions are over-engineered. There's a reason for that, I think. OOP makes a designer think about reusability; encapsulation and polymorphism lend an object to reuse, so a designer tends to think early in the project about what other applications a class might be useful for, and designs accordingly. That appeals to the engineer I am; it's an "elegant" solution, so to speak. I know that much of what is written is crap, and has to be redone to make it usable in new applications, but at least the designer usually puts a bit of thought into it and tries. All in all, I think OOP is here to stay, and I'm a fan. I'm currenly trying to learn C#, and I find it very limiting to have to create a class in order to make a simple file filled with utility functions that should properly be global routines without regard to membership in a class, but I can live with that. The advantages, in this case, seem to outweigh the minor inconveniences. Sometimes I wish that I could have Pascal back again - it was the last, and best language I ever truly mastered - but that's a futile wish. Whether we like it or not, the software world is now an OOP world. You can choose to embrace it and make your life a bit simpler, or to fight it and make life difficult. There are ways to get around the restrictions if you want to, of course... :-D
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Roger Wright wrote:
Sometimes I wish that I could have Pascal back again - it was the last, and best language I ever truly mastered - but that's a futile wish. Whether we like it or not, the software world is now an OOP world.
Delphi is Turbo Pascal (which has been object orientated since the 80s). It's still going strong, at least in the ISV community.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
Roger Wright wrote:
Sometimes I wish that I could have Pascal back again - it was the last, and best language I ever truly mastered - but that's a futile wish. Whether we like it or not, the software world is now an OOP world.
Delphi is Turbo Pascal (which has been object orientated since the 80s). It's still going strong, at least in the ISV community.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
I'd heard that, but haven't checked into Delphi. The first OOP version of Turbo Pascal was 5.5 - I bought 5 in about '92 or '93, and it shipped with an addendum - version 5.5! It even had manuals! And I still have the manuals, though I think I chucked the 5 1/4" floppies a couple of years ago. Great product for its day - it even included Turbo Assembler and a debugger (I think it was called DDE). :-D
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
I'd heard that, but haven't checked into Delphi. The first OOP version of Turbo Pascal was 5.5 - I bought 5 in about '92 or '93, and it shipped with an addendum - version 5.5! It even had manuals! And I still have the manuals, though I think I chucked the 5 1/4" floppies a couple of years ago. Great product for its day - it even included Turbo Assembler and a debugger (I think it was called DDE). :-D
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
I used to use Turbo Pascal 5.5 myself, and it was a quite astonishingly good compiler for the time. :)
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
