Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
OOP - grouping classes

Subject: OOP - grouping classes

From: John Kreuder

Date: 8 Jul, 2009 15:48:01

Message: 1 of 4

I want to make an array of objects, but my objects are of different classes. I am modelling thermal systems and each of my objects represents a different type of component (compressor, turbine, pump etc). For this reason, combining the objects into a single class is not an option. I need to be able to vary the number and type of components in a system. I am trying to find a way to assign data to each object using recursive methods, and if I could get all of the objects into a single array, this would be easy. Does anyone know of a workaround or do you any suggestions for an alternative approach?

Subject: OOP - grouping classes

From: Eric W

Date: 8 Jul, 2009 16:22:12

Message: 2 of 4

"John Kreuder" <gedoboarder@hotmail.com> wrote in message <h32f3h$qp6$1@fred.mathworks.com>...
> I want to make an array of objects, but my objects are of different classes. I am modelling thermal systems and each of my objects represents a different type of component (compressor, turbine, pump etc). For this reason, combining the objects into a single class is not an option. I need to be able to vary the number and type of components in a system. I am trying to find a way to assign data to each object using recursive methods, and if I could get all of the objects into a single array, this would be easy. Does anyone know of a workaround or do you any suggestions for an alternative approach?

You answered your question in the second sentence:

You are "modeling thermal systems and each of my objects represents a different type of <COMPONENT> (compressor, turbine, pump ect).

If all of your objects are "components" as you defined them, OOP style would then dictate that there is a parent class of your individual components called "component" that has members and methods common to all of your individual components. Your individual components are then defined as a child class of "component" with individual characteristics, members, and methods.

At that point, you can have an array of "components" and either have polymorphic methods that deal with "components" by class, or you force all of your components to have interfaces similar enough that a method called on ANY component will work.

This is simply the answer to your question from the viewpoint of your subject "OOP - Grouping Classes". Actual implementation and user results may vary.

Subject: OOP - grouping classes

From: John Kreuder

Date: 8 Jul, 2009 19:30:17

Message: 3 of 4

"Eric W" <gmail@ewilliams2006.com> wrote in message <h32h3k$2hc$1@fred.mathworks.com>...
> "John Kreuder" <gedoboarder@hotmail.com> wrote in message <h32f3h$qp6$1@fred.mathworks.com>...
> > I want to make an array of objects, but my objects are of different classes. I am modelling thermal systems and each of my objects represents a different type of component (compressor, turbine, pump etc). For this reason, combining the objects into a single class is not an option. I need to be able to vary the number and type of components in a system. I am trying to find a way to assign data to each object using recursive methods, and if I could get all of the objects into a single array, this would be easy. Does anyone know of a workaround or do you any suggestions for an alternative approach?
>
> You answered your question in the second sentence:
>
> You are "modeling thermal systems and each of my objects represents a different type of <COMPONENT> (compressor, turbine, pump ect).
>
> If all of your objects are "components" as you defined them, OOP style would then dictate that there is a parent class of your individual components called "component" that has members and methods common to all of your individual components. Your individual components are then defined as a child class of "component" with individual characteristics, members, and methods.
>
> At that point, you can have an array of "components" and either have polymorphic methods that deal with "components" by class, or you force all of your components to have interfaces similar enough that a method called on ANY component will work.
>
> This is simply the answer to your question from the viewpoint of your subject "OOP - Grouping Classes". Actual implementation and user results may vary.


Sounds like a good idea in theory, but I was unable to implement it because the methods of each component would take too long to massage into a common form. Instead I tried using abstract methods in the component superclass, but then I couldn't create objects of type component anymore. I've done some additional testing and I think I may have found a workaround:

By using eval(['string' '.method(arguments)']) where string is a string with the same name as an object, I think I'll be able to use an array of strings instead of an array of objects to do what I want.

Does anyone see any problems with this approach?

Subject: OOP - grouping classes

From: Doug Schwarz

Date: 8 Jul, 2009 19:46:48

Message: 4 of 4

In article <h32s49$hrp$1@fred.mathworks.com>,
 "John Kreuder" <gedoboarder@hotmail.com> wrote:

> By using eval(['string' '.method(arguments)']) where string is a string with
> the same name as an object, I think I'll be able to use an array of strings
> instead of an array of objects to do what I want.
>
> Does anyone see any problems with this approach?

Yes, it uses eval.

Can't you just put your objects in a cell array?

c{1} = obj1;
c{2} = obj2;
x = c{1}.obj1_method();
y = c{2}.obj2_method();

--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us