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
"Use the right tool for the right job." -- Scotty et al I did ANSI C for most of my career (so far). And only dabbled in C++ a little bit. Object oriented programming fits very few situations I have come across. The most complex thing I needed in C was pointers to functions, and that only in one application.
-
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
OO is a tool. Use it like a tool and treat it with proper respect. It's not a miracle solution, and obviously not appropriate for every problem.
N a v a n e e t h wrote:
most of the OO applications that I saw was over engineered.
In my opinion that's not OO's fault, that's people who don't know what the hell they are doing. Have them design an app with templates, or procedural only solutions, and you'd end up with a similar mess. Writing good software is hard. End of story.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
OO is a tool. Use it like a tool and treat it with proper respect. It's not a miracle solution, and obviously not appropriate for every problem.
N a v a n e e t h wrote:
most of the OO applications that I saw was over engineered.
In my opinion that's not OO's fault, that's people who don't know what the hell they are doing. Have them design an app with templates, or procedural only solutions, and you'd end up with a similar mess. Writing good software is hard. End of story.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
Jim Crafton wrote:
OO is a tool
:laugh: :laugh: Right, I know what you actually meant, but I had a good laugh.
“Follow your bliss.” – Joseph Campbell
-
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
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"
-
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
I think OO makes a lot of sense, but I'd agree that to a man with a hammer, everyting looks like a nail. In other words, people will tend towards OO solutions because that's how we are trained to think by the use of OO languages.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
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
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 handl -
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 handlAnd then Peter spake : "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?" That's very eloquently, said, Peter, thanks. imho a lot of that increasing complexity has to with the compounding effect of adding new layers of abstraction and functionality over badly engineered sub-structure, often to bypass badly designed features, or work-around known bugs : it's why I call a lot of what real-world programmers actually do "dinosaur dentistry." imho the "slash and burn" "feature-race driven" rush for dominance of giant cartels results in mutant chimeras like Blend as temporary fixes. How many hours of your life have you wasted doing work-arounds for the long-documented flaws of many of the basic WinForms controls ? But no, why make those "world class" when you can rush forward to the "Brave New World" of WPF, no matter programmers have to revert to directly writing XAML which, imho, is one step above assembly language. Go ahead : WPF Disciples : have me burned at the stake :) And yes, give us three dimensions before there's even a good retained mode 2d graphics structure in place with proper font sub-pixel voodoo. Keep layering stuff on top of DirectX until ... ? No, don't fix the software : buy a faster GPU ! When the latest version of the most modern widely used operating system in the world, doesn't bother to maintain the previous state (like the order the column headings are in) of the configuration of something as basic as the OpenFileDialog ... I've eaten enough dog-food, and been a dog-food factory long enough, to have the right to howl :) best, Bill p.s. the above opinions and sentiments are reasons I was glad to hear MS is going to do another CTP of VS 2010 !
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
modified on Saturday, December 19, 2009 6:24 AM
-
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
One of the places that OO makes things easier to understand is when you have case statements that do different things based on the struct you are dealing with. The classic example is drawing graphics. You framework may have 'drawRect', 'drawLine', drawCirc' functions called based on a 'type' field in the structure. In OO they would all inherit from a graphic object that defines 'draw', and rect, line and circ, and do what they need to. The frame work just calls draw. Of course, not all programs need it.
Opacity, the new Transparency.
-
And then Peter spake : "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?" That's very eloquently, said, Peter, thanks. imho a lot of that increasing complexity has to with the compounding effect of adding new layers of abstraction and functionality over badly engineered sub-structure, often to bypass badly designed features, or work-around known bugs : it's why I call a lot of what real-world programmers actually do "dinosaur dentistry." imho the "slash and burn" "feature-race driven" rush for dominance of giant cartels results in mutant chimeras like Blend as temporary fixes. How many hours of your life have you wasted doing work-arounds for the long-documented flaws of many of the basic WinForms controls ? But no, why make those "world class" when you can rush forward to the "Brave New World" of WPF, no matter programmers have to revert to directly writing XAML which, imho, is one step above assembly language. Go ahead : WPF Disciples : have me burned at the stake :) And yes, give us three dimensions before there's even a good retained mode 2d graphics structure in place with proper font sub-pixel voodoo. Keep layering stuff on top of DirectX until ... ? No, don't fix the software : buy a faster GPU ! When the latest version of the most modern widely used operating system in the world, doesn't bother to maintain the previous state (like the order the column headings are in) of the configuration of something as basic as the OpenFileDialog ... I've eaten enough dog-food, and been a dog-food factory long enough, to have the right to howl :) best, Bill p.s. the above opinions and sentiments are reasons I was glad to hear MS is going to do another CTP of VS 2010 !
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
modified on Saturday, December 19, 2009 6:24 AM
I take that as an invitation to dig deeper ;) I am developing these thoughts as i write them, it might be a bit inconsistent... I think it pays to classify complexity here. Citing from different sources, I'd do it as such: Problem Complexity The complexity inherently involved in the task to solve. Solution Complexity The complexity required to solve the problem. Note that they are not necessarily equal. I'd split it up further into Required Solution Complexity - the complexity you need to deal with to solve the core problem. Like a phycisist chooses a suitable coordinate system that simplifies calculations, like a mathematician proves equivalence to a known and "trivially" solved problem, we can, through proper design and algorithms, make our lifes easier. However, the original problem complexity will remain. Accidental Solution Complexity - the complexity we add in our solution, though it is not necessarily required. I guess that's where all the layers of abstraction and redirection fit in. In my understanding, this is not entirely unnecessary: It doesn't help solve the problem, but it helps the solution solve the problem. Like the glue keeping our solution together. But we should treat it as that: glue, means to an end, accidental, not as the holy grail that these things are made to be. Interaction complexity - A simple example: copying files. Let's say, I figure out a way to make reads and writes over an ethernet cable, so we can use the copy file mechanism on the network. Nice! In the meantime, you figure out that users have become very impatient and really start to hate our error messages, so we better should properly lock files, and reserve the required space on the target before we srart to copy. Nice! But now we put this together, suddenly we have to lock files and reserve disk space through a network, something my solution never considered. I don't know where to really fit this in. It could be labeled "problem complexity" (after all, proper locking changed the definition of "copy files"), or solution complexity (abstracting the network requires more than just reads and writes). It's also why I mentioned Joels Leaky Abstraction - we need to look out for these things, they take us (or at least me) by surprise.
BillWoodruff wrote:
imho the "slash and burn" "feature-race driven" rush for dominance of giant cartels results in mutant chimeras like Blend as temporary f
-
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:
So, what advantage OO programming style gives us?
A way to organize large lumps of code in a reusable fashion.
N a v a n e e t h wrote:
IMO, it is adding more complexities to the application and making the maintenance tough.
Yup, in the similar way that using the EF in a small todo-list application would be overkill. The method isn't adding complexity, it's rather a complex method for complex circumstances.
N a v a n e e t h wrote:
I think, most of the OO applications that I saw was over engineered.
It's not a binding choice, and it's not forbidden to write batch-files once you learnt Object Orientation. I agree with you that OO is being "preached" too much. It has been coined as a reason why Johnny can't code[^].
N a v a n e e t h wrote:
and the S/W development methods that worked well for you.
Like Lincoln, I'll be sharpening the axe for hours. No set of rules, guidelines or best practices can replace old-fashioned thinking.
I are Troll :suss:
-
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?"
