Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Hello my question is regarding if its possible to use the factory pattern for classes with same number of arguments in their constructor but different types. For example, I have an interface called IVerify. I have 2 classes that implement them, NameVerifier, which takes in a String name in its constructor, and IntegerVerifier, which takes in an int num in its constructor. Is it possible to do the factory pattern in this case?
Could we use IVerify Factory.CreateNameVerifier(string) and IVerify Factory.createIntegerVerifier(int) Is it still considered as a factory pattern?
Additional note: Im using c++
If there are many versions of NameVerifier and IntegerVerifier then your solution is still a Factory Pattern since you will be abstracting which class to instantiate inside CreateNameVerifier and CreateIntegerVerifier.
But if Verifiers are unique w.r.t to the type of Argument that they take i.e., there is only one NameVerifier and only one IntergerVerifier and they differ because of their types then your existing solution is just creating a sort of wrapper to create objects/Verifiers. In such case it should be something like this:
Reference: Factory Pattern
class IVerify
{
};
class CNameVerifier : public IVerify
{
};
class CIntegerVerifier : public IVerify
{
};
class CVerifierFactory
{
enum TYPE
{
STRING,
INTEGER
};
template<typename T>
IVerify* CreateVerifier(const CVerifierFactory::TYPE &_enumType, T _Parameter)
{
IVerify *pVerifier = NULL;
switch(_enumType)
{
case (CVerifierFactory::STRING)
pVerifier = new CNameVerifier(_Parameter);
break;
case (CVerifierFactory::INTEGER)
pVerifier = new CIntegerVerifier(_Parameter);
break;
}
return pVerifier;
}
};
CVerifierFactory g_oFactory;
IVerify *pVerifier = g_oFactory.CreateVerifier(CVerifierFactory::STRING, "Alex");
if(pVerifier != NULL)
{
//use pVerifier
}
Note: Strict Type Checking of arguments _Parameter are not done before creating Verifiers. You can extend the number of arguments for object creation using Variadic Template/Parameter pack.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
I'm making a simple programming language, and have encountered the following problem:
I have a Parser class which has methods that return derived classes of the Node struct. Currently all of the Parser class methods look something like this:
DerivedNode Parser::ParseDerived()
{
DerivedNode node{};
node.Field1 = 0;
node.Field2 = 10;
return node;
}
I recently switched the Node type from being a struct to a class, because I want to implement some oop, thus I made fields of Node class private. I'm refactoring the Parser class and struggling to decide, what is the best option out of these 3:
// Option 1: Public setters
DerivedNode Parser::ParseDerived()
{
DerivedNode node{};
node.SetField1(0);
node.SetField2(10);
return node;
}
// Option 2: Making Parser a friend of all Node derived classes
DerivedNode Parser::ParseDerived()
{
DerivedNode node{};
node.m_Field1 = 0;
node.m_Field2 = 10;
return node;
}
// Option 3: Storing in variables and calling a constructor
DerivedNode Parser::ParseDerived()
{
size_t field1 = 0;
size_t field2 = 10;
return DerivedNode{ field1, field2 };
}
I would love to hear which of these methods is the best and some arguments why (sorry for my English).
A class is supposed to hold an invariant. Unless all combination of all field values are correct, 2nd version is strongly discouraged; 3rd is recommended. It's also the way to go for immutable structures which help debugging and testing very much.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have got some related answers like Why the size of empty class that is derived from two empty classes is 2? but not get the answer to my question clearly.
interface PI1
{
default void show()
{
System.out.println("Default PI1");
}
}
interface PI2
{
default void show()
{
System.out.println("Default PI2");
}
}
class TestClass implements PI1, PI2
{
public void show()
{
PI1.super.show();
PI2.super.show();
}
public static void main(String args[])
{
TestClass d = new TestClass();
d.show();
}
}
Does this JAVA program show multiple inheritance?
In C++ the minimum size is 1.
However, the other question is about multiple inheritance from base classes of the same type. Two objects of the same type cannot have the same address, because then they would not be different objects.
The address is an important part of the identity of an object.
So, if you have two objects of the same type, the minimum size would be 2.
None of this happens in Java, because there is no multiple inheritance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have written a program, which takes an input vector of integers and prints all possible permutations of these integers.
In order to do that my program has two methods:
void Permutate(//input) and void DoPermute(//necessary arguments)
Only the method Permutate should be called by the user/client. DoPermutate is a recursive method which is firstly called by Permutate and provides the logic for the algorithm.
The question now: would you put Permutate and DoPermutate in a class and make DoPermutate private, or would you put both methods in the global scope and not use classes at all and thus expose DoPermutate to the user/client? I am asking this because cmath also has the utility methods in a global scope.
What would be a more elegant approach?
The question now: would you put Permutate and DoPermutate in a class
This is what I would to:
Declare Permutate in a namespace, such as:
namespace MyApp
{
// Declare
void Permutate( ... ); // Add all the necessary arguments,
// which can be input arguments ad
// output arguments.
}
Please note that the declaration does not expose whether a class is used in the implementation. That is detail of the implementation that does not need to be exposed in the interface.
If it is helpful to use a class in the implementation, use it.
namespace MyApp
{
// Helper class
struct PermutateClass { ... };
// Implement the user facing function.
void Permutate ( ... )
{
// Delegate the implementation to the helper class.
PermuateClass p(...);
p.doIt();
}
}
If it is not helpful to use a class, just use helper functions as needed.
namespace MyApp
{
// Helper function
void DoPermutate ( ... ) { ... }
// Implement the user facing function.
void Permutate ( ... )
{
// Delegate the implementation to the helper function.
DoPermutate p(...);
}
}
The key point I want to emphasize is that whether you use a helper class with a bunch of member functions or a bunch of non-member function is an implementation detail that you should be able choose without impacting the users of the user facing function.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Just some background:
I am making a monopoly game and now I have to implement the actions of each space such as GO, properties (upgrading), chance, community chest, jail, etc.
I've considered making a different class for each space (but obviously that would be very time consuming). I believe there is also a way do to it with inheritance and pure virtual functions. Any way you guys can think that would make this a simpler process?
Thanks!
There are only a few different types of spaces:
properties
railroads
chance / community chest
utilities
other single ones like go, jail, parking, tax
For example you could have a Property class where each instance of the class has a different name/colour/price. You wouldn't have to make 22 different classes, just have 22 instances of the same class with different names.
Note that having class instances that represent spaces you can land on is only one way to implement a game like that. I'm pretty sure I wouldn't choose that option.
There are two ways you can make a function do different things given an object:
Differentiate the behavior based on the data of the object.
You could capture the differences in the various spaces using data.
enum SpaceType
{
GO, CHANCE, COMMUNITY_CHEST, // etc...
};
class Space
{
public:
void foo()
{
switch (spaceType)
{
case GO:
// DO stuff for GO
break;
case CHANCE:
// DO stuff for CHANCE
break;
// etc..
}
}
private:
SpaceType spaceType;
}
Differentiate the behavior based on the type of an object.
class Space
{
public:
virtual void foo() = 0;
};
class GoSpace : public Space
{
public:
virtual void foo()
{
// Do stuff for GO
}
};
class ChanceSpace : public Space
{
public:
virtual void foo()
{
// Do stuff for CHANCE
}
};
// Similarly for other classes.
Pick your method. Personally, I would pick the second method because the logic for each different type is put into their own functions, without the complications of what other types do.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a program written in C++ where the user is able to segment some cells from a microscopy image. When this is done, the program got three overall parameters to change. Those three being feature, classifier and reductionMethod.
Each of these parameters are made as templates which are equal in their initialization. I thought that I could make the following implementation to call this:
if (feature == 1)
{
FastColorIntensityGradientFeature<8> workingFeature();
}
else if (feature == 2)
{
ColorIntensityGradientFeature<8> workingFeature();
}
workingFeature(input, var, var);
But this is not possible, because the workingFeature is initialized in the if-else statement. How can I do this instead? I'm not that used to programming in C++.
One way to make it work is to move your code into a function that has a template parameter taking the feature type you want to deal. Sample:
template <typename IntensityGradientFeature>
void doWork() {
IntensityGradientFeature workingFeature;
workingFeature.doSomething();
}
Then you call this way:
if (feature == 1)
doWork< FastColorIntensityGradientFeature<8> >();
else if (feature == 2)
doWork< ColorIntensityGradientFeature<8> >();
Both of the templates can have a common base class, then you can create a pointer of type base, and then create the desired child in the if clause.
class base
{
public:
virtual void workingFeature(input, var, var);
};
template<int num>
class FastColorIntensityGradientFeature : public base
{
public:
virtual void workingFeature(input, var, var);
};
template<int num>
class ColorIntensityGradientFeature: public base
{
public:
virtual void workingFeature(input, var, var);
};
and then change your if clause to:
base * choice;
if (feature == 1)
{
choice = new FastColorIntensityGradientFeature<8>;
}
else if (feature == 2)
{
choice = new ColorIntensityGradientFeature<8>;
}
else
{
// some error handling
}
choice->workingFeature(input, var, var);
You didn't specify the argument types for your function, but obviously they will need to be there in the class definitions.