Forgot your password?
typodupeerror
Programming IT Technology

Can OO Programming Solve Engineering Problems? 621

Posted by Cliff
from the stuff-to-think-about dept.
ThChalm asks: "I am the first one to admit that my programming experience is somewhat limited. The majority of it has been obtained writing FORTRAN code to solve problems in mechanical engineering. I have written some smaller (you might say toy) codes using C. I have read a lot of books on C++ (and OOP), but always get frustrated with the following question: Why can't anyone show me an engineering application that is solved with an object oriented program?"

"I appreciate the concepts of OOP and see its applicability in managing records, GUIs, and possibly standard function libraries. I cannot, however, convince myself that there is a clean way to use these concepts to solve the type of procedural problems that I have encountered in the past (finite difference solutions to differential equations, finite-volume computational fluid dynamics, iterative solutions to non-linear equations, Monte-Carlo simulation of radiative heat transfer, etc.)

Am I just being close minded to the ideas of OOP or do my problems just require 'procedural' solutions, which are better solved using procedural techniques? I'll even be happy with the answer 'Your problems are two small and specialized to realize any significant advantages of OOP.'

I'd be interested in hearing comments from anyone else who has this problem, anyone who has worked through it, or anyone who can send me an example of an engineering application of C++ and OOP."

This discussion has been archived. No new comments can be posted.

Can OO Programming Solve Engineering Problems?

Comments Filter:
  • by Anonymous Coward on Thursday January 03, 2002 @11:34AM (#2779216)
    Your problems are too small and specialized to realize any significant advantages of OOP.
    • The comment got modded up to funny, but it's dead on the mark. OO Programming is about O (Objects). When designing a program, first determine the objects in your domain. The stuff you specifically mentioned are not objects. If you can't find any objects in your domain, then don't go the OO route.

      Here's an example: Airfoil design. The object in the domain is the airfoil (and probably composed of other objects like surfaces, sections, etc). The actual equations used are not the object, they are what you do with the object. So when you talk about finite difference solutions, fluid dynamics, and iterative solutions, you aren't talking about objects, but what you can do WITH objects.

      Even if OO doesn't fit your domain, take a look at the STL and Generic Programming in general. There's some useful stuff in there for your needs.
  • OOP (Score:2, Informative)

    by ParamonKreel (182921)
    It's not that you can solve problems in OOP that you can't solve in Procedural (Fortran/C like), it's just that for many problems, OOP is much faster, allowing you to re-use much code to deal with things in a similar way when they can be and use the specifics only when needed.
    • Re:OOP (Score:2, Interesting)

      by Kamel Jockey (409856)

      OOP is much faster, allowing you to re-use much code to deal with things in a similar way when they can be and use the specifics only when needed.

      OOP tends to produce very bloated machine code though. In some mission critical real time systems, or on embedded systems in which there are siginificant resource limits, this may not be a good programming tactic. Yes, it reduces development time, but it tends to increase execution time.

      But its sure saved my ass on numerous occaisions! Because of OOP, many of my non-trivial programs "practically write themselves!"

      • Re:OOP (Score:3, Insightful)

        by kevin42 (161303)
        That has been true in the past, but with modern compilers (like gcc) you will get very similar code and only a slight increase in overhead (vtables) with C++ over C. Lots of people are using C++ in small embedded systems now.

        Real bloat comes from libraries like STL...
        • Re:OOP (Score:2, Funny)

          by madmaxx (32372)
          lol ... from fud surrounding one topic to another. the STL is no more bloated than my mother-in-law. err, hmmm ... wait ... no more bloated than a canned ham. what do you mean by bloat anyway? unqualified mud-slinging is no where near as fun.
          • I guess I should have put a smiley face on that last comment, because I meant it as a sort of troll.

            I have nothing against STL in general, but some compilers have had problems which caused the use of STL to make your program very very large. By bloat I mean large. But I use STL when I need it and again with a good compiler it's not a problem.
      • There are many instances where C++ can actually produce faster code.

        For a simple example, compare the C qsort with a C++ template Quicksort function. In the C++ version, the comparison operator would likely be compiled inline to the function, meaning that you don't get the overhead of a function call for every comparison. In C the only way you could do this would to be to write quicksort yourself for every data type that needs it. C++ templates allow a lot of work to be done at compile time, rather than at runtime.

        Check out http://www.oonumerics.org/blitz/ [oonumerics.org] for fast C++ scientific applications.

        cheers,

        Tim
  • by Arctic Fox (105204) on Thursday January 03, 2002 @11:37AM (#2779231) Homepage Journal
    Most engineers have been taught that FORTRAN is the way to solve problems in engineering. If everyone starts out with that prejudice and is stuck there.
    Where I work, there is a project to write an engineering application in VB, and it has seemed to be one problem after another after another. (I know i know, VB is crap). The core library functions are in C, in a DLL, so I guess thats a bit of a start.
    FORTRAN has been ingrained into the current working generations of engineers, so they're going to use what they know.
    Heck, I've even seen SQLPlus code (from Aspen) written very very very FORTRAN like. Instead of using min(), max(), there was a bunch of select looping and checking variables..... Oy.
    • You're confusing programming language with design concepts. The question is not "is Fortran better for engineering problems than C++?" but rather "can OO design and development be applied well to engineering problems?"

    • Most engineers have been taught that FORTRAN is the way to solve problems in engineering. If everyone starts out with that prejudice and is stuck there.

      Engineering problems are generally solved by iterating through a set of equations (sometimes hundreds of them). Iteration is the only way known to solve these problems. While you could rewrite your iteration into recursion, you would probably be filling up massive amounts of memory uselessly.

      Actually, you should take a look at the compilers that are out there. If you write some code in FORTRAN with any decent compiler then the compiler will generally do some very nice things for you (like automatic parallelization). Engineering code is often very parallelizable. And when you compare the wall clock time for a FORTRAN engineering program and a C engineering program generally the FORTRAN will work better because the compiler knows very well how to handle the FORmula TRANslation in FORTRAN.

      In summary, it is not a "prejudice," it is a knowledge of the best tool for the job. Your broad statement of "VB is crap" may generally be true, but you should remember that it is an available tool and that for some things (needing a hack that can solve a small windows problem quickly) it is the best tool for the job.

      Engineers' goals are generally to use the best tool at their disposal for the task at hand.

      I speak from experience working with Molecular Modeling as a Chemical Engineer. On my most recent project, I used FORTRAN, Perl, and Matlab (yes that is a programming language not just a program). Each tool is the best at what it does for its purpose.
  • OOP (Score:2, Interesting)

    by Ashcrow (469400)
    In my opinion, OOP is only good in large scale yet generic problems. I've seen many people do C/C++ combonations where they filled in C++ gaps with their own C code.

    Maybe another way to look at it is to use what you know. It seems like a good amount of engineering students use fortran or pascel to do their engineering work in. As a computer science guy I hardly ever see fortran or pascel when doing my work (school or job), but it boils down to the fact that it works and thats whats important.
  • Complex Question... (Score:5, Interesting)

    by Marx_Mrvelous (532372) on Thursday January 03, 2002 @11:38AM (#2779242) Homepage
    This is a really difficult question to answer. I guess my reply would be that no, pure "OO" programming wouldn't hold any advantage to simple procedural programming in this case. However, you can easily add procedures to objects, so OO language is really just a superset of procedural.

    Personally, I like the organizational potential of OO. You can have a Pipe object, and call function like Pipe.calculateFlowrate(12,43,23), then you could have a subclass SquarePipe, and call the function SquarePipe.calculateFlowrate(12,12,43,23).
    Essentially, you could have 10 objects each with 10 functions to do 100 different tasks, rather than 100 different functions to do 100 different tasks.
    • by taliver (174409)
      However, you still end up writting 100 different functions in either case, and calling

      squarepipe.calculateFlowrate

      seems no easier to remember than

      squarePipe_CalculateFlowRate()

      or

      CalculateFlowrate(SQUAREPIPE,...)

      Also, if you have generic functions across all classes, you are left with a bizarre model of pipes, bowls, steam generators, and anything else having to be under some umbrella so you can attach a "SurfaceArea" or "Volume" calculator or some other generic routine.

      I've also never been a big believer of the whole "code-reuse" argument. The biggest code-reuse in practce is all done in C, and very non-OO -- libc.

      Unless you already have a big simulator witten in OO style, and you need a simulator, I'm not sure of the use of OOP. If you are trying to do a large calculation, then the time you spend in trying to stick to the OOP mindset doesn't seem like it will ever pay off.
      • by piggy (5857) on Thursday January 03, 2002 @12:35PM (#2779689) Homepage
        However, you still end up writting 100 different functions in either case, and calling


        squarepipe.calculateFlowrate

        seems no easier to remember than

        squarePipe_CalculateFlowRate()

        or

        CalculateFlowrate(SQUAREPIPE,...)
        But this is easier if you don't know the pipe type before runtime, or the type could change:

        PipeType * theTypeOfPipeAsParameter;
        FlowRateParams * flowrateparams;
        Pipe * thePipe;
        [[thePipe alloc] initPipeWithType:theTypeOfPipeAsParameter];
        flowrate = [thePipe calculateFlowrate:flowrateparams];

        That is, you are correct unless you dynamically create pipes of different kinds at runtime, perhaps using an abstract factory (for example, an interactive simulation which allows the engineer to manipulate the objects) or, at a more basic level, have need to send the same message to a collection of disparate pipes (for example, compare the simplicity of the design and code to send the same "calculateFlowrate" message to each object in an array in a polymorphic OO language versus a procedural language).

        My point is that, perhaps the implementation of the calculation cannot easily be made OO, but access to that calculation can often benefit from an OO wrapper.

        Just off the top of my head. At work, we are attempting to apply OO to requirements analysis, while still persisting in the "object-based" world of Ada development. (This means that I don't have any real world, OO engineering implementation examples).

        Russell Ahrens

      • You wrote:
        squarepipe.calculateFlowrate
        seems no easier to remember than
        squarePipe_CalculateFlowRate()
        or
        CalculateFlowrate(SQUAREPIPE,...)
        Also, if you have generic functions across all classes, you are left with a bizarre model of pipes, bowls, steam generators, and anything else having to be under some umbrella so you can attach a "SurfaceArea" or "Volume" calculator or some other generic routine.

        Well and what about this:
        // I don't know if you use square pipes
        // or round pipes ...
        // or oval pipes ...
        calcTotalFlowRate(Array_of_Pipe* pipe) {
        double sum = 0;
        for (int i=0; i leth_than pipe.length; i++) {
        sum += pipe[i].calculateFlowRate();
        }
        You wrote:
        I've also never been a big believer of the whole "code-reuse" argument.

        I say:
        Then write my above loop in C ... ignore the fact that I used a template ( angle brackets got stripped by the formatter :-( )of course ...

        For the problem you are bringing up: adding later a SurfaceArea calculation, OO is exactly THE solution.

        And if you are to tired to modify all classes where a calcSurface method would be needed write a Visitor. OOPS, thats a design pattern ... read: "Design Patterns", Elements of Reuseable Design, Gamma et al., Addison Wesley, 1995.

        Regards,
        angel'o'sphere
    • by STSeer (119553)
      "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. "

      Alan J. Perlis

      http://www.cs.yale.edu/homes/perlis-alan/quotes. ht ml
  • by Crimplene Prakman (82370) <prak AT iol DOT ie> on Thursday January 03, 2002 @11:39AM (#2779248) Journal

    There are a number of ways to approach this, but I've found the following useful:

    • if you're relating to physical objects e.g. sensors, displays, etc., then create an object
    • Algorithms, problem-solving functions, and procedures such as you're talking about, can then be added as methods to the objects you've created, or you can create new "virtual" or "calculator" objects to fit between the ins and outs, that expose your algorithms and procedures as methods before outputting them.

    It's more a matter of thinking in terms of telling your processes to do stuff than creating a road for them to walk down. If you know what I mean ;-)

    All your Qaeda are belong to US

    • by mblase (200735) on Thursday January 03, 2002 @11:52AM (#2779381)

      For simplicity's sake, let's think about quadratic equations for a second. You can solve them easily, but if you want to use them in a larger program, you could create a QuadEq object in OOP with the following properties:

      • coef_A, coef_B, and coef_C as the three coefficients
      • root_1 and root_2 as the two roots of the equation
      • deriv_1 and deriv_2 as the first and second derivatives of the equation

      An OO programmer would then add methods to set, retrieve, and calculate those properties based on what's been entered. And the QuadEq object would be entirely portable and easily amplified for future equations.

      I don't think choosing OOP is a matter of being the only tool to solve certain problems. However, it is often the most efficient way to solve large, rapidly-changing problems. But like you said, other problems (like many of the ones I encounter in web development) will be small and uncomplicated enough that the overhead of OOP isn't worth the trouble.

      • I'm sorry, but this is a classic example of bad OO, except in specific circumstances. A simple calculation is expanded into 6 method calls (3 x setCoefficient, 1 x calculate, 2 x getRoot), and even if compound methods are provided the side effects grossly impede calculation performance.

        An object can represent anything that has a state which changes over time, in response to input or other events in the software. If what you are modelling does not hold with the above definition, it shouldn't be an object.

        Discrete calculations are especially suited to NOT being objects. They have no requirement for persistent information outside the function, and thus no need to be in an object. The primary reason for putting them in an object is grouping, which is a Really Bad Idea for common library routines because you can't export C++ objects from libraries (unless you assume that the library user has the same compiler and linker as you do...).

        Fortunately C++ (unlike some other OO languages) has a solution to this problem: namespaces. Any function which is self-contained (has no need for non-local data) can be placed in a namespace, logically grouped with similar functions, and if the header is carefully constructed can still be used in libraries using C name "mangling".

        The only situation in which I can imagine the object you propose being useful is as a data object behind a GUI which allows you to enter quadratics and fills in the other fields. And even in this case I contend that the correct model would be a QuadraticModel object (like the one you describe) which calls calculateQuadraticRoots() in a namespace or other library.

      • Bad example? (Score:4, Interesting)

        by Anonymous Brave Guy (457657) on Thursday January 03, 2002 @02:46PM (#2780531)

        Sorry, but I think that's a bad example. Using an OO design has gained nothing over a simple function or two here, but has probably generated much more clutter as a result.

        If I dared propose a more appropriate example in a similar vein, one thing OO is quite good at is providing and working with a representation for complicated and interrelated data items, such as a mathematical expression. Suppose I'm writing a mathematical tool to process these. I will represent an expression as an object of type Expression. Subtypes of that might be ConstantExpression (representing a numeric constant, say 2 or e), AdditionExpression (representing a+b, where a and b are themselves Expressions), etc.

        Now I have a clear structure for representing these, I can parse whatever input I have into this format, and work with it. Need to display it using pretty graphics? No problem, add a Display() method to Expression's interface, and provide a suitable implementation for each subtype. Need to evaluate the expression? Eval(), here we come.

        So far, so good. You've used OO to provide a nice representation of a problem, at least as clearly as a procedural solution would have done. It's pretty much a draw so far, and a matter of personal preference which style you prefer.

        However, the OO framework is much more easily extensible than its procedural counterpart. You can add new subtypes of Expression, and have them immediately fit into your existing framework, without changing any of your existing code (or even having access to it, for that matter). To do this procedurally, you often wind up writing some clever switching logic, but OO does it all for you behind the scenes.

        It's also easier for the outside world to work with your code, because you can provide nice, clean interfaces, such that all Expressions look the same to the outside world, however they are composed.

        Finally, this approach helps organise your code. If all your types of Expression provide an Eval() interface, the implementation of that interface is in a known place, and probably quite straightforward for each subtype. This maintains a degree of clarity that is easily lost when you don't have the organisational framework an OO design supports.

  • by einer (459199) on Thursday January 03, 2002 @11:40AM (#2779257) Journal
    I'm not terribly familier with the problems you have presented (I.E. I know what a monte carlo alogorithm is, but not the radiative heat transfer part...), but it sounds to me like you're trying to fit the problem to the solution and not the other way around. OOP can be useful if you're trying to model something, or replicate the behavior behavior and characteristics of a real world problem, but it's not that great for say, solving a system of equations... I guess you can use whatever language or system you would like, but not many need C++ and the STL to evaluate expressions.
    • I would have to differ with you on this one. I took a CS class this semester that dealt with the advantages and disadvantages of using OO code to solve damped spring problems, ODE solvers, etc. Using template engines, the Barton-Nackman trick, and other less-than obvious tricks allow you to have most of the benefits of a pure OO system without the speed tradeoffs.
    • I disagree. C++ is intended to solve systems in the language of the domain - which is one of the central purposes of the language (see Design and Evolution of C++ by Stroustrup). Some of the strongest uses of C++ I've seen today are well abstracted matrix libraries for advanced signal processing (Blitz++) ... not too far from what the question is asking about.
    • OOP can be useful if you're trying to model something ... but it's not that great for say, solving a system of equations
      I don't know about you, but I see a mathematical model of processes or objects as a system of equations. How else do you describe them? If you are talking about sequences of events you should recall that those are also described by equations.

      I'm sure that OOP is useful in modelling, but more detail would be nice. Most people don't realise that the engineering problems solved on supercomputers are usually approximations, and increasing efficiency or available resources can improve those approximations. Even a mundane problem like the temperature distribution of someone jogging in wet trousers on a humid sunny day would need serious computing power, and there are a lot of problems more complex than that which can give useful results.

  • by mheine (303013) on Thursday January 03, 2002 @11:41AM (#2779270)
    All of the techniques you listed and most other engineering problems are expressed in a procedural format. In order to use OO you would have to transform the problem into an object problem. The things that OO does really well at are things where we already think in object terms. Like GUI widgets. Most engineering problems simply aren't expressed that way. Although most problems could be rephrased that way the algorithms would necessarily not be equivalent (better or worse would require experimentation)
  • If you're dealing with a problem that can be reduced to a mathematical formula or the like, you're probably better off looking in Numerical Recipes or the NAG libraries, or what have you.

    In this case, you're dealing with a well-defined, well-understood problem. You could implement a solution using OO principals, but why bother. I mean, you're not going to be changing it or adapting it all that much.

    The power of OO happens at a higher level, and with less-well understoof problems. In this case, you're modeling higher-level entities, with less well-understood properties that are much more liable to change. In this case, the ideas of modularity, pluggable behavious, cohesiveness, etc., become much more important.

    I hope that didn't sound too much like a hand-waving explanation.
    • Well, I wouldn't recommend Numerical Recipes. It lacks rigor [nasa.gov].

      I haven't looked at NAG, but you're not getting all the source code? Actually, I find it weird that one does rely on closed source in science, when science depends on the full disclosure of all relevant material. Well, the computations done is arguably the most important aspect of most analysis done today, so all source code should be available for public scrutiny.

      I would recommend R [r-project.org] for many applications. It has some lightweight OO that is very efficient, it's a really beautiful language. It is also very rigorous, you will find the best things in Numerical Recipes there, but there is also a lot of code that has been through formal peer review.

  • Code Reuse and extensibility is (IMHO) the largest advantage of OO. By (trying) to demark a dotted line around the box of code you want to (re)use and separating out your new code, you realize gains in writing and testing. Communicating what code actually does is also much cleaner in a componentized view.

    So take a look at many programs writting in Windows these days. Anything written that uses COM. Almost all *ix shell scripting. While they all follow different aspects of "object" reuse, you are benefitting from using a block of solid code without having to retest it. I'm abstracting the definition many people have of "object" as such, but in the end all the goals are similar: Get it done better, faster.

    mug
  • Some of the replies here are a little confused. To paraphrase The Princess Bride, the word does not mean what you think it does.

    Functional programs evaluate expressions rather than execute commands to "get stuff done". Scheme (which is derived from Lisp) is one of the more well known functional programming languages.
  • I would tend to agree that OOP might be the wrong solution. It seems to me that OOP is designed to generalize code to solve broad problems. Engineering, and other applications which require minute changes depending on multiple factors might be better served by procedural code designed to specifically handle those problems.

    An interesting point that is raised is the fact that OOP, while an enormously helpful tool to many programmers and despite its advantages in many other theaters of software design, does not have to be an end all be all for programming as a whole. The tool that works should be the tool that is used.

  • ...when the jury is still out on whether OOP can even solve computer science problems?

    Other than a small handful of examples, I haven't seen where OO helps any way other than the creation of arbitrary data types and convenient grouping of data and functionality which can be done, although less cleanly, in a procedural language as well. The complexities of inheritance and God forbid, polymorphism, usually lead to more problems than they solve, in my opinion.

    I agree that OO programming can be more programmer-friendly in some cases, but in general find it more trouble than it's worth. Sometimes it looks to me like most of the things that can be re-used have already been turned into libraries, and the rest is all custom programming.

    I confess to learning programming using procedural techniques and using them for a dozen years before picking up OOP, and still finding those techniques easier to apply. But I'm not the only one that questions whether OO is a big red herring to productivity.
  • by soboroff (91667) on Thursday January 03, 2002 @11:45AM (#2779311)
    OOP doesn't solve engineering problems of the kind you describe. The programs solve the problems.

    OOP is a way to think about structuring the program, how you organize data and operations on the data, how you build reusable components which you can apply in some future problem you need to write a program to solve. In other words, OO helps solve software engineering problems. You'll still need to write the program which solves your particular problem.

    And before the flames commence, yes, OO isn't the only solution to this class of problems. It's just one.
  • Here's a problem (Score:3, Interesting)

    by Henry V .009 (518000) on Thursday January 03, 2002 @11:46AM (#2779314) Journal
    How do you write a million lines of maintainable code in six months with 5 programmers in Silicon Valley and 50 in Turkey? Hint: You don't do it in C.
  • OO programming is not just about modeling the problem well, which in and of itself is enough to recommend the approach to an engineer. It also addresses the very difficult task of generating and maintaining a large software project in a form that a human can understand. For many small tasks, the extra overhead involved might not be worth the extra effort required if you are not already comfortable with the OO metaphor.
  • by CaptainAlbert (162776) on Thursday January 03, 2002 @11:46AM (#2779319) Homepage
    Take a look at BLITZ++ [oonumerics.org], then tell me OOP is not useful for scientists and engineers. :-)

    I think the safest thing to say is that whatever your programming needs, whether you're doing pure matrix/BLAS number crunching or writing complex simulations/models, you should think twice before using FORTRAN. Well-written code in, say, C++ will be more maintainable and accessible to other people you work with (and who have to touch your code in future).

    The only thing which keeps people using FORTAN that I've seen is that the optimising compiler support is fantastic compared with the equivalent offerings in C/C++ compilers. But that's not much of an excuse for general day to day problem-solving.

    Just my 2p.
  • Good reference (Score:2, Interesting)

    by Anonymous Coward
    Read the following book:

    Object-Oriented Implementation of Numerical Methods: An Introduction with Java & Smalltalk
    by Didier H. Besset
  • by WimBo (124634)
    One of the items I've run into is that FORTRAN natively supports complex numbers. C doesn't support them, and I need to use the Standard template library in C++ to get the support.

    After I've used the STL, I then don't have the huge library of old code that I can draw from in FORTRAN.

    I much prefer writing in C / C++ to writing in FORTRAN, but there's lots of legacy FORTRAN code out there that'll get reused.
  • by srealm (157581) <prez AT goth DOT net> on Thursday January 03, 2002 @11:47AM (#2779326) Homepage
    When you get down to it, every application, at some level, is a database of some kind. ie. it will end up storing many records of the same or similar type, usually in memory, and then go and do actions on those records. Weather each 'record' is a data packet, plugins for your application, records from some kind of file, whatever. In the end, it all acts a little like an in-memory database.

    The traditional way to handle this kind of thing is with a linked-list or array of structures. The main thing OOP gives you is not any 'special' solution to old procedural programs -- infact, a good blend of procedural and OOP is always the best solution, because every program is a combination of both. However, what OOP does give you is a nice way to encapsulate all data that is relevent, instead of into a structure, into a complete package.

    Instead of calling functions, and passing that object around, and then worrying about lost pointers, NULL's, etc. You take the more logical course of action, and perform the action directly ON the object. ie. instead of doing: do_something(mystruct, ....) you would just do mystruct.do_something(...). Which when you think about it, is a more logical solution. Almost every function you write, except for the straight out code-flow, and accessor functions, is some kind of operation on a data record in your 'in-memory database' (however it is represented). OOP's main purpose is to more link the functions doing stuff to the data, and the data itself. Nothing more, nothing less.

    Things like inheritance, templates, polymorphism, etc, are all just fluff to make coding easier, that has been added on top of the OO ideal. Granted, they make life ALOT easier (dont get me wrong, I use all of them all the time, and I'm an OO junkie), but the main purpose of OO is simply to create logical units, including code, and data in one block. So instead of having a bunch of structures, and then all functions to act on that structure in one .c file, and you know they're all related to that structure because they're in that particular .c file, you instead put all the functions in a class, and you know the funcitons work on that data, because the data, and function, are all part of the same logical unit.

    So I think you've mistaken the benefit of OO. As I said before, OO is not some kind of magical wand that will solve even the most complex of computing programming problems easily ... its just a cleaner way to group together data and functions that work on that data in a more 'binding' fashion, something that had to be done by the coder's memory and by hoping the previous coder's comments were good enough to make it clear what goes with what.
    • OO as a way of thinking can be done in any language. What an OO *language* can offer is really two things that C can't, recovery of the "this" pointer and late binding.

      Recovery of the "this" pointer means that any function will magically have a pointer to the object it is working on available. Now normally this doesn't matter much because you can just have the function take itself as an argument (or a magically cast-to-void "handle" if you want to be opaque about it). But when you start to have inheritance, it can be tricky for the calling function to figure out what pointer to use. The OO language will do this for you.

      Late binding means you can link at runtime, not compile time. C++ offers this recovery but not late binding. Java and COM offer both.

      The rest is mostly OO hype. The big argument about how you can encapsulate everything inside a function is bogus because then you just convert it into a documentation issue, of knowing what exact random thing the designer of the function has decided it is appropriate to do. This is no different in OO or non-OO.

      The best, really the only successful realization of the OO dream of small interconnectable pieces so far is the Unix command line tools with pipes between them. Sure the data exchange format is trivial and limited, but the system actually works, and users can easily join together small reusable pieces of code to accomplish (most of) what they desire. The fact that this system is 30 years old and has not been improved upon just shows that <insert cliche here>.

      - adam

    • One day, grasshopper, you too shall understand.

      You seem to have grasped one of the central concepts of OO, and a fraction of its usefulness. You have yet to come to terms with its real worth, or the Greater Picture.

      To a limited extent OO is the "reverse" of passing around a data structure. It is convenient, and to most people more logical. But most importantly it offers something that non-OO languages cannot provide: compile time type safety and encapsulation.

      The and is really important, because a non-OO language can offer either, but not both. This means than a function can never be entirely sure that its data is in a consistent or expected state, which an object can.

      Aside: to provide compile-time safety to must declare the entire data structure, and not do any type-casting. But to provide for encapsulation you must hide the data structure, so that a developer cannot at compile time reference any member of the structure by name (i.e. can't screw with the data without making assumptions about offsets that equate to hacking, and will not remain true if the data structure changes). Doing both is not possible without additional code in the function to calculate and check some sort of checksum of the data structure; and that does not provide for compile-time error checking.

      This may not seem important, but it greatly reduces bugs. You can code and debug a library of objects, happy in the knowledge that no other part of the program can screw with the objects' minds. Never underestimate the value of compile-time error checking; a well-designed program may most of its bugs in this fashion!

      And now we move on to more interesting stuff, like inheritence and polymorphism. (And no, "templates" (parametised classes, for the better educated) are not OO).

      OO is not about "making programming easier". It is about creating a more logical structure to allow the application of engineering principles to software design and implementation. This means improving robustness and maintainability.

      OO achieves this by reusing code in a more effecient fashion than procedural languages; as a direct consequence of inheritence.

      In any situation being modelled by software there tend to be a number of data-bearing entities (physical objects, processes, representations) with similar properties and having similar functions. OO allows the similar properties and functions to be matched, factered out and reused across all the entities.

      Non-OO languages can approximate some of this functionality by using embedded or chained data structures, but they lack a significant capability: to automatically adjust the function according to the entity.

      This difference is best illustrated by considering an office with a manager, secretary, clerk and some production workers. The manager walks into the office and says "all of you, do your job!". Simple, and OO.

      In the non-OO case the manager walks into the office and says "all of you, if you are a secretary answer the phone and do the filing, if you are a clerk total the books, if you are a production worker on the Toy line then build toys, and if you are a production worker on the Pen line then make pens."

      OO simplifies the procedural logic which controls a situation, because each object knows how to behave in an appropriate way in reaction to a more generic instruction.

      If you find no benefit in OO other than "it makes coding easier" then you are missing the point, and I would suggest getting a good book on the topic and reading it thoroughly.

    • by SimonK (7722)
      Encapsulation is only half the story. To get any benefit from OO, polymorphism is essential. Encapsulation does indeed get you nice organisation by itself, but you don't get any improvement of flexibility. With polymorphism added, you gain the vital ability to operate on objects without having to discover their runtime type. This lets you write, for instance, a catalogue system that can operate on video tapes or books, without having to have any knowledge of what exactly its working on.
    • Interesting, but I disagree with some of your points. One by one:

      1) OOP != encapsulation, by definition.
      Hint: you missed inheritance and polymorphism :)

      2) Unfortuantely, not every program is combination of OO and procedural code. Sometimes OOP-ness is enforced.
      Hint: Java.

      3) Unfortunately, OOP is not helping to package code and data togethter. On the contrary, because of the inheritance it's often more difficult to trace what are the properties and methods of an object.
      Hint: read "Patterns of Software" by Richard Richard P. Gabriel. He has an exellent chapter on compression and reuse. By compression he means dependency on the context. For OOP it's non-localized dependency, which is usually bad.

      4) Your argument about NULL pointer checking is irrelevant. Before calling object methods, you have to make sure is's initialized. No difference with passing the pointer as an argument.

      5) There's more than just applying a function to a structure. Here it is: applying a function to two structure of diferent type. Where do you put this function? In OOP, it's a source of many arbitrary decisions on early stage. Projects evolve, but it's difficult to change such a decision once it's done.
      Example: LinkPictureToAlbum( Picture, Album ). Is it Album object method or Picture object method?

      In practice, another problem is need for multiple dispatch, but that's rather implementation problem. C++ and Java are popular OOP languages and they provide single dipatch only. It's not an inherent OOP problem - see CLOS for an example of successful multiple dispatch in OOP.

      6) Templates is non-OO feature of C++!

      I agree with your conclusion, though. The OOP is not a panacea, but it's definitely useful.
  • One example (Score:2, Insightful)

    by bapya (190846)
    One example that comes to my mind immeiately is MMTK ( link [python.net]) (Molecular modeling tool kit) developed in python by Konrad Hinsen.
  • sure it can but (Score:5, Informative)

    by kaisyain (15013) on Thursday January 03, 2002 @11:49AM (#2779345)
    First off you're examples Monte Carlo simulations and differential equations aren't "engineering problems". They are math problems that are a component of an engineering problem. Engineers does things. It builds a bridge, drives a car, prints a document. The examples you give are parts of that solution. Every GUI needs to do things like interpolate colors and position, which are the same class of problems -- if orders of magnitude simpler -- as differential equations and Monte Carlo simulations. So it seems to me that you need to figure out what your real problem is and figure out what programming paradigms might help you out with that.

    As others have pointed out OOP doesn't let you solve things that are otherwise unsolvable. It is a way of solving problems that may be better in some situations and worse in others. The examples you give of solving equations are all better suited to a functional language than a procedural one like Fortran, so rather than asking "why use OOP" you might want to first ask yourself "why am I using Fortran?" Obviously there are a number of factors that go into how we pick our solutions. Maybe OOP per se isn't a good fit for your problem but you need it to be multiplatform and have a huge amount of available code and standard libraries so you end up going with Java. Or whatever.

    The kinds of problems you're talking about don't have a great mapping onto the traditional ways of describing OOP. However, OOP is really just a somewhat formalized kind of way of dealing with abstraction and data encapsulation. You can make a difference equation a class. Maybe it'll only have one method that immediately finds all the finite solutions. But once it is a particular datatype you can also do things like compare whether two user-entered difference equations are identical and just returned the cached solution. You can curry them. You can return partial solutions and then come back later and ask the object for more solutions.

    Don't you already have discrete data types for these things? And don't you already have functions that operate on those discrete datatypes? Then you're already doing OOP. Sure you're not using inheritance and multimethods and things like that. But not every OO program does.
    • OOP is really just a somewhat formalized kind of way of dealing with abstraction and data encapsulation.

      OOP is one way of doing this. The question the poster needs to ask himself is whether he needs to maintain state in his programs. Many engineering problems do not require this. If he doesn't need to maintain state, then OOP is needless overhead.
  • by Mr. Fred Smoothie (302446) on Thursday January 03, 2002 @11:51AM (#2779368)
    OO languages exist at the "high" end of the language-level spectrum. They're geared toward managing code complexity in the face of a problem domain which is conceptually complicated, primarily by encapsulating bits of the problem domain into digestible and self-contained sub-problems. The overhead of all of the OO constructs is worth it if the reduction of your problem domain into smaller chunks is neccessary to solve the problem (or advantageous in terms of directing the efforts of multiple team members in areas where some decoupling is possible).

    However, if you problem is "low-level" or conceptually simple (though not neccessarily computationally simple) -- a recipe like "apply transformation x to dataset y, then transform again w/ algorithm z", the OO features simply serve as a distraction from thinking about your actual problem domain and it's solution.

    So yes, IMHO, there are problems for which OO techniques are not ideally suited, and most importantly, if the techniques get in *your* way they are not the right tool for *you*. Rememer, languages and tools don't solve problems. People do. If a tool makes you task easier, use it. Otherwise, save yourself the time.
  • by Papa Legba (192550) on Thursday January 03, 2002 @11:52AM (#2779384)
    You seem to think that OO is some end all be all of the programing language. It is more on how you structure the code. You can do a hello world program using OO is you wanted. Instead of acting on the logic of the problem you design from the idea that the data is what must be manipulated and therefore is an object to be handeled. All the problems you are listed are easily solved by defining the class that is associated with the data inputs and then perform actions on those objects. It is quite a bit different in thinking over how fortran is programmed.Having programmed in both OO is a much more powerful solution.

    Here is an excerpt from www.whatis.com that may explain this better than I can.

    " The first step in OOP is to identify all the objects you want to manipulate and how they relate to each other, an exercise often known as data modeling. Once you've identified an object, you generalize it as a class of objects (think of Plato's concept of the "ideal" chair that stands for all chairs) and define the kind of data it contains and any logic sequences that can manipulate it. Each distinct logic sequence is known as a method. A real instance of a class is called (no surprise here) an "object" or, in some environments, an "instance of a class." The object or class instance is what you run in the computer. Its methods provide computer instructions and the class object characteristics provide relevant data. You communicate with objects - and they communicate with each other - with well-defined interfaces called messages.

    The concepts and rules used in object-oriented programming provide these important benefits:

    The concept of a data class makes it possible to define subclasses of data objects that share some or all of the main class characteristics. Called inheritance, this property of OOP forces a more thorough data analysis, reduces development time, and ensures more accurate coding.
    Since a class defines only the data it needs to be concerned with, when an instance of that class (an object) is run, the code will not be able to accidentally access other program data. This characteristic of data hiding provides greater system security and avoids unintended data corruption.
    The definition of a class is reuseable not only by the program for which it is initially created but also by other object-oriented programs (and, for this reason, can be more easily distributed for use in networks).
    The concept of data classes allows a programmer to create any new data type that is not already defined in the language itself.

    One of the first object-oriented computer languages was called Smalltalk. C++ and Java are the most popular object-oriented languages today. The Java programming language is designed especially for use in distributed applications on corporate networks and the Internet."

  • by pdqlamb (10952) on Thursday January 03, 2002 @11:52AM (#2779385)
    I've seen some truly awful procedural code (lots of it was Fortran, BTW). I've seen some truly gorgeous procedural code (lots of it was Fortran, BTW). I've seen some some wonderful, and even more pretty awful, OO code (mostly C++, but with some Java).

    Go ahead and study object oriented programming. You'll learn some new ways to do things. But I think it's the act of studying, and the act of learning, that will be the most valuable thing you get out of the process. Too many people never study how to program, how to document, how to design code. They learn one or more languages. Their code shows it.

    A few people have a natural tendency to write elegant code. A few more, but still not very many, study and try to learn how to write elegant code.

    But don't expect the object-orientedness to make much difference. A dozen or more years ago, a young whippersnapper got hooked on objected-oriented design. He derided all the existing Fortran we had as spaghetti code. To some of us, though, his "object-oriented" code was lasagna code. No overriding structure, code spread out all over the place, a single function scattered over three files. And this was still Fortran; I've seen C++ coders who took six files for a similar, simple function.

    I've also surprised myself! when some of my OO C++ code needed four lines to add new functionality. But it was carefully designed, after years of programmer improvement and study.

    Go ahead and try it; it can only help.
  • by cananian (73735) on Thursday January 03, 2002 @11:53AM (#2779389) Homepage
    SIMULA --- the first object-oriented language --- was specifically *designed* for engineering tasks: but the tasks in question were process *simulation*. And, indeed, any iterative difference-based approach to physics modeling fits right into modern object-oriented languages. You create an instance of the object Car, say, for each physical car in the system, then call Car.update(time) to have the car compute its physics to move itself to the proper location for the given time. This way the physics of each part is sensibly contained within the instance of the object representing the part. This also works is you have instances of Boiler, WaterPipe, or OxygenAtom, WaterMolecule, or UraniumAtom and Neutron.

    I think the "answer" to your question is that, yes, your examples are too simple. When you're doing some simulation where the "finite difference solutions to non-linear equations" all interact with each other, and with computed fluid dynamics and heat transfer, etc, you'll immediately see the benefit of separating all these concerns into encapsulating object types.

  • 'Your problems are two small and specialized to realize any significant advantages of OOP.'

    The kinds of problems you're trying to solve aren't problems object oriented designs are good at. While OO is a natural way of dealing with some concepts (for example, GUI concepts), its real power doesn't come from this kind of thing. It tends to be best for designing very large systems that are complex and may change significantly over their life-time. The kinds of problems you mention (finite difference solutions to differential equations, finite-volume computational fluid dynamics, iterative solutions to non-linear equations, Monte-Carlo simulation of radiative heat transfer, etc.) aren't really the kind of software engineering projects that require carefull design. They may be hard problems, but they're also understood and well studied problems.

    Take a step away from the scientific problems and consider something like an inventory management system for a pharmacy chain that needs to be solid and accurate, while at the same time collecting data and producing pretty reports for whatever statistic the company directors think is important on that particular day of the week. A slightly different kettle of fish, no?

    Another often stated advantage of object oriented programming is component reuse. It seems that most developers don't really try, but for a little bit more effort and thought, object oriented techniques make writing highly reusable software components easy.

    For my own personal projects, I have a set of classes that do all sorts of things for me, from a log file manager to a small LALR(1) parser which I have a generic config file parser built using (all in C++, no need for external programs). It's a pain in the ass to write the code originally, but it was all well worth the effort. :)

  • A lot of engineers have trouble with the problem "Staying employed during a recession." OOP is the cure - every bit of code you create is now unmanagable to your cow workers. As such, you can't be fired.
  • My personal experience has been that OO is a big win when a problem is subject to factoring. By factoring, I mean that when you take each element involved in the problem, you can find common factors between them. In that case, you get a natural class hierarchy by moving the common elements into parent classes with each individual element being a subclass. The reduction in code size decreases the number of bugs substantially.

    One way you can detect this is if you are doing a lot of cutting, pasting and modifying during development. Often this is an indication that a better design would be to have one copy of the base code. All the other elements that had copies would now essentially inherit the base code and then override the parts that need to be changed for that particular element.

    If your project is not going to involve a lot of inheritance, then OO is really only useful if you are in a large project, in which case it acts as a useful way of delineating responsabilities. (i.e. all I have to do is implement and test these interfaces and I don't have to worry about stepping on other people's toes.)

    This is all a great simplification, but it covers my experience in a nutshell.
  • Pragmatics... (Score:2, Insightful)

    by Yoda2 (522522)
    If your primary job is engineering and not programming, and you're getting the job done in FORTRAN, then by all means stick with FORTRAN. If on the other hand, you are building software systems from scratch that will need to be maintained over time and have components that might need to be reused then maybe OO is the way to go. In any event, it is good that you are exploring OO because even if you don't use all the techniques explicitly, you are probably picking up some good design ideas through osmosis.
  • We do it! (Score:5, Interesting)

    by Bill Barth (49178) <bbarth&gmail,com> on Thursday January 03, 2002 @12:00PM (#2779438)
    Imagine for a minute that you don't know what problem you want to solve yet. You know that that you want to apply a Galerkin Finite Element Method [st-andrews.ac.uk] (for instance, though this particular method isn't required) to a whole class of problems on unstructured grids on a whole class of distributed and shared memory parallel computers. Imagine that you want your user base to be able to specify their equations like they would in LaTeX or some other markup language. Now try imagining that you have only FORTRAN77. Not a pretty picture. We're in the process of completing a rewrite of major sections of our parallel code to do exactly this. Our code started out (7 years ago) as an extremely efficient parallel (3D) C/F77 code for Navier-Stokes + Heat Transfer and is quickly growing into a multi-purpose, multi-physics code written largely in C++.* We extract considerable advantage form C++'s ability to hide implemenations so that as long as interfaces don't change the guts can. We also make good use of the ability to run code before main() in order to register the exisitence of routines (hash tables are your friend). If the routine isn't there you can't call it, but the code still compiles and runs otherwise. We also make use of base class/derived class relationships and polymorphism to allow, for instance, one base mesh class for the rest of the code to interact with, but with two separate derived classes: one to generate meshes internally, and one to read meshes from other programs. Etc., etc. I'm not sure our website can take the /.'ing, but you can look here [nasa.gov] for some hints. * I say largely b/c there's a few struct's still left over from the code's C days, but all the F77 is gone. There are still calls to assembly coded (vendor supplied) BLAS routines, though.
  • Remember that OO code tends to compile into slower and larger executables than structured code. This is not always the case, and optimizing compiliers can do a great deal to mitigate this, but the fact of the matter is that OO code was developed to give coders more power and shorter development times.

    Most of the engineering problems that I've ever seen solved in code are math intensive. One such problem was calculating the drag on a certain aircraft wing. If I remember correctly, the coder who was showing me her code indicated that the math involved broke down into a repetitious series of a few hundred cross-section integrations. These equations had to be solved for several hundred thousand cross sections to get a final result and a chart. At the time ('91) there was no 3d model, and the calculations were being conducted on a desktop computer. As you can imagine, it took a very.. very long time. One of the people I was with asked her what she was doing her math in.

    C. C++ had too much overhead, she complained, and the C compiler she was using was slightly faster than Pascal or Fortran. She was very seriously considering trying to translate her equations to register-based assembler code to speed up the process.

    If you have an engineering problem, and you're happy with the results you get from a funcational language, it's probably not worth your time you'll lose from switching to an OO language.

    If you
  • by franimal (157291) on Thursday January 03, 2002 @12:01PM (#2779447) Homepage

    From your post is sounds like you're solving single solution problems where you write a 'disposable' procedure (probably reusing some code) for each problem. OOP isn't designed for that.

    OOP really starts to shine when you actually have objects to work with. If all you're doing is trying to solve a single solution problem a simple 'disposable' procedure is the best route. For larger, evolving, iterative projects OOP is a godsend. In my case, I'm designing a MAV (Micro Air Vehicle).

    I'm using Python instead of C++ but the OOP example still holds. Aircraft design is a highly non-linear process, and for myself at least, counter-intuitive. I could write a single procedure to run the analysis but that's not nearly a flexible as an OOP solution.

    Basically, I'm using off-the-self components (i.e. motor, batteries, propeller) as a starting point for my design. Each of these components is considered an object. These components are combined in such a way as to make another object: the entire MAV. By using OOP it's rather easy to try different component configurations and design conditions (flight altitude, cruise, loiter, velocity, etc).

    If I was really cool (I'm not) I could add in some simulation stuff (Larger aerospace corporations do a lot of this, as it's cheaper and quicker than an experimental approach).

    One thing that this sort of OOP approach lends itself towards (especially in my case, is genetic algorithms). Since aircraft deisgn is so non-linear, and counter-intuitive the best solution is not easy to find. So many different designs need to be analysed. OOP and genetic algorithms were born for just this sort of thing.

    If you have a single problem that needs to be solved once for one set of conditions, then use a procedure. If you have a larger project that requires the solution of many smaller problems for various conditions (instances to use the OOP term) then OOP is an easier route. Anything in between is a judgment call and really depends a lot on your specific case.

  • OOP vs. C++ (Score:2, Interesting)

    by Rohan427 (521859)
    Many people confuse OOP with C++. The two are not the same. C++ contains enhancements that are _supposed_ to help OOP, but often don't.

    I've been programming for more than 24 years and have dealt with languages from assembly to FORTRAN. I learned to program in assembly before PC's were even invented. I have always written code as modular and reusable and in a sense in an OO style. I've solved many problems, some large, some small, using OO programming without using C++. In fact, I try to avoid OO C++ for many reasons, though I prefer to use a C++ compiler and a smattering of C++ functions/keywords and style.

    I think you will find that many problems have been solved using OOP, but that the definition and composition of OOP is often misunderstood. For a good example of an application that is written using OO techniques, but does NOT use OO C++, see the Quake II source code.

    The reasons I avoid using OO C++ is due to inefficient compilers, the tendency to generate hard to find/fix bugs, excessive overhead, and the tendency for other programmers (if I'm working in a team) to overuse/misuse OO C++ features (e.g. - operator overloading). To date I have been able to accomplish the same tasks, with the same OO designs, using straight C, with less hassle and greater efficiency.

    - Rohan
  • Ptolemy project (Score:2, Informative)

    by rfischer (95276)
    I'd recommend that you check out the Ptolemy project (http://ptolemy.eecs.berkeley.edu/). It brings the most powerful features of OO design (encapsulation, polymorphism) into an engineering modeling environment. Applications? Signal processing, simulation of hybrid electronic and mechanical systems, embedded control, etc. Also the basis for many electronic CAD tools.
  • by McBeth (1724)
    As part of a project I was on, we needed to do a bunch of simulations of particles moving subject to physics. Unlike what you usually see in games, these needed to be real simulations (reproducable in the lab).

    We ended up doing a bunch of OOP so that we could handle many different kinds of particles, and many different PDE solvers, each selected for the particular task. Because of polymorphism, we were able to write the engine once, and plug in what we needed fairly easily. In the end the code ended up being much cleaner, readable, and faster than the Fortran we started with. We have gone on and are using it for a completely different kind of simulation now with minor changes.

    This was all in the Chemistry Department, but I certainly think it applies.

    I would guess that most engineers use Fortran in part because of the book "Numerical Recipes in Fortran". Although there exist C and C++ versions of the book, they certainly don't take advantage of the languages, and for the most part are direct ports of the fortran. They are very disparaging of the languages in those books, and even spread FUD about C, C++ and the numerical stability of the compilers.
  • There's an intriguing book called bject-Oriented Implementation of Numerical Methods: An Introduction with Java & Smalltalk which might give some pointers. I haven't read it (just browsed it in a bookstore), so I can't give a personal recommendation one way or the other. It does seem rather intended to address just your question, though.

  • by nuffle (540687)
    Don't listen to the guys saying engineering problems are best solved with procedural programming. That's a ludicrous generality.

    Both methods (and basically all programming paradigms) can be used to solve your problem. Which you choose depends on factors other than just "which will work". Readability, reuse, maintainability, performance, and ease of design are some of the issues you'll have to weigh do decide whether to use OO or procedural. In my opinion, OO programming beats procedural in all these matters except performance (but C++ ain't too bad, right?).

    My company does a great deal of mission-critical engineering software development (satellite command and control, for example), and we approach every large project with OO design and implementation. We find it insturmental in managing complex systems.

    If you ever have to show your code to someone else, they'll thank you for having partitioned your project into smaller entities each with their own responsibilites and personalities. This modeling concept is much easier to follow than procedural's interweaving threads of execution.
  • I worked in that field, and it is very susceptible to OO solutions. A motor, for example, has a max speed, acceleration, position. It moves. Has a set zero position routine. It may move to far or it may stall (error handling routines). It may be a stepper or servo motor (subclasses).

    Pushbutton switches can be on or off, lights likewise (same class, sanity checks to ensure you don't read a light or turn on a pushbutton).

    Remember, you are dealing with real world objects which have attributes. Look at them from that perspective, and see how you can model them in software.

  • I don't know what you mean when you talk about an engineering application but there are some significant C++ applications written for the geoscience industry. I worked for a small company that does a 3D structural restoration and C++ was just fine for the purpose. We had our own scene graph/utility library and a GUI that exposed the toolkit's functionality.

    The reason for using OO was code maintainability and compartmentalization. It is generally easier to divide work up once you're able to break your application down to classes.

    OO also means extendibility. With the right class hierarchy it was easy for us to add a new node to our scengraph to support a new type of data. For example, initially the app supported horizon data only, later on we added support for faults just by extending one of the base classes. OO will help you write any application if your class structure is sane.

  • The applicatations that you listed primarily deal with physical systems, so they are very well suited to OO, where an object can be used to represent some real-world thing. Molecules, machine parts, elastic elements, or magnetic domains are all things that have behavior, state and identity, so they are perfect cantidates for objects.

    But, the physical simulations are also iterative, so the code will have a loop, and loops feel like procedural code. That is not a conflict -- you are allowed loops in OO code! Your simulations would likely have a loop that iterated over time, space, temperature, or energy, and for each iteration, you would examine the state of each object in the system and call some methods on them to simulate their behavior.

    For instance, if you were building a solar system simulator, each planet would be an object, with properties for position in space and mass. Your loop would iterate over time and over each planet. For each planet in a time step, calculate the force on the planet due to other planets, and move the planet in response to the forces. ( More likely you would use an adaptive iterator and use another loop to do several iteration steps per planet per timestep. ) The benefit of OO here is that it makes it easy to organize your code and move simple things like F=Ma, 3d vector manipulations and your Runge-Kutta integrator out of the main algorithm. Plus, your code is easier to read, since you don't nned a lof of comments for things like planet.mass() or planet.move(vector)

    OO makes physical simulations much easier because it allows you to organize the program according to the physical structure of the system, and those object remove a lot of basic code from the algorithm, so the algorithm becomes simpler and easier to work with.

    I have built simulations for packet networks, simulated anealing, Ising glasses, Newtonian mechanics and finite element analysis in both OO and procedural style, and OO worked so well that I would never consider writing any of them in procedural style again.
  • by wowbagger (69688) on Thursday January 03, 2002 @12:15PM (#2779546) Homepage Journal
    Preface: I've been an embedded systems software engineer since 1987. I've been programming in C for almost all of that time, and C++ since '91. I've designed systems with over 250kloc, hard realtime.

    The biggest single advantage of OOD is that you can say "This sort of thing will have a function that does something like this, but I won't make the final decision on exactly HOW to implement that function until late, when I have more information on what needs to happen."

    Let me give you a concrete example. I had to design the code to reprogram the flash in one of our devices. I faced the following problems:
    1) the way the data got to us could either be Xmodem or Ymodem.
    2) The file format could be either OMF or raw binary.
    3) The types of memory devices could change - they could be Intel type 1 flash, AMD type 1 flash, or Intel type 2 flash (or RAM), all of which have different programming requirements.
    3a) In addition, the types of flash could be changed by the production line (based on what was available - most of those parts were "on allocation", meaning "you take the quantities we give you and you like it - you ain't IBM so you don't matter".
    3b) The types of flash on a given unit could be mixed - you had to probe at runtime to figure out what you had.

    So, here's how I decomposed it:
    1) I had two file type objects: OMF and Binary. They each HAD-A Input object, which provided data , and HAD-A Memory object, which would program memory. The OMF object read OMF records from the Input object, parsed the OMF records, extracted the data, and commanded the Memory object to program regions of memory.
    2) I had an Xmodem object, which WAS-A Input object. It read data from the serial port, handled the checksum or CRC verification, block counting, and made the data available to the user (the file object).
    3) The Memory object HAD-A pointer to a Memory_driver object. When the Memory object was commanded to write to a block of memory, it verified that the write was in the current block, and if so passed the request to the Memory_driver object. If not, the Memory object HAD-A list of Memory_driver_list objects, which each HAD-A pointer to a function that would probe a given memory address and return either NULL or a pointer to a newly created Memory_driver object. The Memory object would iterate through the list, asking each Memory_driver_list object "Can you program this?". When one of them returned a non-null value, the Memory object would delete the old Memory_driver, and use the new Memory_driver.
    4) I had Intel_series1, Intel_series2, AMD_series1 and RAM objects, all of which WERE-A Memory_driver. Each class HAD-A static instance of a Memory_driver_list object, which automatically linked itself to the driver list. Each driver HAD-A static member function to probe memory and return a pointer to a newly created driver if needed.

    First, this let each routine be focused on what it needed to do - the Xmodem routines didn't worry about OMF format, the OMF didn't do Xmodem handshakeing, the Memory routine didn't care about the specifics of programming memory. I could test each object out in isolation, get it working, and move on. Now, you can do this with proceedural programming techniques too.

    Second, when a new type of memory was added, I was able to just write the driver for it, and not touch the OMF object, the Memory object or the file transfer objects. They automatically picked up the new driver. Now, you can do this in a proceedural language like C, but how do you do so? You make each driver have a table of function pointers, and you have the upper level code keep track of a void * that contains your driver information. Guess what - that's OOP! The function table is the same as a C++ vtable, the void * is your this pointer. Except that in C, you have to track all that stuff yourself, in C++ you can let the compiler worry about the BS and you focus on the code design.

    In short, OOD helps, but you still have to use it correctly.
  • OO is Hard (Score:3, Insightful)

    by karb (66692) on Thursday January 03, 2002 @12:15PM (#2779549)
    I'm a software engineer. However, I lost you at the "I'm having trouble doing ...". I'm assuming this means you are some sort of real engineer :) :) OO is great. It does what it promises. It makes everything a whole lot easier to manage, makes your code more reusable, blah blah blah.

    However, I have lots of bad experience trying to get engineers to write good OO code. Nothing against y'all, but, conversely if you forced most software engineers (aside from a few savant freaks that I'm sure will chide me) to deal with the engineering problems you mentioned (that I have never heard of or forgot) we would probably die.

    What I'm getting at, I guess, is that OO rules. However, it's like linux, or repairing cars, or (ad infinitum). Being an expert rules, but it's not always worth the time to become an expert. You can't just jump in. Reading a few books helps, but I've read a few books, been doing this full-time for two or three years, had a very OO college experience, and most of the stuff I design and code is still crap.

    In addition, the code you are writing seems really unlikely to change. Write it procedurally, and write it well, and your grandkids will still be using that code because it would be too much of a pain to rewrite it to OO.

    I think you might be looking for an exemption. Here it is : use procedural programming for things that are tough for you to imagine in OO terms. Don't feel guilty. You will still never have as much crap code lying (laying?) around with your name on it as I do, and I do this for a living ;)

    • Well, I'm an astrophysics student, and not really even a hacker, though I have made a couple of hacks that people have thought have been good. But I think that given a language where the concepts are clear, OOP isn't hard at all.

      The reason why I learned OOP is pretty much that I had to. I'm at the University of Oslo in Norway [www.uio.no], and OOP was invented here and implemented in SIMULA. So they really forced us to use SIMULA and program OO, but in just a couple of basic courses, so I didn't a prolonged forced exposure.

      Examples where OO concepts are clear include SIMULA and the S system (my favorite implementation R [r-project.org]). SIMULA is a full-blown OOP system (but there are various reasons why it failed), while S has just a few OO features, but the features that have been implemented are easy to understand, they incorporate some essential concepts, and they are very powerful.

      Then, you have C++ which is also a full featured language, but where the concepts are not that clear and easy to grasp.

      When OO gets muddy is usually when it is built on the top of existing languages. Perl OO is a bit muddy, but not too bad, but if you look at e.g. IDL it gets rather bad IMHO.

  • Engineering with OOP (Score:2, Informative)

    by epperly (188343)
    My previous employer, Aspen Technology, Inc. [aspentech.com], markets some programs written in C++ using the concepts of object-oriented programming. They also market some programs that are largely written in FORTRAN. The C++ and FORTRAN programs are used by real engineers to solve real engineering problems.

    Many engineering programs use a combination of languages. For example, C++ is used for the high level programming and FORTRAN for low level the numeric kernels. Of course, you can write low level numeric kernels in C++ because it supports both OO and procedural programming. Often FORTRAN is used because

    • the code has already been written and tested
    • FORTRAN compilers can be optimized better due to simpler loops and different aliasing rules (note C may improve with the introduction of the restrict keyword in the C ISO 99 standard).
    • numerical methods gurus are more comfortable with FORTRAN
    • C++ is still not considered as portable as C or F77

    My present employer, the Center for Applied Scientific Computing [llnl.gov], has Overture [llnl.gov] and SAMRAI [llnl.gov] written in C++.

  • OOP is mainly useful for the design of large systems. Unless your language is being overly intrusive, there won't be anything OO inside the solution of an engineering problem like the ones you describe.

    The way OOP would apply to your problems would be when you're looking at the problem from more of a distance. You might have a situation in which some code wants the solution to a problem; the problem is specified by some other code, and it is solved by some other code, but there is a chunk in between that is doing something with the two parts (e.g., graphing them or something). You could make a "problem" interface, with a "solve" method, and various methods for getting information about the data. Then the intermediate code doesn't need to know what procedure to call to get the solution, because the problem object knows that.

    As for things like "solve a differential equation" or "solve a set of linear equations", OOP means that you're writing a big method instead of a big procedure. It's not a big deal. The real jump is switching to a functional language, where you write your code without side effects, and the compiler can do optimizations which change when code gets run and do not run the same code with the same data more than once.
  • I'm sure plenty of people use C++ to kick butt, but I personally never appreciated OOP until I used it in more high level languages.

    For something that's much more OOey, and easy to learn, try Python. I don't see any reason for new applications to be written solely in C++ nowadays. And the speed issue is irrelevant since you can rewrite portions of code in C (and quite easily, I was pleased to find).

  • A lot of people seem to be forgetting that objects can be used to represent algorithms or protocols instead of GUI widgets or physical things, and that subclassing still applies. It's very easy to imagine, for example, a MonteCarlo class or a FiniteElement class with virtual methods for the equations to be applied to each element/unit/whatever. It's much cleaner and more maintainable than explicit dispatch tables and function pointers, and never even mind the cut-and-paste approaches that many scientific code is still based on. Various notational conveniences such as function overloading and default arguments could also be useful.

    Sure, the OOP literature tends to give different sorts of examples, but the basic tools are still useful if you just allow yourself to think in terms of relationships between algorithms instead of between actual objects.

  • Ok, using the example you gave the following comes to mind. Say you wanted to build a generalized engine that could support multiple business models and run n number of algorithms n number of times. From an OOD/OOP perspective, one might encapsulate the data with a generalized interface, and have engine that takes x object, x algorithm and execute the calculation or report back an error.

    Now the real question is "should you?" Probably not if you're doing scientific calculations. You're better off optimizing the code and writing detailed documentation than generalizing the structure. Like others have said, "OO is a tool." That's all it is, nothing more, nothing less. Try to think of it as building a house or an office building.

    There are reasons why office buildings have large open spaces with cubicles. This allow reconfiguration of the furniture to fit each renter's needs. For the same reasons you wouldn't try to cram 50 person company into a 4 bedroom house, you shouldn't force OOP principles on a problem that doesn't call for it.

    From your post, it sounds like you're interested in OOP, so maybe the question really is "should you get a new job that gives you an opportunity to find out first hand what OOP can do for you?"

  • by mikera (98932) on Thursday January 03, 2002 @12:37PM (#2779704) Homepage Journal
    I have always thought of OOP as fundamentally a procedural programming technique but extended to give you better ability to organise and manage larger projects. C++ is a superset of C - you don't have to use the OOP features but they can help you enormously in the right situation.

    OOP also encourages good programming practices like producing well-defined interfaces, implementation hiding and code re-use. I actually think these are crucial to the effectiveness of OOP. These are all good things, and I'm sufficienctly lazy that I would never write anything other than a trivial program in purely procedural style.

    However, OOP is still best suited to particular domains. Modelling, GUIs, enterprise applications, games etc. are perfect because they all require the manipulation of discrete and readily identifiable "objects" that map onto the OOP model very well.

    If you're writing network drivers, you could use OOP, but as other posters have been keen to point out the (very small) overhead of most OOP languages actually becomes a problem for very low-level code. Hence OOP isn't so well suited for OS kernel code, network protocols, hand optimised inner loops and embedded applications.

    The difference between procedural and OOP is mainly a trade-off between low level control of the machine and having a semi-automated system to manage the complexity for you. Interestingly, for larger projects, good programmers in procedural langauages often end up having lots of function calls that take the "object to be acted on" as an argument and are therefore effecively emulating method calls. Once they start putting in switch statements in those functions to branch on the type of object encountered, they have effectively emulated virtual methods.

    Your case is an interesting one. You are dealing with mathematical/engineering problems that are often tackled in a procedural style.

    If you're feeling adventurous, I would actually suggest you head off to look at functional langauges. Reason is that these langauges are ideally suited for representing functions and other mathematical constructs, just as OOP is geared towards representing and manipulating "objects". Haskell would be my no.1 choice if you're looking for elegance and flexibility, O'Caml if you are more concerened about raw performance.

    If these seem too radical a departure, then I still think that OOP could make sense for a major project. You probably wouldn't need inheritance, but implementation hiding can be very useful. Let's say you're modelling fluid dynamics, and do it procedural style with a big array. Works fine until you decide that in fact you want to store the data in an octree so that you can get a couple of orders of magnitude better resultion in the particular areas you are interested in. At that point you have to change everything that accesses the data structure, including the 100 or so simulation programs you've been developing. Not fun. If OTOH you had encapsulated it all in an object, you would just change the object's private implementation, keeping all accessor methods the same (e.g. getFluidVelocity(x,y,z), getPressure(x,y,z) or whatever, I'm not an engineer :-). In this case, all the code that used the object would remain the same, possibly saving you a load of work.

    It's also often useful to have data represented as objects just so you can do useful things like pass the around, build larger data structures etc. Not that you can't do this in procedural style, but OOP takes away all the pain. I've lost track of the number of times I have taken advantage of all the useful features like object serialization in Java, which saves you all the hassle of having to write import/export functions to store your data structures on disk.

    Ultimately, use what seems right for your application. But remember that OOP and other techniques such as functional programming aren't just fads, they are ways to solve problems that procedural style just isn't well suited for. If you find yourself spending too much time writing the "glue" to hold a big application together, then it's a good sign that you've actually picked the wrong tool.
  • Problems of the type you descripe wouldn't benefit much from OOP. I'd solve them myself in C, but that's mainly just because I don't *know* Fortran (fortran is very good at math problems with straightforward methods of solution, and parallelizes easily).

    My most recent project, on the other hand, involved simulating a computer system (I won't go into detail; wait until after I've published). This is a perfect scenario for OO - a computer system is built up out of many parts, many with similarities, but with different implementations. If you need a cycle-by-cycle or event-by-event simulation of a computer system, it makes sense to build up models of all of the parts that will be interacting and put them into an OO hierarchy. This lets you avoid copying code, and lets you change things much more easily than in a straight C environment.

    In a previous project, I was building the skeleton for a program that would have to be rewritten for many different purposes. Some parts would stay the same between instances, and these were what I was building. I made the mistake of writing it in C, with the idea of upgrading it to C++ later. I ended up faking OO-isms by calling function pointers hither and yon to abstract things. When maintenance of the project was finally turned over to someone else, they started the migration to C++.

    In a complex program where you have a lot of abstraction going on between different types of component, an explicitly OO language will almost always make life much easier.
  • I found OO and C++ to be very helpful in a signal processing package I did some years ago. It performed FFTs, fast cosine transforms, correlation, cepstral analysis, graphing, etc to support experimentation with audio and voice analysis/recognition.

    I started out in C, but converted to C++ when it became clear there would be a serious advantage for that particular code.

    Looking at the header file, I see that I ended up with a class SampleInfo that contained basic info like the sampling rate and a dozen other items of interest. This basic type was useful as a parameter to constructors and converters throughout the package.

    Then there was a class HeaderInfo, which inherited from SampleInfo. It added information such as whether the data was a stream of bytes, complex numbers, or in phase-magnitude form.

    Using that starting point, several other classes inherited from HeaderInfo to add still more specialization: VectorHeaderInfo (information about an array of arrays of samples) plus associated implementation classes: ByteVector (just an array of samples of type byte), ComplexVector, ComplexVectorOfVectors, etc.

    The class hierarchy and associated inheritance doesn't sound especially impressive, but it immediately cleaned up the code and made it easier to experiment and easier to find certain kinds of conceptual bugs.

    Actual transformations were made easy by always returning a pointer to 'this', so a typical usage would look like:

    Audio recording(SampleRate);

    ByteVector bytes_in.record(recording);
    ComplexVectorOfVectors data(bytes_in);

    // Slashdot formatting is peculiar here,
    // read as "data.zeropad()":
    data

    .zeropad()

    .window()
    .fft()
    .accentuate()
    .scale()
    .show_color_spectral_analysis();
    exit(0);

    This style of pipelining data through transformation stages makes experimentation a breeze...just insert/delete pipeline stages.

    Even design of core algorithms like fft() itself benefited somewhat from reimplementation in C++, although the benefit there was a little smaller.

    Basically the added value of OO is small (but non-zero) if you look at converting just one function implementing a single numeric technique, but becomes larger and larger as you implement a family of related techniques, such as matrix arithmetic, multiple transforms, diff eq techniques, etc.

    P.S. the biggest optimization advantage for using Fortran is on things like vector processors. And in any case, the right way to optimize is to re-code only inner loops. Thus one could have a package written mostly in C++, but with inner loops recoded in Fortran, if necessary.

    Coding whole apps in Fortran is neolithic.

  • by Greyfox (87712) on Thursday January 03, 2002 @12:49PM (#2779780) Homepage Journal
    There's still a lot of hype out there about how OOP can solve all your problems and it can actually solve a lot of them. The problem is it introduces a completely new set of problems that you will be completely unfamiliar with. The folks pushing OOP don't tend to mention that.

    OOP requires a different organizational view of the problem you're working with. I've seen a tiny few people coming out of college who appear to have been introduced to the necessary concepts in college. For old school programmers or people whose degree program was still geared toward 1970s era, there's going to be a learning curve. Moreover you can't just go off on your own and start programming in C++ or Java willy nilly. You'll just reinforce bad habits while not developing any good ones. A year in a shop with good solid programmers who are willing to mentor you would probably give you a pretty good feel for what works and what doesn't. Assuming you're willing to really study the dicipline.

    One of the first things your mentors will probably tell you to do is go out and get a few books. Design Patterns, Antipatterns and Refactoring books make good introductory reading. None of these things are magic bullets either, and you should refrain from viewing them a such. If you don't have Programmer Nature, none of that stuff will help you.

    After all that you'll be able to write code that should be easily maintainable and flexible for new problems. Whether or not that will actually solve the problems you want solved is another question entirely.

  • Using Objects (Score:3, Informative)

    by fm6 (162816) on Thursday January 03, 2002 @12:52PM (#2779800) Homepage Journal
    What makes OOP powerful is its ability to create powerful application frameworks and component libraries. Now few programmers have the interest or skill to create these things, but we all can excellent use of them. The hard part is understanding OOP systems from the later point of view. They tend to be designed and documented by people who think in terms of building the system, rather than making things with it.

    The first OOP system I ever used was Digitalk's Smalltalk V [phaidros.com], a quite successful adaptation of the ur-OO language to DOS, and later to 16-bit Windows. I was impressed by its power and expressiveness -- and frustrated by the difficulty of dealing with the huge mass of new concepts. It would have been much easier if there were a clear distinction between things I needed to know in order to extend the framework, and things I needed to know in order to create applications.

    Anyone interested in OOP should download one of the many Smalltalk implementations available [phaidros.com] just to play with it. But there's a limit to the serious work you can do. There are still Smalltalk developers out there, but most people just don't have the mindset.

    Modern OOP systems are mainly extensions of procedural programming languages. This disgusts OOP purists, but makes for a more shallow learning curve, and helps sharpen the distinction between features for designing objects, and features for using them.

    C++ is the fanciest of these. But it's extremely complex, and should be approched slowly, if at all. C++ enthusiasts never seem to tire of finding new and obscure idioms to invent.

    There are lots of OOP languages out there, but I think two recommend themselves to the newbie -- especially the newbie who wants to actually makes things. There's Java, which no longer seems likely to change the world, but is still a dominant force in some applications.

    And there's Object Pascal, which outsiders consider an antiquated curiousity, but which is considered a powerful and highly usable tool by its rabid fans. OP compiles very quickly, which makes it particularly useful for RAD tools.

    Which brings me to the commercial: I help document the two big Object Pascal RAD tools, Delphi (Windows) [borland.com], and Kylix (Linux) [borland.com]. Both are extremely accessible to the OOP newbie, while having all the power and expressiveness of a serious OOP system. And both have versions you can download for free.

    Some people down the hall do a similar tool for Java [borland.com]. I hear its pretty good.

  • It's not a well defined term. What exactly are you expecting? Some "problem solver" object you can just drop in to any program and reuse?


    At it's most primitive layer, OOP is a coding thing, a syntactic sugar as so many professors like to say. A way to keep code clean. It's quite nice in that capacity, I don't mind writing "c = a + b;" and under the covers mpz_add is getting called and adding the arbitrary precision number a to the arbitrary precision number b and storing the out put in c. This isn't true OOP, I only include it becuase it's the OOPLs that have made it popularly available.


    The next level is encapsulation and reuse. It's pretty damn nice to be able to write "d = {}" in python and create a hashtable dictionary. I do that is literally dozens of python programs. I could easily produce the same thing with list primitives or vectors and what have you and I might even be able to make it better for my particular use but for the most part the dictionary object in python or any of the STL objects are insanely useful, they are easy to use, quick and they are building blocks you can use to build bigger programs. You're already using this kind of code whether you know it or now, the C library is the same thing, it doesn't have the same syntactic sugar though and the things it does are generally more simple where some of these objects are higher level components. I wouldn't call the C library object oriented, per se, but might call a component that does the job of half a dozen C library calls an object.


    The final layer of OOP as I see it is modeling. Again it's not well defined outside of a few circles and even then Grady Booch and Bertrand Meyer and the other gurus spend countless hours and books bickering about it. The modeling part is how we break a problem down and implement a solution for it. This I would say is a universal area where OOP has won and will continue to. When programs reach certain sizes, the human mind can really only deal with the complexity by building heirarchies and mapping the problems to solvable isomorphs and then trying to reuse ideas as you move through the heirarchies. If you're trying to multiply a few matrices and then hit them with the Gauss stick to tell if the bridge is going to work, it's probably not a good example of a problem to model that way. A GUI on the other hand is a perfect example where you can have a very clean hierarchy of windows of different types with different functions that behave differently. In my experience, I haven't seen any large scale projects started in the last 15 years that weren't object modeled, even if they were implemented in C or some other non-OOPL, I have seen a fair amount of code from the 1960s and 1970s that was very very complex because it didn't have any real object modeling. The linux kernel has a fair amount of object modeling in it, there are abstract block devices and character devices and they can all be treated the same way, buffering is an abstract concept regardless of the device. Even functionally implemented programs have some degree of object modeling in them.


    Now what kind of OOP are you looking for? If you're looking for some kind of advanced object model with reflection and a complex object hierarchy, then maybe it's not being used to solve some engineering problems, it takes a certain size problem before that kind of effort really pays off in the implementation. If you're looking for code reuse then there are numerics packages and probably tons of other packages the will do that.

  • I have been on projects that insist on OO for there engineering projects. its good for reuse within THAT project, but thats about it.
    Very few people can write good OO. but even the good ones often end up with too much indirection, which can seriously hurt a "low level" program.
    Each project had specific needs for that chip set, or product, so anything but the most basic needs wasn't reusable without more tweaking.
    Compilers are pretty darn good these days, so thing that use to be a selling point for OO aren't anymore.

    In my real world experience, there is nothing OO can give you, that good coding practices don't.

    The main advantge thats bandied about these days is re-use, but That can be done with a function just as easily.
  • by ttfkam (37064) on Thursday January 03, 2002 @01:25PM (#2779999) Homepage Journal
    I feel like clearing the air of half-baked comments and know-nothing OO detractors.

    First of all, for those individuals who refer to C++ as an OO language, please stop. You're wrong. C++ can be used for an OO project, but it is a multi-paradigm language. At least that's what Bjarne Stroustrup calls it. But what does he know about C++?

    Second, use of C++'s STL does not equate to OO programming. It is an example of generic programming. Here's a hint: the STL has very little inheritance except for iterators and iostreams -- most evaluation is handled at compile-time. And even iterators and iostreams are just as much generic as OO.

    Finally, please dispel the rumor that C is automatically faster than C++ because of C++'s excessive overhead. Need proof? Please read this article [att.com] about treating C++ as its own language and not a variation of C. Yes, it's a PDF. Get over it.

    Think the article is FUD? Prove it! Take the examples from the article and tune them better than he did. Compile them with trusty ol' gcc and g++ on your box. Measure the results. After you do so, can show that C is faster, does not contain any potential buffer-overflow bugs, handles error conditions, and wasn't at least five times more code to do it, then reply back with your results. I have a feeling I won't be getting any replies from people who actually try it.

    That said, use whatever language you like best. Studies have shown that people will always perform better in languages they know intimately well than languages in which they have a general familiarity.

    But if you want to use OO and C++, check out this numeric library [oonumerics.org]

    Have a nice day

  • by jilles (20976) on Thursday January 03, 2002 @01:35PM (#2780057) Homepage
    It seems you have convinced yourself that the world should be modeled in terms of procedures. This is typical for people who have programmed using procedural languages. The same happens to people who program OO: they see classes everywhere. Then you have people who like functional languages: suddenly everything seems a function.

    The sad part is that all these paradigms have problems where they can be applied very well and none of them can be applied to all problems well.

    Now back to OO. What is it good for: it's a good way to structure complex systems. If you have a complex system, you can probably make its structure more explicit by using objects, design patterns and so on.

    Mind you, it is no silver bullet and you wouldn't be the first one to build a super complex, flexible OO everything system that doesn't perform well and is impossible to maintain.

    Symptoms that indicate you might benefit from OO:
    - There's a lot of commonalities between the programs you write: this indicates that you can generalize functionality.
    - There's a lot of dependencies between your modules: you need to encapsulate and hide stuff
    - You have a lot of complex data structures and lots of functionality around those data structures: hmm objects???

    If you are serious about adopting OO you should spent some time with books about OO design such as for example Gammma's excellent book about design patterns.

    As for your question regarding engineering problems. I have worked with companies involved in building embedded stuff like fire alarms, haemo dialysis machines (medical machines), mobile phones, digital radio systems and embedded server products. All of them use OO based designs to their advantage so it can be done. And in case you are wondering: all of these systems were very large systems (500 KLOC - 5 MLOC). Using OO is a necessity for these companies since it is the only tool they have to keep complexity under control.
  • by jamisons (74697) on Thursday January 03, 2002 @01:37PM (#2780063)
    I haven't worked _on_ this project but I did work with it a little bit, and tried to write a small analysis routine for a class I took. Check out the OpenSEES Project [opensees.org] at Berkeley for a good example of a OOP solution to an engineering problem. Every portion of the analysis, from equation solvers and matrix routines to structural elements and material models are broken into objects. It's an ambitious project but it's moving quickly. And it's even open source!
  • by Zero__Kelvin (151819) on Thursday January 03, 2002 @04:28PM (#2781249) Homepage

    One of the most common misconceptions in the industry is that C++ is 'an OOP language.' For that matter, it is similiarly incorrect to label C a procedural language. Paradigms like Object Oriented or Procedural are exactly that ... paradigms ... ways of thinking about problems.

    The first C++ compilers were merely front ends for C ones, which took C++ constructs and generated C code, which was then compiled and linked into an executable. It is true that C++ was developed to assist in making OOP constructs with clarity and ease (let's not argue the success or lack therof here, please.) Still, nothing stops one from OOP modelling in Assembly Language and procedural was always openly supported by Bjarne Stroustrup when he invented C++.

    You call the problem on the head when you say "I cannot, however, convince myself that there is a clean way to use these concepts to solve the type of procedural problems that I have encountered in the past." When your problems lend themselves to procedural solutions then you want to think about them that way, just as when your problems lend themselves to Object Oriented models, you want to model them that way.

    The right tool for the right job. If you want to implemet a Fast Fourier Transform you want to look at it procedurally. If you want to model a Robot, in which thousands of components performing those FFTs interact, you probably want to take your procedural code, wrap it in some Object Oriented code, and get your model.

    OOP and Procedural are complementary analytical methods, not competitors. It is an abuse on the part of any software engineer to view or discuss them otherwise!

Recent investments will yield a slight profit.

Working...