Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Can OO Programming Solve Engineering Problems?

Cliff posted more than 12 years ago | from the stuff-to-think-about dept.

Programming 621

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."

cancel ×


Sorry! There are no comments related to the filter you selected.

I have gotten the first post (-1)

Tasty Beef Jerky (543576) | more than 12 years ago | (#2779212)

Complete with


random text to screw up the stupid lameness filter and caps and such.

Natalie Portman denounces hot grits (-1, Offtopic)

cyborg_monkey (150790) | more than 12 years ago | (#2779416)

By: Hob Goblin
3 January, 2002

/ Troll News Bureau / - In a move that has astounded many loyal fans in the Troll Community, Natalie Portman denounced hot grits at a press conference earlier today. Apparently she became disgusted after an unidentified Troll offered to pour hot grits down her pants in exchange for one goblin, a bowl of oatmeal and three hours of monkey sex.

Is Portman off her rocker? Yes
I don't know
Yeah, baby, yeah!!
| View Results
"Hot Grits are heavily contributing to the downfall of this society" Portman stated "and I can't stand this insanity anymore, something must be done to protect myself and people like me from these ruthless grits fiends." Supporters cheered as Portman left the podium.

Several groups protesting outside of the conference showed their disgust at Portman's comments by holding a grit party where wheelbarrows full of hot grits were waiting for anybody who cared to take the plunge. "Hot Grits are my life." one protester said as he poured another bowl down his shorts, "I can't live without them and I'm sick of everybody always complaining about them."

Legislation has been introduced into the House of Trollmasters that would restrict the act of grit pouring to people's homes, it is not expected to pass as most the Trollmasters are avid grits fans.

The Dissociated Press contributed to this report

OOP won't help, sorry... (5, Funny)

Anonymous Coward | more than 12 years ago | (#2779216)

Your problems are too small and specialized to realize any significant advantages of OOP.

Re:OOP won't help, sorry... (0)

Anonymous Coward | more than 12 years ago | (#2779298)

No, his problems are too large and diffuse to realize any significant advantages of OOP.

Re:OOP won't help, sorry... (1)

coflow (519578) | more than 12 years ago | (#2779386)

it seems to me that the larger and more diffuse a problem is, the more that problem screams out for object oriented design....

OOP (2, Informative)

ParamonKreel (182921) | more than 12 years ago | (#2779219)

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 (2, Interesting)

Kamel Jockey (409856) | more than 12 years ago | (#2779246)

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 (3, Insightful)

kevin42 (161303) | more than 12 years ago | (#2779321)

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 (1)

FlowerPotAdmin (541227) | more than 12 years ago | (#2779445)

Real bloat comes from libraries like STL...

Actually, don't you mean template use in general?

Re:OOP (1)

Chris Parrinello (1505) | more than 12 years ago | (#2779388)

"very bloated" is really incorrect nowadays for modern compilers for OO languages such as C++. This is a common misconception that old timer real-time and embedded programmers like to cling to whenever anybody mentions OO. Basically, if you avoid relying heavily on polymorphism for method calls, C++ is just as fast as C. If executeable size is a problem then just don't use or link in standard libraries.

My opinion about the procedural vs. OO in RT or embedded systems debate is that if all of these platforms are so resource constrained, then the applications should really be written in assembly anyway. One can write really poor performing code in a procedural language just as easily as an OO language. Why risk it? :)


Re:OOP (1)

ParamonKreel (182921) | more than 12 years ago | (#2779428)

I meant in the development time. I'm well aware that as you get further and further away from machine code, you loose the speed of telling the processor exactly how to move electrons around.

Use Functional (1, Interesting)

Zordak (123132) | more than 12 years ago | (#2779222)

Functional programming is better suited to solving engineering problems. You don't need the overhead of OO design for your engineering programs. I would stick to C unless you are trying to do some kind of fancy GUI.

Don't confuse OO techniques and languages (3, Insightful)

twoflower (24166) | more than 12 years ago | (#2779255)

OO design has nothing to do with C++ versus C. You can do OO design with any language you like; much of the Linux kernel has elements of OO design, but is implemented in C.

Language is an implementation detail. It does not dictate design.


Re:Don't confuse OO techniques and languages (0)

Anonymous Coward | more than 12 years ago | (#2779356)

This is a troll right? You can't do object oriented programming with every language. Many languages don't have the ability to do OOP.

Sure you could do OOP with C, but you'd have to do a lot of extra footwork in order to get those objects created in C to act like objects.

Re:Don't confuse OO techniques and languages (0)

Anonymous Coward | more than 12 years ago | (#2779446)

Ok smarty pants. What language is your precious OOP language actually written in? Huh? Huh?


Re:Use Functional (5, Informative)

VP (32928) | more than 12 years ago | (#2779280)

C is a procedural language, not a functional language. Examples of the latter include LISP, Scheme, and ML.

As to whether an object-oriented approach is suitable for engineering applications, I think it depends on the applications and problems. How important is abstraction and re-use? If you deal with matrices, would you benefit from a matrix object which implements all the properties a matrix has? With differential equations, are there objects suitable for implementation?

As with all general questions I am afraid the answer is "It depends."

Yes and no (3, Informative)

renehollan (138013) | more than 12 years ago | (#2779341)

Functional programming is better suited to solving engineering problems.

Not really, but there is an element of truth to that mantra: most engineers traditionally learned to program in Fortran, and there were some damn good Fortran compilers/libraries to handle the types of matrix manipulations commonly encountered.

You don't need the overhead of OO design for your engineering programs. I would stick to C unless you are trying to do some kind of fancy GUI.

While abstract classes will incur the hit of an extra level of indirection in a function call, and exception handling in C++ can be expensive (as can multiple inheritance), these features only cost you if you use them.

Now, to answer the question at hand, I have helped to design and develop commercial speech recognition products using C++. Of course, there was plenty of C and hand-tuned assembler there as well.

A more concrete example would be the VFS in Linux, as well as the classes of network, block, and character device drivers -- while generally coded in C, they represent the notion of abstract base classes unifying a common interface to many different implementations -- there's no reason C++ could not have been used there.

Re:Use Functional (1)

OSSMKitty (125119) | more than 12 years ago | (#2779387)

While I would agree that functional programming is a great paradigm for solving general engineering problems, I think it would have some issues with the problem domain specified by the post.

For example, in Haskell, as in most functional languages, you can never be quite sure how the runtime is implementing your algorithm. In some cases, say a Simpson's rule approximation, this doesn't matter because:

  1. Any optimization that needs to be done is easy to do by changing the algorithm, and
  2. the endpoint is easy to determine.
However, this isn't always the case for some numerical or simulation algorithms that might run a long time, have a fixed algorithm, a lot of special cases, and heuristic based endpoints.

Functional (-1, Troll)

ParamonKreel (182921) | more than 12 years ago | (#2779230)

Yes, do functional if you are only coding basic Algorithms.

Look at the audience.... (4, Interesting)

Arctic Fox (105204) | more than 12 years ago | (#2779231)

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.

Re:Look at the audience.... (0, Redundant)

Kierthos (225954) | more than 12 years ago | (#2779275)

Hrm... I don't know... I have degrees in both Mechanical Engineering and Computer Science, and while getting my B.S. in Mech.E, we only had one course on FORTRAN programming after the 101 intro. Whereas in the Comp.Sci. program, there were multiple courses involved in programming in C/C++.

Maybe Engineering grad students get more FORTRAN, but I tend to doubt it.


Re:Look at the audience.... (2)

NecroPuppy (222648) | more than 12 years ago | (#2779365)

Not as far as I know... I was a computer engineering student, and I regularly worked with the grad students, mostly as a gofer.

Mostly, they worked with pre-existing software packages; when they needed to actually write anything, it would be in C/C++ or LISP - sometimes both at once.

And let me tell you, embedded LISP code inside a C programer is really ugly looking...

Re:Look at the audience.... (3, Insightful)

Bat_Masterson (250306) | more than 12 years ago | (#2779363)

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?"

Re:Look at the audience.... (3, Interesting)

wsloand (176072) | more than 12 years ago | (#2779444)

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 (2, Interesting)

Ashcrow (469400) | more than 12 years ago | (#2779233)

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.

what should i use? (1)

oyenstikker (536040) | more than 12 years ago | (#2779240)

So what would be a good language to learn for a beginning mechanical engineering student?

Re:what should i use? (0)

Anonymous Coward | more than 12 years ago | (#2779261)


Re:what should i use? (1)

QuaintRcky (41068) | more than 12 years ago | (#2779348)

Python - a lot of scientists and engineers use it.

The value of python comes from the clarity and simplicity of the language, meaning it is much easier to concentrate on the problem than the language. It also has a first class object model, and yes - it is just as happy in the functional or structural programming model as the object oriented one.

Also in answer to the main question, yes the examples you are giving are too small, but combine 10 such filters into a workflow of data processing and you might start to see some of the value of object-orientation. As the richness of data-sets increases, and the complexity of the algorithms to work on them increases, object-orientation is a way of staying on top of the complexity. It is also more of a "simulation" approach to breaking down the problem, think of a real world solution and simulate it - it is no accident that smalltalk (one of the early O-O languages and still one of the best) evolved from the language simula.

Re:what should i use? (2)

redhog (15207) | more than 12 years ago | (#2779370)

Why not learn Scheme [] ? It is weel suited for implementing recursive algorithms in a straight-forward way. Also, may I suggest learning some logic-based language, like prolog, with a finite domain solver included (as the one in gprolog [] )? I don't know, since I'm no engineer, but I can imagine a finite domain solver being usefull for engineering tasks (it can be used for e.g. scheduling several tasks to reduce resource usage and the like).

Re:what should i use? (0)

Anonymous Coward | more than 12 years ago | (#2779405)

forget the language..
ProE, you'll get a high paying job

Complex Question... (5, Interesting)

Marx_Mrvelous (532372) | more than 12 years ago | (#2779242)

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.

Re:Complex Question... (2, Insightful)

taliver (174409) | more than 12 years ago | (#2779432)

However, you still end up writting 100 different functions in either case, and calling


seems no easier to remember than




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.

Different solutions to different problems (5, Interesting)

Crimplene Prakman (82370) | more than 12 years ago | (#2779248)

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

We may be human (0)

jfonseca (203760) | more than 12 years ago | (#2779332)

Prakman, nice sig, I wake up listening that song everyday!

Math objects are objects, too (5, Interesting)

mblase (200735) | more than 12 years ago | (#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.

OOP (-1, Troll)

utdpenguin (413984) | more than 12 years ago | (#2779250)

May I recomend to you the improved version of OOP called Object Oriented Programming Sucks (OOPs) and fill in many of the holes you are talking about. Youc an get more info Here. []

Perhaps the computational power is to be questionn (1)

aepervius (535155) | more than 12 years ago | (#2779254)

I am not experienced in OOP programming anymore, especially how good the compiler are now, but maybe OOP is mostly used for its inheritance in data structure , and reusability of the code (enhance UI, management problem etc...). On the other hand, physic and mathematic problem require usage of pure processing power on calcul. Maybe OOP would help add an UI layer, but using data structure with OOP in raw calcul might add an innacceptable "slow down".

Round peg, Square Hole... (3, Insightful)

einer (459199) | more than 12 years ago | (#2779257)

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.

Re:Round peg, Square Hole... (2, Interesting)

RTMFD (69819) | more than 12 years ago | (#2779361)

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.

Re:Round peg, Square Hole... (3, Insightful)

madmaxx (32372) | more than 12 years ago | (#2779414)

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.

need more specifics (1)

demian031 (466963) | more than 12 years ago | (#2779264)

if you are plugging numbers in and expecting numbers out then procedural would be just as good as anything.

but there might be other applications where oop will really pay off for you. one thing i can think of is possibly simulations.

i think oop was first used in northern europe (yeah before PARC) to simulate manufacturing systems.

Engineering Processes are Procedural (4, Insightful)

mheine (303013) | more than 12 years ago | (#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)

I think it's a problem of scale and understanding. (4, Insightful)

PHAEDRU5 (213667) | more than 12 years ago | (#2779271)

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.

any componentized program (2, Insightful)

mugnyte (203225) | more than 12 years ago | (#2779274)

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.


Not functional programming... (2, Informative)

Chris Parrinello (1505) | more than 12 years ago | (#2779276)

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.

Is it neccessary to be an end all be all? (2, Insightful)

syrupMatt (248267) | more than 12 years ago | (#2779281)

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.

Scope (1)

Liquid(TJ) (318258) | more than 12 years ago | (#2779287)

I don't think that OOP is intended to completly replace traditional language concepts, esp. on the function level. OO in my opinion really shines in dealing with relationships between objects or concepts, but the object classes themselves shouldn't always behave the same. I generally think of an object as a collection of data items and thier properties, but an "object" can also be a black box of functions that acts other objects, or any other set of properties that's approprate.

If a program's sole purpose it to generate numbers based on other numbers, I don't see any reason to force OO methods onto the system. But if it's part of a larger system, then you may want a class that behaives like an object to the world, but acts like a function set internally.

Engineer Boy = idiot (-1)

Tasty Beef Jerky (543576) | more than 12 years ago | (#2779289)

He doesn't know the difference between two and too...

See for yourself
I'll even be happy with the answer 'Your problems are two small and specialized to realize any significant advantages of OOP.'


It's a way of thinking (1)

JustAnotherReader (470464) | more than 12 years ago | (#2779292)

Once you learn OOP and truly "grok" the meaning of OOP you'll wonder why you ever coded any other way. It's difficult to answer the question "What's the businessw case for OOP" because we're not talking about how to build a more efficient web server, we're talking conceptually about design, implementation, and code re-use.

So there's no easy answer. Unfortunatly, the real answer is to spend a year or two coding in C++ or Java and becoming familier with OOP concepts. Then you'll be able to answer your own question.

Engineering DOES use OOP. (1)

S≤ (145132) | more than 12 years ago | (#2779295)

Maybe its just us new eggs, but I've only been taught using OOP, through MATLAB code, which is almost the same as C/C++.

The City of Palo Alto, in its official description of parking lot standards,
specifies the grade of wheelchair access ramps in terms of centimeters of rise per foot of run. A compromise, I imagine...

OO / Not OO - who cares? (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2779299)

if (question == lame) {;
x = random() mod 5;
switch x;
1: cout << "This is cool!";
2: cout << "I wonder if you can run linux on it?!";
3: cout << "Too bad I don't have a windows box to try it on."
4: cout << "Update: Oops, we ran this two days ago. My bad."
5: cout << "I've been playing (windows only game) nonstop for three weeks. It rocks."

How can we answer that... (2, Insightful)

Katravax (21568) | more than 12 years ago | (#2779301)

...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.

Re:How can we answer that... (1)

DrSkwid (118965) | more than 12 years ago | (#2779437)

try looking at javascript sometime

Stick with Fortran (0)

CmdrTuco (537085) | more than 12 years ago | (#2779305)

Despite what the 13 yr old computer science experts on Slashdot might tell you, Fortran (esp. Fortran 77) rocks. Stick with it. Remember the KISS principle.

OOP solves Software Engineering problems (5, Insightful)

soboroff (91667) | more than 12 years ago | (#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 (3, Interesting)

Henry V .009 (518000) | more than 12 years ago | (#2779314)

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.

Assembler then? (0)

Anonymous Coward | more than 12 years ago | (#2779344)

...............or Forth maybe?

Objects are not just modeling metaphors (2)

big.ears (136789) | more than 12 years ago | (#2779317)

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.

OOPs (I did it again) (5, Insightful)

CaptainAlbert (162776) | more than 12 years ago | (#2779319)

Take a look at BLITZ++ [] , 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 (2, Interesting)

Anonymous Coward | more than 12 years ago | (#2779322)

Read the following book:

Object-Oriented Implementation of Numerical Methods: An Introduction with Java & Smalltalk
by Didier H. Besset

Complex Number Support (2, Informative)

WimBo (124634) | more than 12 years ago | (#2779325)

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.

OOP == encapsulation ... (4, Informative)

srealm (157581) | more than 12 years ago | (#2779326)

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.

One example (2, Insightful)

bapya (190846) | more than 12 years ago | (#2779327)

One example that comes to my mind immeiately is MMTK ( link [] ) (Molecular modeling tool kit) developed in python by Konrad Hinsen.

Maybe (1)

JMZero (449047) | more than 12 years ago | (#2779329)

OOP isn't going to help you solve your math problems, for the most part. If you're dealing with a lot of objects, it could clarify things. For example, if you had physical objects with a list of properties like dimensions, temperatures, etc... you have a few options.

You could have parallel arrays, like

double nObjectX[100] (array to be clear)
double nObjectSpecificHeat[100]

This would certainly work, and you could write functions to work with data as it is here.

But if you thought of all of these as properties of one object, (ie Object.X, Object.SpecificHeat), you could:

- pass them to your functions more easily
- make your code more clear
- impress your programming friends

It could be that none of the above will help you at all. There is, by definition of how computers work, nothing that you can do with OOP that you can't do without it. And lots of time it's more effort for the same product.


Re:Maybe (0)

Anonymous Coward | more than 12 years ago | (#2779441)

If all you need to do is store related properties together, then an array of structs would do the trick.

Depends greatly on the problem (1)

gila_monster (544999) | more than 12 years ago | (#2779333)

There are some areas where OOP is considered undesirable. The avionics industry, for example, makes very limited use of OOP because certain aspects (garbage collection, dynamic allocation of resources, & others) raise safety-of-flight issues. Certification authorities prefer things more controlled, as plane crashes are generally considered a bummer.

This is also why the aviation industry doesn't adopt new technologies quickly. It prefers to wait until they have a proven service history. The 486 is stilled widely used in the industry, for example.


An example (1, Interesting)

Anonymous Coward | more than 12 years ago | (#2779340)

This is "just" numerical code, but maybe will give you some ideas: (Blitz++)

Wil Wheaton, actor, dead at 28 (-1)

Wil Wheaton (532837) | more than 12 years ago | (#2779343)

I just heard on the radio that Richard William Wheaton III (Wil Wheaton's full name) was found dead today at his home in LA. We will all remember his wonderful performances as Wesley Crusher on Star Trek:TNG and Gordie Lachance on Stand By Me. Wil has contributed much to society, and I'm sure he will be greatly missed by the readers of Slashdot

sure it can but (5, Informative)

kaisyain (15013) | more than 12 years ago | (#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.

Fortran already has most of the objects (1)

tshoppa (513863) | more than 12 years ago | (#2779347)

Fortran already has most of the really basic objects used to solve engineering/numerical analysis problems: Integers, reals, arrays, matrices, subroutines, functions, etc.

Object-oriented languages are so popular at the moment because it's a way of adapting a language to a new problem domain (keep in mind that C was written to write an OS kernel, and it's only through bad luck that folks are using an extended version to do everything under the sun today).

But just as C++ and Java are (slowly) displacing COBOL for business applications, I think we'll see object-oriented code displace Fortran and C for number-crunching. (Remember, COBOL was written specifically for Business applications!)

I honestly don't know of a good book on numeric computation that is truly object-oriented. The current edition of Numerical Recipes in C++ doesn't really take advantage of everything you can get from an OO approach. Maybe the new edition of Numerical Recipes in C++ [] will do a good job at this. Still, the current version shouldn't be ignored, there are some good ideas about how objects can really help in large computational challenges.

"Engineering Problems" is awfully vague (1)

avdi (66548) | more than 12 years ago | (#2779354)

To the question "Can OO programming solve engineering problems", I would answer an emphatic yes. However, the engineering that I do at my place of work has to do with coordinating RADAR tracks in an air traffic control system, among other things. OO principles are applied to this domain with excellent, elegent results. The problems you are talking about (though I don't pretend to understand them) sound like very specific mathematical ones which are probably best solved in a procedural fashion, perhaps packaged up neatly into a class. However, just because it's the only engineering problem you are faced with, don't make the mistake that OO design principles cannot be applied to any engineering problem domain.

Computational complexity vs Conceptual Complexity (5, Interesting)

Mr. Fred Smoothie (302446) | more than 12 years ago | (#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.

a turbine engine modeling application (1)

Nehemiah S. (69069) | more than 12 years ago | (#2779369)

When I worked at AEDC [] I spent some time involved in NASA Lewis (now Glenn)'s numerical propulsion system simulation [] project. The idea of this project was to apply OO principles to turbine engine modeling.

Each component of a modern engine was viewed as an object (compressor, turbine, burner, etc). The solver could use helper aplications of any complexity to model components, then tie them together (very useful for integrating proprietary codes with a common architecture).

I could talk a lot more about it but it has been years and it would be better for you just to follow the link...


Different Problems, Different Languages .... (0)

Anonymous Coward | more than 12 years ago | (#2779377)

It could be that the OO methodology simply isn't applicable to the problem area you're interested in. OO is fine for describing/developing some parts of a system, but not for others parts. Just as functional or logic based formalisms are good at some parts and bad at others ...

You sorta get it (1)

KurdtX (207196) | more than 12 years ago | (#2779380)

Each of the examples you give is essentially a function (ok I'm not 100% familiar with everything you mention, but from what I know...). In OO design, each of these would be a discrete "building block", think of each as a specialized calculator. Now if you're just trying to solve a single equation, (in my opinion) yes it is too small for full blown OO.

However, if you have a function that say, needs to do many integration, derivation, or whatever steps, you can write an object instead of just doing a function. The advantage of writing a integration object instead of just a function is that you are forced to pass in all of your data, and thus the object is reusable (it in effect becomes a library). You could include in the same object many different types of integration, single, double, Legrande, although I would separate out derivatives.

I guess another (abstract) way to relate it is to buying a new computer. You can either go to Dell (or whomwever) and buy a new package every time and pay a premium, or you can just upgrade one module at a time - your hard drive isn't big enough, get a better one, not enough RAM, get some more, etc.

And if anyone wants to flame me about how this will lead to a legacy system let me point out that: a) Linux runs on a 486; b) it's just an abstraction!

OOP numerics page (0, Redundant)

guybarr (447727) | more than 12 years ago | (#2779383)

look here:
(not just blitz there)

You don't understand what OO is (3, Insightful)

Papa Legba (192550) | more than 12 years ago | (#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 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."

The act of learning (5, Insightful)

pdqlamb (10952) | more than 12 years ago | (#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.

Object-oriented programming was invented for this (5, Informative)

cananian (73735) | more than 12 years ago | (#2779389)

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.

OO is better for big stuff (2, Informative)

jpmorgan (517966) | more than 12 years ago | (#2779390)

'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. :)

different equations for different data. (0)

Anonymous Coward | more than 12 years ago | (#2779391)

Using polymorphism if you have different types of data to solve certain problems you can use your objects to create multiple inputs with the same name, just different data type inputs.

quants do it by the numbers (1)

Rocky Mudbutt (22622) | more than 12 years ago | (#2779397)

An excellent example of complex mathematical algorithms implemented with an object model is the quantlib project. Financial modelling is a kind of engineering, although usually more rewarding monetarily than electrical engineering.

From their front page:
The QuantLib project [] is aimed at providing a comprehensive software framework for quantitative finance. QuantLib is a free/open source library for modeling, trading, and risk management in real-life.

QuantLib is written in C++ with a clean object model, and is then exported to different languages such as Python and Ruby. Bindings to other languages (including Java), and porting to Excel/Gnumeric, Matlab/Octave, S-PLUS/R, COM/CORBA/SOAP architectures, FpML, are planned for the near future.

A mech. eng. example (0)

Xner (96363) | more than 12 years ago | (#2779399)

OO programming is just a though pattern, and it can be applied to almost any problem. Let's consider an example you're probably familiar with, a finite element program.

In a finite element program you would probably have an object "Mesh" that holds all your elements. Now as you probably know you can have all sorts of different element types with different solution methods. These can all be implemented as subclasses of an abstract "Element" class. A method element->solve() (or solutionIteration() or similar) would then take care of hiding the different solution methods from the higher layers of the program.

If you want you can extend this method even further, implementing a Node object that can be shared by multiple elements. By subclassing the nodes you can implement things like boundary conditions.
You see, the problem now becomes a connected forest of objects that are rather uniform, but can have their own specific rules of behaviour when needed.

I'm not saying this is not possible with regular procedural code, people have been writing procedural finite element simulations for years. What i'm saying is that if you want to bring some architectural sanity into the world of computational science (and god knows it needs it...) OO might help.

Note that if for whatever reason you cannot/do not want to use an OO language, you can still think OO. You can then implement the thing using a regular procedural language that has some way of keeping data together in a logical way. Structs in C are perfectly suited for this task. This way you might miss some of the neat OO features, but the resulting code will at least have the advantage of keeping data and related code together.

Ought to Work (0)

Anonymous Coward | more than 12 years ago | (#2779402)

From the 1920's through the 1960's it was quite common to solve engineering problems with analog computers. Some analog computers were mechanical and others were electronic. These machines were inherently object-oriented. One built the program by connecting together components (objects) into a model of the system of interest, and then observed the results. If O-O software hasn't reached this level of capability yet, maybe there's a problem with the way we do O-O.

general software engineering practices (1)

RussRoss (74155) | more than 12 years ago | (#2779404)

It's not necessarily a matter of mapping a specific engineering problem to an OOP model that will yield benefits. I see OOP as valuable for any large software project even if the problem itself is not particularly object based. User interface code maps better to OO designs and collaboration in a developement team tends to work more smoothly with an OO framework. I think it is in the general construction of an application that OOP will give benefits (if used properly) rather than in the specific solution to a specific problem. In that sense, any engineering application could benefit. For small problems (and small applications) I generally use an imperative language like C or Perl, but for larger projects I favor a OOP approach.

- Russ

Depends on what you define as a problem.. (2)

zulux (112259) | more than 12 years ago | (#2779409)

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.

OO wins if the problem is subject to factoring (2)

west (39918) | more than 12 years ago | (#2779410)

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.

Depends on your situation (1)

Hasie (316698) | more than 12 years ago | (#2779413)

I'm an electronic engineer and a little while back I was playing around with an algorithm for designing impedance matching networks (circuits that make one impedance look like another one). The network can consist of series inductors, parallel inductors, series capacitors and parallel capacitors. I implemented each of these components with an object. So OOP can be used for some engineering programs!

On the other hand, heavy duty computations are probably not well suited to OOP because there is a very slight overhead involved with using objects. This small overhead can be multiplied a HUGE number of times for very large problem and can increase the computation time and memory requirements. That's one of the reasons FORTRAN is still so popular for heavy duty calculations: it's very simple and has no unnecessary overhead to speak of. Add to that the fact that it was designed for heavy duty mathematical work in the first place and you have a winner.

Just my opinion mind you!

to explore this in more depth. . . (1)

mjackson14609 (69635) | more than 12 years ago | (#2779417)

. . .take a look at some issues of Computing in Science & Engineering; they have a website [] , although much of the actual content isn't free. You'll find some successful OO applications there.

Sure -- What about FEM codes (1)

Perldivr (514838) | more than 12 years ago | (#2779418)

For my Master's Thesis (in ME) I created a FEM applet written in Java. OOP works well for this application since elements can be treated as objects. In theory, you can add new element types to your code by creating a new object with an appropriate interface.

OOP also helps with mathematical entities. Java lacked a suitable Matrix class for Force and Stiffness matrices. Luckily, OOP made it practically trivial to create new classes to not only hold the numbers, but to also encapsulate matrix algebra. Want to multiply a matrix by another? You can easily do something like this:

myForceMatrix=myStiffnessMatrix.multiply(myDispl ac ementMatrix);

In short, I found OOP concepts very helpful for my Java finite element applet.

- Perldivr

OO in engineering (1)

obuyukis (547707) | more than 12 years ago | (#2779422)

There are quite a few finite element programs in OO. Some CFD code too.

An instance where OOP helps (1)

truck (31834) | more than 12 years ago | (#2779423)

I use various methods of solving partial differential equations in large scale applications like segmentation of medical images. As I am sure will be expanded upon by others, OOP methods do not help to solve the problem per se, but they can make coding and debugging much easier. With complex algorithms that can be the difference between a single researcher applying the algorithm in a month versus 6 months and having to get 2 or 3 others to help code.

An example:
I have a Data class that can store itself (serialize) in a standard scientific data format, like HDF and can perform other various tasks (get, set, null all values, add, subtract, etc). Now I might have subclasses that specialize to vectors, 2D arrays, N-dimensional arrays, etc. The basic functionalities are inherited and once tested will be less likely to cause problems in other classes. Lets further say that these classes are parameterized, i.e. templates. Now the basic functionality works for floats, doubles, unsigned char's etc. I could of course get this same functionality with normal procedural programming, but in the end my colleagues and I will be more productive.

OOP is a tool, just like an oscilliscope or a strain guage. Not using it when appropriate is not good engineering practice.

Objects are things (1)

battjt (9342) | more than 12 years ago | (#2779424)

I've done programmnig for truck engineering support.

Objects are things like engines, axles, gears.

"finite difference solutions to differential equations, finite-volume computational fluid dynamics, iterative solutions to non-linear equations, Monte-Carlo simulation of radiative heat transfer" are process to be run on objects. They may be objects also, but OO is best at helping you organize you data.

My experience with IT supporting engineers is that engineers first think of the process, then the data (data may be denormalized data sitting in some table somewhere, but here is the math that we want to perform on every row) and IT concentrates on organizing the data (here is an efficient datamodel for that data that you want to perform some operation on). See how OO would better fit the needs of the IT staff?

The trick is understanding what engineering wants to do with data, so your object models facilitate their computations, not get in the way.

The work I did was to model the truck, then using math supplied by engineering, we performed simulations with our models. The advantage was that engineering couldn't do the simulations alone because they couldn't get their minds around the vast amount of data and we couldn't do the simulations, because we didn't know the behaviors of the materials.

We acutally had objects like a transfercase that had a bracket location, gearRatios, input location, output location, currentGear, inputRPM, outputRPM, etc. Some of these values were calculated and some we given depending on the type of simulation. The trick was deciding when to calculate values and when to use cached values. (we used a dependence graph that was implicitly constructed) Are simulation would include activities like running the engine through the RPM range and each gear of the transmission, and articulate the rear axle through its positions to find binding in the drivetrain. Using these simulations we were able to select some parts (is this axle better than the previous?)


Stuff (0)

Anonymous Coward | more than 12 years ago | (#2779425)

OOP is good for big programs with complex workflows. When you have 50-1000 developers working on a single product you need to devide their job. For these projects OOP is a must. Even if you work on a project alone you will be more organazed by using OOP. OOP can also be used to improve reuse of the code, but I rarly see a library that is designed well enough to use it. Well designed libraries usualy designed in such way that mistakes are not easily made. If you not sure why OOP might make you program better, you probably will be better off not using it. This exspesialy true if you procedural way of programming gets job done..

Pragmatics... (2, Insightful)

Yoda2 (522522) | more than 12 years ago | (#2779429)

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.

Industrial Engineering Example (1)

jstarr (164989) | more than 12 years ago | (#2779433)

Although Industrial Engineering (IE) reflects different problems than your more mechanical examples, IE is definitely engineering and its problems can be solved (conceptually) better with OOP. Why? Because IE deals with large-scale simulations involving multiple discrete parts. The systems cannot (typically) be represented by a system of differential systems, and instead must be modelled as independent parts communicating with each other. In other words, these are complex systems.

For example, I'm a research assistant in a project studying realtime promising. (Essentially, this project is looking at ways to determine the due date of an order quickly and accurately. This way we can avoid saying 6-8 weeks to deliver...) Although the different algorithms and heuristics could be included in a procedural or functional paradigm, the overall size of the system (>10,000 lines) along with the complex data types (some with more than 20 attributes) lends itself best to OOP. Earlier versions of the code were written in a more procedural fashion, but by moving toward a more OOP framework the code has become simpler and easier to manage.

Additionally, since this is research software, ease of making changes is a high priority. It is easier to be able to make changes to key systems without disturbing other code within an OOP system than with procedural or functional code. If the system was already well-understood, then a straight-forward procedural solution might be preferable.

I would like to add that my statements about functional programming do not include functional programming with objects (ala CLOS).

We do it! (5, Interesting)

Bill Barth (49178) | more than 12 years ago | (#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 [] (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 [] 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.

Speed of OOP... (2)

Bonker (243350) | more than 12 years ago | (#2779440)

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

HA (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2779443)




Design Analysis, not Problem Solving (3, Interesting)

franimal (157291) | more than 12 years ago | (#2779447)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>