C++ friend subclasses access private members (strategy pattern) - c++

Question

I've coded a crossover method for a genetic algorithm (see https://en.wikipedia.org/wiki/Crossover_(genetic_algorithm)).
The crossover method modifies the private members of the Chromosome class but I pulled it out of Chromosome into a separate pure virtual base class CrossoverStrategy (friend of Chromosome) to keep each crossover method nicely encapsulated in a subclass, i.e. the GoF strategy pattern (see https://en.wikipedia.org/wiki/Strategy_pattern).
Now the problem is CrossoverStrategy subclasses can't access Chromosome private members because friendship isn't inherited in C++. The only 2 solutions I see are:
1) Add accessor methods to the pure virtual base class e.g. CrossoverStrategy::getGenes() to make Chromosome private members accessible to subclasses. Because CrossoverStrategy can't anticipate all the stuff its subclasses may want to do with Chromosome, I need to expose everything up front. Ugly!
2) Forward declare each CrossoverStrategy subclass and explicitly make it a friend of Chromosome. This feels slightly less ugly, at least keeps the interfaces and code cleaner. I'm leaning towards this option for aesthetics.
Any better design suggestions? Code below.
// Chromosome.h ++++++++++++++++++++++++++++++++++++++++++++++++
class CrossoverStrategy
{
public:
virtual std::vector<Chromosome*> crossover(Chromosome *parent1, Chromosome *parent2) = 0;
const std::vector<double> &getGenes(Chromosome *instance) { return instance != NULL ? instance->m_genes : std::vector<double>(); }; // OPTION #1 ... BOO! UGLY!
};
class CrossoverStrategyExample1; // OPTION #2 ... BOO! UGLY!
class Chromosome
{
public:
// Friends
friend class CrossoverStrategy;
friend class CrossoverStrategyExample1; // OPTION #2 ... BOO! UGLY!
private:
std::vector<double> m_genes;
};
// CrossoverStrategies.h ++++++++++++++++++++++++++++++++++++++++++++++++
#include "Chromosome.h"
class CrossoverStrategyExample1 : public CrossoverStrategy
{
public:
virtual std::vector<Chromosome*> crossover(Chromosome *parent1, Chromosome *parent2);
private:
};
// CrossoverStrategies.cpp ++++++++++++++++++++++++++++++++++++++++++++++++
#include "CrossoverStrategies.h"
std::vector<Chromosome*> CrossoverStrategyExample1::crossover(Chromosome *parent1, Chromosome *parent2)
{
// Do something with Chromosome private members
// PROBLEM ... m_genes not accessible to subclasses? BOO BOO BOO!
(for unsigned long i = 0; i < parent1->m_genes.size(); i++)
parent1->m_genes[i] = 0.0;
}

Answer 1

Option 2 should be rejected because it does not scale. You will be continually modifying Chromosome to keep it up to date with new CrossoverStrategies.
Option 1 is a strange idea because it places the getter function for Chromosome's data members outside of Chromosome. I can see some cases where this is an attractive idea, if getGenes is made protected, but I'm not convinced here. Consider instead
Option 1-A
class Chromosome
{
public:
const std::vector<double>& getGenes() const
{
return m_genes;
}
private:
std::vector<double> m_genes;
};
Everyone who can access a Chromosome can access getGenes, but they can't do anything to damage it and Chromosome remains blissfully ignorant of its users.
Option 3: Use The Pimpl Idiom
Short and stupid example with a few flaws to keep the demo short
Chromosome.h ++++++++++++++++++++++++++++++++++++++++++++++++
#include <vector>
class Chromosome; // forward declaration only
class CrossoverStrategy
{
public:
virtual ~CrossoverStrategy() = default;
virtual std::vector<Chromosome*> crossover(Chromosome *parent1, Chromosome *parent2) = 0;
};
Chromosome * ChromosomeFactory(/* some construction parameters here */);
// should also provide a declaration of a factory function to provide CrossoverStrategies
CrossoverStrategies.h ++++++++++++++++++++++++++++++++++++++++++++++++
#include "Chromosome.h"
class CrossoverStrategyExample1 : public CrossoverStrategy
{
public:
virtual std::vector<Chromosome*> crossover(Chromosome *parent1, Chromosome *parent2);
private:
};
CrossoverStrategies.cpp ++++++++++++++++++++++++++++++++++++++++++++++++
#include "CrossoverStrategies.h"
class Chromosome
{
public:
std::vector<double> m_genes;
// silence a warning
Chromosome(): m_genes{}
{
}
};
// Because Chromosome is only defined in this file, only this file can use the internals
// of Chromosome. They are public, but the outside world doesn't know that
Chromosome * ChromosomeFactory(/* some construction parameters here */)
{
// Probably makes and returns a pointer to a Chromosome,
// but could pull it from a list, copy construct from a template, etc...
return new Chromosome(/* some construction parameters here */);
}
// should also provide a definition of a factory function to provide CrossoverStrategies
std::vector<Chromosome*> CrossoverStrategyExample1::crossover(Chromosome *parent1,
Chromosome *parent2)
{
for (unsigned long i = 0; i < parent1->m_genes.size(); i++)
parent1->m_genes[i] = 0.0;
return std::vector<Chromosome*>{}; // silence a warning
}
Main.cpp ++++++++++++++++++++++++++++++++++++++++++++++++
#include "Chromosome.h"
#include "CrossoverStrategies.h" // A bad idea. Forces recompilation when strategies are added
int main()
{
Chromosome * p1 = ChromosomeFactory(/* some construction parameters here */);
p1->m_genes.push_back(0.0); // will fail to compile (incomplete type)
Chromosome * p2 = ChromosomeFactory(/* some construction parameters here */);
// probably should hide the next line with a factory as well
CrossoverStrategy * strategy = new CrossoverStrategyExample1();
strategy->crossover(p1, p2);
}
A quick afterword on security. It always comes at a cost. Generally it makes things harder to use. It makes them harder for an attacker, but it also makes things harder for the legitimate users. Whether it's worth it or not is up to you.

Answer 2

The first, obvious, option is to consider whether the members of Chromosome should or should not be public. Given that you want an arbitrary number of classes to have access to its data, an obvious option is to make that data public.
A second option is for Chromosome to provide a public getter and setter for the affected data, such as;
class Chromosome
{
public:
std::vector<double> getGenes() const {return m_genes;};
bool setGenes(const std::vector<double> &newgenes)
{
bool is_error = true;
if (IsValid(newgnes))
{
is_error = false;
m_genes = newgenes;
}
return is_error; // return true if change is rejected
};
private:
std::vector<double> m_genes;
};
Then all CrossOverStrategy and its derived classes need to do, given valid pointers to Chromosomes, is request the genes, do whatever is needed, and (when done) provide a new set of genes back to selected Chromosomes.
Encapsulation of Chromosome is preserved by various measures, since the only way to change genes is via a member function of Chromosome i.e. there is no way of changing genes in a chromosome outside control of the Chromosome class. Which allows Chromosome to do any checks it likes, and reject bad genes if desired.
There is no need for any other class or function to be a friend of Chromosome. A key advantage is that it is not necessary to change the Chromosome class whenever a new class is derived from CrossOverStrategy.
The trade-off is that genes are retrieved and changes by copying the complete set (potential performance hit of copying). But it avoids the need to break encapsulation of the Chromosome class by providing, directly or indirectly, a reference to its private members to any other classes.
If copying the complete set of chromosomes is a bad thing, work out some additional member functions of Chromosome that allow the caller to request partial changes (e.g. update particular genes, insert a set of genes into a specified place in the vector of genes, etc). These additional functions need to work on the same principle: all changes of genes within a Chromosome go via member functions of Chromosome, and there is no "back door" mechanism for other code to sneak changes through.
If you really want, you can make the setter and getter private members of Chromosome, and make only the base class CrossOverStrategy a friend. Then all CrossOverStrategy needs to do is provide protected helpers that only call the private helpers of Chromosome.
class CrossoverStrategy
{
public:
virtual std::vector<Chromosome*> crossover(Chromosome *parent1, Chromosome *parent2) = 0;
protected:
std::vector<double> getGenes(Chromosome *instance)
{
return instance ? instance->getGenes() : std::vector<double>();
};
bool setGenes(Chromosome *instance, const std::vector<double> &newgenes)
{
return instance ? instance->setGenes(newgenes)) : true; // true indicates error
};
};
That way, only the classes derived from CrossOverStrategy can access the protected helpers. If the workings of Chromosome change, then the only class that needs to be adapted in this case is the base CrossOverStrategy class - since its derived classes don't (directly) access Chromosome at all.

Answer 3

Your idea is fundamentally flawed.
On one hand, you say you don't want just anyone to be able to mess with the vector of genes.
On the other hand, you want any descendant of CrossoverStrategy to be able to mess with the vector of genes.
But there's a contradiction. "Any descendant" of a class is "just anyone". Any user is able to inherit from any class and do what they want with your vector of genes. They only need to go through a small one-time inconvenience of inheriting from CrossoverStrategy.
This is the reason why friendship in C++ is not inherited. If it were, access control would be useless in presence of friend classes.
Of course you can simulate inheritable friendship by having a protected getter in CrossoverStrategy as one of the answers suggests. But doing that defeats the purpose of access control. It makes the arrays of genes as good as public.