is this a example where abstract factory pattern is used? - c++

Question

Now I am developing a class for recognize a object in a photo, and this class is composed of several components (classes). For example,
class PhotoRecognizer
{
public:
int perform_recogniton()
{
pPreProcessing->do_preprocessing();
pFeatureExtractor->do_feature_extraction();
pClassifier->do_classification()
}
boost::shared_ptr<PreProcessing> pPreProcessing;
boost::shared_ptr<FeatureExtractor> pFeatureExtractor;
boost::shared_ptr<Classifier> pClassifier;
}
In this example, when we use this class to perform recognition, we invoke other classes PreProcessing, FeatureExtractor and Classifier. As you can image, there are many different methods to implement each class. For example, for the Classifier class, we can use SVMClassfier or NeuralNetworkClassifer, which is a derived class of the basic Classifier class.
class SVMClassifier: public Classifier
{
public:
void do_classification();
};
Therefore, by using different elements within PhotoRecognizer class, we can create different kinds of PhotoRecongnizer. Now, I am building a benchmark to know how to combine these elements together to create an optimal PhotoRecognizer. One solution I can think of is to use abstract factory:
class MethodFactory
{
public:
MethodFactory(){};
boost::shared_ptr<PreProcessing> pPreProcessing;
boost::shared_ptr<FeatureExtractor> pFeatureExtractor;
boost::shared_ptr<Classifier> pClassifier;
};
class Method1:public MethodFactory
{
public:
Method1():MethodFactory()
{
pPreProcessing.reset(new GaussianFiltering);
pFeatureExtractor.reset(new FFTStatictis);
pClassifier.reset(new SVMClassifier);
}
};
class Method2:public MethodFactory
{
public:
Method1():MethodFactory()
{
pPreProcessing.reset(new MedianFiltering);
pFeatureExtractor.reset(new WaveletStatictis);
pClassifier.reset(new NearestNeighborClassifier);
}
};
class PhotoRecognizer
{
public:
PhotoRecognizer(MethodFactory *p):pFactory(p)
{
}
int perform_recogniton()
{
pFactory->pPreProcessing->do_preprocessing();
pFactory->pFeatureExtractor->do_feature_extraction();
pFactory->pClassifier->do_classification()
}
MethodFactory *pFactory;
}
So when I use Method1 to perform photo recognition, I can simply do the following:
Method1 med;
PhotoRecognizer recogMethod1(&med);
med.perform_recognition()
Further more, I can even make the class PhotoRecognizer more compact:
enum RecMethod
{
Method1, Method2
};
class PhotoRecognizer
{
public:
PhotoRecognizer(RecMethod)
{
switch(RecMethod)
{
case Method1:
pFactory.reset(new Method1());
break;
...
}
}
boost::shared_ptr<MethodFactory> pFactory;
};
So here is my question: is abstract factory design pattern well justified in the situation described above? are there alternative solutions? Thanks.

Answer 1

As so often there is no ultimate "right" method to do it, and the answer depends a lot on how the project will be used. So if it is only for quick tests, done once and never looked back - go on and use enums if it is your heart's desire, nobody should stop you.
However, if you plan to extend the possible methods over time, I would discourage the usage of your second approach with enums. The reason is: every time you want to add a new method you have to change PhotoRecognizer class, so you have to read the code, to remember what it is doing and if somebody else should do it - it would take even more time.
The design with enums violates two first rules of SOLID (https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)):
Open-Closed-Principle (OCP): PhotoRecognizer class cannot be extended (adding a new method) without modification of its code.
Single-Responsibility-Principle (SRP): PhotoRecognizer class does not only recognize the photo, but also serves as a factory for methods.
Your first approach is better, because if you would define another Method3 you could put it into your PhotoRecognizer and use it without changing the code of the class:
//define Method3 somewhere
Method3 med;
PhotoRecognizer recogMethod3(&med);
med.perform_recognition()
What I don't like about your approach, is that for every possible combination you have to write a class (MethodX), which might result in a lot of joyless work. I would do the following:
struct Method
{
boost::shared_ptr<PreProcessing> pPreProcessing;
boost::shared_ptr<FeatureExtractor> pFeatureExtractor;
boost::shared_ptr<Classifier> pClassifier;
};
See Method as as a collection of slots for different algorithms, it here because it is convenient to pass Processing/Extractor/Classifier in this way.
And one could use a factory function:
enum PreprocessingType {pType1, pType2, ...};
enum FeatureExtractorType {feType1, feType2, ..};
enum ClassifierType {cType1, cType2, ... };
Method createMethod(PreprocessingType p, FeatureExtractionType fe, ClassifierType ct){
Method result;
swith(p){
pType1: result.pPreprocessing.reset(new Type1Preprocessing());
break;
....
}
//the same for the other two: fe and ct
....
return result
}
You might ask: "But how about OCP?" - and you would be right! One has to change the createMethod to add other (new) classes. And it might be not much comfort to you, that you still have the possibility to create a Method-object by hand, initialize the fields with the new classes and pass it to a PhotoRecognizer-constructor.
But with C++, you have a mighty tool at your disposal - the templates:
template < typename P, typename FE, typename C>
Method createMethod(){
Method result;
result.pPrepricessing.reset(new P());
result.pFeatureExtractor.reset(new FE());
result.pClassifier.reset(new C());
return result
}
And you are free to chose any combination you want without changing the code:
//define P1, FE22, C2 somewhere
Method medX=createMethod<P1, FE22, C2>();
PhotoRecognizer recogMethod3(&med);
recogMethod3.perform_recognition()
There is yet another issue: What if the class PreProcessingA can not be used with the class ClassifierB? Earlier, if there was no class MethodAB nobody could use it, but now this mistake is possible.
To handle this problem, traits can be used:
template <class A, class B>
struct Together{
static const bool can_be_used=false;
template <>
struct Together<class PreprocessingA, class ClassifierA>{
static const bool can_be_used=true;
}
template < typename P, typename FE, typename C>
Method createMethod(){
static_assert(Together<P,C>::can_be_used, "classes cannot be used together");
Method result;
....
}
Conclusion
This approach has the following advantages:
SRP, i.e. PhotoRecognizer - only recognizes, Method - only bundles the algorithm parts and createMethod - only creates a method.
OCP, i.e. we can add new algorithms without changing the code of other classes/functions
Thanks to traits, we can detect a wrong combination of part-algorithms at compile time.
No boilerplate code / no code duplication.
PS:
You could say, why not scratch the whole Method class? One could just as well use:
template < typename P, typename FE, typename C>
PhotoRecognizer{
P preprocessing;
FE featureExtractor;
C classifier;
...
}
PhotoRecognizer<P1, FE22, C2> recog();
recog.perform_recognition();
Yeah it's true. This alternative has some advantages and disadvantages, one must know more about the project to be able to make the right trade off. But as default I would go with the more SRP-principle compliant approach of encapsulating the part-algorithms into the Method class.

Answer 2

I've implemented an abstract factory pattern here and there. I've always regret the decision after revisiting the code for maintenance. There is no case, I can think of, where one or more factory methods wouldn't have been a better idea. Therefore, I like your second approach best. Consider ditching the method class as ead suggested. Once your testing is complete you'll have one or more factory methods that construct exactly what you want, and best of all, you and others will be able to follow the code later. For example:
std::shared_ptr<PhotoRecognizer> CreateOptimizedPhotoRecognizer()
{
auto result = std::make_shared<PhotoRecognizer>(
CreatePreProcessing(PreProcessingMethod::MedianFiltering),
CreateFeatureExtractor(FeatureExtractionMethod::WaveletStatictis),
CreateClassifier(ClassificationMethod::NearestNeighborClassifier)
);
return result;
}
Use your factory method in code like this:
auto pPhotoRecognizer = CreateOptimizedPhotoRecognizer();
Create the enumerations as you suggested. I know, I know, open/closed principle... If you keep these enumerations in one spot you won't have a problem keeping them in sync with your factory methods. First the enumerations:
enum class PreProcessingMethod { MedianFiltering, FilteringTypeB };
enum class FeatureExtractionMethod { WaveletStatictis, FeatureExtractionTypeB };
enum class ClassificationMethod { NearestNeighborClassifier, SVMClassfier, NeuralNetworkClassifer };
Here's an example of a component factory method:
std::shared_ptr<PreProcessing> CreatePreProcessing(PreProcessingMethod method)
{
std::shared_ptr<PreProcessing> result;
switch (method)
{
case PreProcessingMethod::MedianFiltering:
result = std::make_shared<MedianFiltering>();
break;
case PreProcessingMethod::FilteringTypeB:
result = std::make_shared<FilteringTypeB>();
break;
default:
break;
}
return result;
}
In order to determine the best combinations of algorithms you'll probably want to create some automated tests that run through all the possible permutations of components. One way to do this could be as straight forward as:
for (auto preProc = static_cast<PreProcessingMethod>(0); ;
preProc = static_cast<PreProcessingMethod>(static_cast<int>(preProc) + 1))
{
auto pPreProcessing = CreatePreProcessing(preProc);
if (!pPreProcessing)
break;
for (auto feature = static_cast<FeatureExtractionMethod>(0); ;
feature = static_cast<FeatureExtractionMethod>(static_cast<int>(feature) + 1))
{
auto pFeatureExtractor = CreateFeatureExtractor(feature);
if (!pFeatureExtractor)
break;
for (auto classifier = static_cast<ClassificationMethod>(0); ;
classifier = static_cast<ClassificationMethod>(static_cast<int>(classifier) + 1))
{
auto pClassifier = CreateClassifier(classifier);
if (!pClassifier)
break;
{
auto pPhotoRecognizer = std::make_shared<PhotoRecognizer>(
pPreProcessing,
pFeatureExtractor,
pClassifier
);
auto testResults = TestRecognizer(pPhotoRecognizer);
PrintConfigurationAndResults(pPhotoRecognizer, testResults);
}
}
}
}

Answer 3

Unless you are reusing MethodFactory, I'd recommend the following:
struct Method1 {
using PreProcessing_t = GaussianFiltering;
using FeatureExtractor_t = FFTStatictis;
using Classifier_t = SVMClassifier;
};
class PhotoRecognizer
{
public:
template<typename Method>
PhotoRecognizer(Method tag) {
pPreProcessing.reset(new typename Method::PreProcessing_t());
pFeatureExtractor.reset(new typename Method::FeatureExtractor_t());
pClassifier.reset(new typename Method::Classifier_t());
}
};
Usage:
PhotoRecognizer(Method1());