jasonclarke
asked on
Is this a valid technique?
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?
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?
what example?
ASKER
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::CreateConve
{
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::Con
{
return 2*value;
}
// etc....
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::CreateConve
{
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::Con
{
return 2*value;
}
// etc....
ASKER
KangaRoo, you were a little too fast there, it was only a minute between question and comment!
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?
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?
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.
ASKER
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.)
(The data is actually Fluid data and the conversion is conversion between fluid types, so the possible conversion types are limited.)
No, there is nothing wrong with it. Maybe a little cluttered.
What about adding associated documentation in a README.TXT or Windows HELP file?
What about adding associated documentation in a README.TXT or Windows HELP file?
ASKER
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!
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!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.