One problem with object oriented languages is

that objects usually are allocated on the heap.

That is a big linked list of free memory blocks.

If objects are created and destroyed continuously

in a non-stack-like, more or less random order

this might cause heap fragmentation. It is a problem

since at a certain time no big block of memory

will be available although the sum of all blocks

would be big enough.

OOP languages based on virtual machines

that use references instead of pointers and

garbage collectors might rearrange the objects,

restructure the memory heap, but this would

result in unreliable execution times. One never

knows when garbage collection is performed

or how long it takes.

Regards,

Joachim

Malika, Joachim makes some excellent points - especially in regards to memory and garbage collection (GC). When I worked on embedded programs many years ago, there was a limit to the amount of memory that could be installed on a device, so use of dynamic memory allocation was limited. Much will also depend on whether the environment supports virtual memory - or if you are limited to only what is actually available. Since OO often implies dynamic memory allocation, understanding your target device and environment will be critical to success/failure of the method you choose.

Many years ago when I worked in the US Defense Industry, several of us had a discussion about software used to track/intercept incoming targets. The question raised was how often does GC run and when, because if we were limited to N objects for tracking (due to memory constraints), what happened when target N+1 was acquired. Assuming GC ran after N objects were allocated (cleaning up those that were no longer necessary), then would it run fast enough to be able to reallocated when that N+1 target was encountered.

I know that GC has improved significantly since those days, but when you are doing embedded, real-time programming, external factors and your target environment have an impact on your design methodology.

When designing a complex nature of embedded system i think if you are a performance base person you can go in for structured oriented which is also an example of a procedural language but it disadvantage is that its not maintainable, extensible, reusable as compared to Object Oriented language which is maintainable. reliable,extensible,reusable etc. OOP makes code readable than structured and also makes different part of the system to be seen as object. It is also easier for you to modify some part of the program to relate to other part of the system. OOP also perceive the way human thinks and it will be easier for you to work in that language.

Sir , (Jerrold (Jerry) Heyman & Joachim Pimiskern) thanks for ur  words in this Regards.

Nana Yaw , thank you.

you are right in Performance regarding, i 'll must choose Structured. both hv Advantages as well Dis advantages but seem to like as OOP is most powerful. Coz, it hv many features (re usability n maintainability) which make it more preference than Structured.

As far as my thinking approach, Structured methodology is much Better in case of just private using means wherever, we just hv limited approach to use it. in such criteria Structured methodology is the Best Option.

What's opinion more??

By my view, OOD/OOP and memory management choices are two substantially separate things. You can certainly organize your design in terms of classes and methods and not do a whit with dynamic memory allocation or roll your own memory manager. You can even do it without using an OOP language per se, though it is certainly easier if you do use one, e.g. C++. Granted you might find it not the "beaten path" but if your system is more expressable in terms of classes and methods, I believe you will pay a price for shoing it into a structured design approach.

Of course object-oriented modeling using UML specification will be the preferred one. It has more advantages to offer - reusability, maintainability etc.

Of course object-oriented modeling using UML specification will be the preferred one.

This looks like a question for an assignment. It's not appropriate to answer.

(David Abbott) yes sir, no doubt u said well;

" though it is certainly easier if you do use one, e.g. C++. Granted you might find it not the "beaten path" but if your system is more expressable in terms of classes and methods, I believe you will pay a price for shoing it into a structured design approach."

Gratitude to all of u to sharing ur analysis es & experience.

(Christopher Johnson) no doubt sir, its an assignment question.

its not mean to follow others without our own analysis & knowledge.

but hv always the intention to gaining different point of views as well keep in mind our own ideas about related topic. Base & Ending is always our own hardworking n searching.

Its just the way, to collecting many ideas and making a strong decision in base of our "specific point" where we reached. otherwise, i didn't raise any question in rest of discussions & after due date.

so, its just polishing our ideas with real world problems & experiences.

also students hv right to take ideas, for making their assigns...from any where..

Thanks & Regards!!

Object orientation leads to designs with lower contextualisation than traditional structured techniques and from that perspective are more flexible. However, I have seen very few people ever do object-oriented design. Most of them do class-oriented design — which is just another structured technique.

You can tell that someone is doing an object-oriented design because they design and program objects instead of classes. Anything else is arguably structured design; then your ability to deal with emergence and complexity will depend (as it always does) on secondary features that are not directly related to the paradigm.

Class-oriented code is much less readable than structured code because you get to see such a small part of the use case at a time. Good OO methods are small — five to ten lines long. Each method likely invokes other methods. The problem is that, because of polymorphism, you can't determine from the source code which actual method will be selected by that method selector. So you can't reason about system-level operations. In a structured program, you can do such reasoning statically. But, of course, that increases contextualisation which lowers flexibility.

The devil is in the details. Most OO programs now behave better than most (traditional) structured programs because of the emphasis on data cacheing in modern processor architectures. Early studies with C++ showed that it outperformed equivalent designs written in C — largely because of the optimisations of a more rigorous type system. Don't every make assumptions about performance on the basis of paradigm or anything else: measure, measure, measure.

very well description Sir(James O Coplien)

welldone..

"Anything else is arguably structured design; then your ability to deal with emergence and complexity will depend (as it always does) on secondary features that are not directly related to the paradigm."