?
Solved

Is this a valid technique?

Posted on 1999-06-25
11
Medium Priority
?
181 Views
Last Modified: 2010-04-02
I have a problem that involves converting data from one type to another (type in the physical not in the code sense).

The example added as a comment below gives an example of the structure I have come up with.

What I would like thoughts on is:

      i) Is it reasonable to keep the headers for the derived classes in the implementation file? (The reason I reckon this is OK is because I don't want anyone to create instances other than via the base classes factory method - and it cuts down the need for lots of files).
       ii) Is there a better way to do it?
      iii) Is there anything wrong with it?
0
Comment
Question by:jasonclarke
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
11 Comments
 
LVL 7

Expert Comment

by:KangaRoo
ID: 1198452
what example?
0
 
LVL 9

Author Comment

by:jasonclarke
ID: 1198453
the example relating to the question:

in the header (.h) file:

enum DataType { A list of the possible data types here };

class DataConverter {
public:
   static DataConverter* CreateConverter(DataType src,
                                         DataType dest);

   virtual double Convert(double value) = 0;
};

amd in the implementation (.cpp) file:

class Type1toType2Converter {
public:
    virtual double Convert(double value);
}

// Other type converter class definitions here...

// then the factory method...
DataConverter*
DataConverter::CreateConverter(DataType src, DataType dest)
{
    if (src == Type1 && dest == Type2)
      return new Type1toType2Converter;
    if (src == Type2 && dest == Type1)
      return new Type2toType1Converter;

    // etc...
}

// and then implement the Convert functions for each type, e.g.

double
Type1toType2Converter::Convert(double value)
{
    return 2*value;
}

// etc....


0
 
LVL 9

Author Comment

by:jasonclarke
ID: 1198454
KangaRoo, you were a little too fast there, it was only a minute between question and comment!
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
LVL 7

Expert Comment

by:KangaRoo
ID: 1198455
i) I have absolutely no objections to keeping the declarations in the implentation file. On the contrary, it does limit the header depancies etc...

ii & iii) Depends on what you want. The method you choose makes it 'difficult' to add conversion functions, they all have to go in the one implementation file. This is no problem if there are only a few and they are rarely changed or extended.

I have an intiutive disliking of enumerations and swith-case like constructions. Are these physical types in some way encapsulated?
0
 
LVL 7

Expert Comment

by:KangaRoo
ID: 1198456
An alternative method is to associate each valid conversion with a FactoryObject. Each new conversion class could register such an an object together with a key indicating the conversion.
0
 
LVL 9

Author Comment

by:jasonclarke
ID: 1198457
No the types are not really encapsulated the object that holds the data for the type is fixed (and I don't want to change it) the conversion operates on  the members of the structure - the conversions are akin to unit conversions, but there is more data involved.

(The data is actually Fluid data and the conversion is conversion between fluid types, so the possible conversion types are limited.)
0
 
LVL 6

Expert Comment

by:Triskelion
ID: 1198458
No, there is nothing wrong with it.  Maybe a little cluttered.

What about adding associated documentation in a README.TXT or Windows HELP file?

0
 
LVL 9

Author Comment

by:jasonclarke
ID: 1198459
I was hoping for a little bit more that 'Yes its OK,'

its is cluttered because the code is purely an example for the sake of the question, so adding a Windows Help File to code that will never actually be compiled or run by me maybe a little excessive!
0
 
LVL 7

Accepted Solution

by:
KangaRoo earned 150 total points
ID: 1198460
The technique is valid. Using a factory method is very Ok I think

As I mentioned maintenance and extension with new conversions may become a bit tedious but I expect no problems if there are only a few conversions to be implemented.

If (in a couple of weeks) yourself pondering on how the CreateConverter method decides on which specific object to create, then change the design (the interface can remain).
0
 
LVL 22

Expert Comment

by:nietod
ID: 1198461
I agree that this is a good technique.  I use it in my libraries as I'm sure many others do.  There are numerious advantages to it, like faster compiles of code that uses the library, the code that uses the library is guaranteed to be implimentation independant, the library implimentation can be hidden for programmers using the library to protect propriatary information.  There are no dissadvantages to this approach that I can think of.
0
 
LVL 5

Expert Comment

by:yonat
ID: 1198462
I've used that two. The only drawback is in writing unit tests. I now use CppUnit testing framework and it is easier writing usint tests if the class declaration can be #included. I suppose you can make a single test class for all DataType derived classes together, though, since they all have exactly the same interface.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction This article is the first in a series of articles about the C/C++ Visual Studio Express debugger.  It provides a quick start guide in using the debugger. Part 2 focuses on additional topics in breakpoints.  Lastly, Part 3 focuses on th…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
The goal of the video will be to teach the user the concept of local variables and scope. An example of a locally defined variable will be given as well as an explanation of what scope is in C++. The local variable and concept of scope will be relat…
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.

719 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question