Object Oriented Programming

[linu95k]

Hi, 

I am new to Object Oriented Programming and I have a task of converting an existing procedural code to object oriented code.

What are the best practices to getting started migrating a procedural code to object oriented.

I tried to find resources for the same but most of the resources are for OOP concepts.

Thank you.

[crossrulz]

---

@linu95k wrote:

I am new to Object Oriented Programming and I have a task of converting an existing procedural code to object oriented code.

---

Why?  Changing the architecture of a program just to change from "procedural" to "OOP" is not a worthy excuse as it will likely require a complete rewrite.  Now if you wanted to add a Hardware Abstraction Layer or similar, that would be a reason to start using OOP in your code.

So instead of looking for resources on how to convert, why don't we just look at what the program is supposed to do and talk about what you actually need to solve the problem.

[linu95k]

I am doing this exercise just to test my understanding of the OOP concepts. Although I have studied OOP in theory now that I try to implement it. It seems like a whole new ball game.

My application performs the following tasks:

1. Read a Configuration File that contains Paths to other configuration file

2. Reads keys from respective configuration file

3. Authenticate/Add/Delete/Edit user details in configuration file

4. Runs a QMH based Test system that acquires data and writes data to a TDMS file

5. The test system has two type of measurement options namely Current and Voltage

6. The probes used for Current and Voltage measurement are different and the current probe further has multiple settings.

7. The report generation part also uses QMH to analyze the test data by reading it from the TDMS file and generates reports.

Problems:

1. Initially I tried to have a Generic File class as parent and have INI and TDMS classes as derived classes but I cannot do that since the interface for both would be different.

2. Functions for reading/writing INI files are not being reused since each has different key values of different datatypes.

3. The interface for Voltage and Current probe is also different therefore I am struggling with inheritance and dynamic dispatch.

4. The system uses multiple QMHs and I am not very comfortable with Command Pattern.

5. There are too many front panel controls and indicators.

At this point I am struggling with the planning phase itself. 

This is probably a dumb question but is there a standard approach to convert an existing code to OOP?

[wiebe@CARYA]

---

@linu95k wrote:

What are the best practices to getting started migrating a procedural code to object oriented.

---

Learn OO first.

---

@linu95k wrote:

I am new to Object Oriented Programming and I have a task of converting an existing procedural code to object oriented code.

---

This is right on top of the most difficult things to do.

Not only does it require good OO knowledge, procedural knowledge, but it also requires application, domain and customer knowledge. You need the last 3 to distinguish between requirements, features and bugs.

Best OO code comes from OO Analysis followed by OO Design (See Booch). Refactoring will almost inevitably cut these steps short.

If you really want to do this for learning purposes, get the requirements from the old application, and start over (with proper OOA and OOD). You could reuse code on VI level, there's no point remaking the exact VI...

If you have OO knowledge, you can separate 'modules' pone by one. But I wouldn't recommend learning this by doing a refactoring.

[jfalesi]

The best reason I've come up with for using an OO design is that it provides a template for your software architecture. If you already have an existing architecture that works for you, then stick with it. But if you find that your architecture is limiting your desired functionality - e.g. if you have a sequential architecture and you need to switch to a parallel architecture - then it might be worth switching to an OO design.

There are some conceptual hurdles to OO that will take some getting used to. For example, if you decide to use message objects, your component class VI's are called by your message class VI's, so it can look like the message VI's "own" the component VI's.

However, if starting from scratch, almost every application I've written is best architected as an event handler and one or more queued state machines, driven by messages passed over channel wires (easier to read and use than queues). This enables asynchronous messaging, which you'll probably eventually realize you'll need anyway. This particular architecture doesn't need to be OO, but using classes for messages and for your components (to encapsulate the persistent data required by the queued state machines) seems natural to me.

The only situation in which I've needed to deviate from this architecture is when I need dynamic multithreading (e.g. if you don't know at compile time how many queued state machines you'll need). In these cases, the Actor Framework is appropriate. For context, the AF encapsulates threads into objects, so they can be created and killed dynamically (like a java thread object).

[wiebe@CARYA]

---

@jfalesi wrote:

The best reason I've come up with for using an OO design is that it provides a template for your software architecture. If you already have an existing architecture that works for you, then stick with it. But if you find that your architecture is limiting your desired functionality - e.g. if you have a sequential architecture and you need to switch to a parallel architecture - then it might be worth switching to an OO design.

---

The great power of OO is that you can specify behavior by wire.

You can of course DIY this with e.g. an enum, but you can't extend functionality without changing the code that actually uses the functionality. With OO, you can add or change functionality without changing the old functionality at all.

This is why OO works really well in architectures. The architecture is fixed and the behavior can be added. You're changing behavior by wire.

Architectures are not the only use case though.

Anywhere where there's two options to switch between, OO can be very helpful. A physical device vs simulated device, A binary file and a text file (input or output), a table or a graph GUI, etc..

But the 2nd option doesn't even needs to be known when writing the 1st. Even a well written library is very unlikely to do exactly everything in exactly the right way for every purpose. If the library is a class, a child can extend functionality and\or change behavior.

Again, it's a crucial benefit of OO that the code using the class doesn't care at all about these extensions and\or changes. If the (child) class honors it's contract the code using it will work (if it worked before of course).