Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 83 of 181

more time, up front, doing ,design work. wi th System; with Opsys; package Light is type Object is tagged private; function Create ( Theaddress Themask return Object; procedure Turn_On ( This: in out Object); procedure Turn_Off ( This : in out Object); private type Object is tagged record Address Mask Is_On end record; end Light; System. Address; Opsys.Unsignedshort; BooLean := FaLse; We plan before we program. But it's not OOP tllat requires more planning. It's the whole idea of writing software correctly. Analysi and design are also supposed to be used in otller programming para- digms, they just often aren 't System. Address; Opsys.Unsignedshort) • Object-oriented programming Tequires 'ln01· e time to code a soLution. In describing why this is an issue, Mr. Niemann points out mat it takes time to understand polymorphism and inheritance, Neither polymor- phism no r inheri tance are require- ments for writing object-oriented programs. If a programmer designs an effective solu tion, the idea of polymorphism can be built in as appropri ate. If you make eve ry solution use inheritance and poly- morphism it may become more complex. But why do that? I suggest using these fealllres of the lan- guages only when appropriate cedures in C++ you must use a class. You can, of course, put some pro- cedUl-es LOgether with some data that they manipulate, but the only way to ensure that the data manip- ulation is always happening within the proper code is to use a class. In Ada95, you have several options. Data and pr·ocedures can be grouped with or without us ing the inhe.-itance mechanism • Objects aTe needed when implf'lllenting laTge IJrogrmns. The idea of imple- menti ng a very large system (in today's terms) without taking advantage of encapsulation, abstraction, hierarchy, and modu- larity is absurd. The advantages you gain from using object-oriented technology are sU-ong enough to consider their use • Objects are easier to maintain. I agree that if I were developing a small piece of ode that had no other code depending on it, then making it a class would complicate matters. But if I have any code (other mod- ules) that depends on the function- al ity J am producing, the entire effort is much easier to manage with object-oriented technology. When speaking of maintaining an individual class, yes the work is ha rdel-. But when it comes LO main- ta ining an entire system, the wOI-k becomes ea ier • The switch statement is bad. Here, 1 agree witll Mr. Niemann, tl1ere is nothing wrong Witl1 C++'s switch tatement (or tlle corresponding "case" statement in Ada95). However, I've never even heard of uch an OOP mytl1 before. In fact, it should be clear that when develop- ing real-time sy terns, you can always know how long a switch or a case statement will take in the worst case. If you are using dynamic rUIl-time dispatching through inheritance, it is much harder to detennine what will happen ahead of time According to Mr. Niemann, lhese are the fa cts about OOP: • ObjPct-orienlNL j))vgrm/lming rl!quires 82 OCTOBER 2000 Embedded Systems Programming • Object-oriented pmgrwmning results in a //lore compLex soLution. When Mr. Niemann recommends tl1is, I need to ask what is mcan t by a more com- plex solution . Harder to use? Harder to understand? I've been arOllIld procedund programs enough to know that it would cer- tainly become a much simpler world when changes tl1at I make do not impact the entire application, Coding in an object-oriented lan- guage, whetl1er it be Ada95 or any otl1er, limits the impacllhal changes made LO one pan of the code wi ll have on tlle rest of the system • Object-oliented lJ1vgmmming results in code that is //lore jJmne to envr. Mr. Niemann makes this claim based on tllC fact lhat he has proven object-oriented programming to be more complex witll his example. If you are only lalking aboul a 100- line program, il's more complex to develop usiug classes in an objeCl- oriented language. But on a gralld scale, objecl-oriented program- ming reduces complexity and loc

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11