What is the best design pattern for this problem?

[elrathia]

No code to go with the question. I am trying to settle on the best design pattern for the problem before I code. I want to use an Object Oriented approach.

I have included a basic UML diagram of what I was thinking so far. 

Stated simply, I have three devices; Module, Wired Modem, and Wireless Modem.

In the Device Under Test parent class, I have put the attributes that are variable from device to device, but common to all of them.

In the child classes, I have put the attributes that are not variable to each copy of that device. The attributes are common across device types. I was planning to use controls in the class definition that have the data set to a default value, since it doesn't change for each serial number of that device. For example, a Module will always have a Device Type ID of 1. These values are used to query the database.

An example query would be [DHR].[GetDeviceActiveVersions] '39288', 1, '4/26/2012 12:18:52 PM'

The '1' is the device type ID, the 39288 is the serial number, and the return would be "A000" or "S002", for example.

So, I would be pulling the Serial Number and Device Type ID from the Device Under Test parent and child, and passing them to the Database using a SQL string stored in the control of the Active Versions child class of Database.

The overall idea is that the same data is used to send multiple queries to the database and receiving back various data that I then evaluate for pass of fail, and for date order.

What I can't settle on is the approach. Should it be a Strategy pattern, A Chain of Command pattern, a Decorator pattern or something else. 

Ideas?

 

[Ben]

Full discloser!

I am physicist that never took a formal OOP course.

Now that I have that out of the way...

Why not use a Factory Pattern?

As long as you have method in the DUT that will be invoked on all of them, LVOOP will call the over-ride VIs depending on the class output from the Factory Pattern (sorta like Stategy I think).

Chain of Command and Decorator strike me as being overly complicated.

That's all I can offer off-hand.

If you make your case for the other design patterns you may convince yourself that you were right in the first place. If I get a chance I try to watch for others thoughts since I can stand to learn more about OOD.

Ben

[elrathia]

Hi Ben,

I have no formal training in it either. In fact I am so new that I am having trouble understanding your reply. I have been studying the Factory pattern that ships with LabVIEW but it is way, way over my head. In fact I must admit that the only things I have a grasp on are simple inheritance and what an Object and a Method and Attribute are.

I haven't much idea of how override works and when you would use it and why. I'm the newest of the new here. 

[Ben]

---

@elrathia wrote:

Hi Ben,

...

I haven't much idea of how override works and when you would use it and why. I'm the newest of the new here. 

---

Good. At least you will not be smaking with a OPPer dOOPer hammer if I make some gramatical mistake.

You may want to look at this thread in the BreakPoint where i trie to help Cory get a handle on Dynamic Dispatching with an example of two classes that inherit from a common parent and invoke Over-ride VIs to do the same thing but with wildly varying results.

The example uses a Class of "Numeric"  and a sibling class "Text" and the both implement an Add method.

It is dirt simple and Cory did a decent job of explaining it.

It just be the motivation you are looking for.

have fun!

Ben

[elrathia]

Wow, first time I've been to that board.

That's going to take some study. I will try to substitute some of my values into your code, if you don't mind, and  see if I understand the application of it. I don't understand why the add method has to be in all three classes but the Write A and Write B don't. And maybe that's the basic question, why does the Add method have to be in all three?

I'll be searching for the answer, but that's to let you know the fundamental level that I don't understand this all at. I am missing some awful, scary, basic thing that is blocking me from comprehending the whole subject and I haven't been able to pinpoint it yet.

[Yamaeda]

That's an effect of OOP in LV. In order to use the base class functions in the diagram the base class needs the function, though it can be abstract. Else you'll need to put the specific child function in the diagram and lose alot of the OOP beauty.

/Y