I see various resources[1] on the internet which specifies "Object Pool" as a creational design pattern although I do not see it being mentioned in GOF book.
Is this something which was introduced as a creational design pattern after the book was released?
[1] https://en.wikipedia.org/wiki/Object_pool_pattern
I'm supposed to be accepting only usyd.edu.au email addresses. The validation works, but it also works with usyd.edu.a emails. I want it to accept only when complete .au is entered. The pattern I have which works so far is:
input type="email", placeholder="Email" name="txtName" id="txtEmail" pattern="[a-z0-9._%+-]+@[usyd]+.[edu]+.[au]"/>
I've been developing a many years and a common problem I face is how best to separate out the service layer. I've been using the repository pattern mainly, but I still struggle with this common scenario.
Customer service that returns a single customer. Invoice service that returns a list of invoices by customer.
The consumer of the service sometimes wants just a Customer other times they want the customer and the invoices which is fine to leave as two calls.
But a new requirement may be they want the Customer, but also want the total number of invoices the respective customer has.
I do not want to corrupt the GetCustomer method and do not want to return a list of invoices and have them do a count (this would work). Is there a best practice without getting into create a lot of one of methods while still keeping performance and round trips in mind? I see a lot of designs where there will get GetCustomer, GetCustomerDeepLoad, etc.
thanks.
What I have is a list types of data, each identified by a name. For example 'length' and 'weight'. These are used to read and write bytes from files. Each metric stores a different amount of bytes, so I have a class Metric that stores for example a description and a byte length for the metric. Then, I can just keep a JSON file or an XML file of metric definitions that can be added to whenever.
I now want to differentiate how these bytes are read and written by adding a to_bytes and from_bytes method to the class. I could store the function definition as a string in the JSON file and just eval() it, or I could write separate child classes for each metric.
What is the best way to store function definitions alongside other data? I'm open to any suggestions, but the best solution is one that keeps it easy to manually add new metrics to the collection.
First of all, I want to point out that it is the first time I am using dynamic polymorphism and the composite design pattern.
I would like to use the composite design pattern to create a class Tree which is able to take different objects of the type Tree, a composite type, or Leaf, an atomic type. Both Tree and Leaf inherit from a common class Nature. Tree can store Leaf or Tree objects into a std::vector<std::shared_ptr<Nature>> children. I would like to fill the vector children with a syntax of this kind (so I guess I have to use variadic, to consider a generic number of inputs in the input lists), as in the following:
Leaf l0(0);
Leaf l1(1);
Tree t0;
Tree t1;
t0.add(l0,l1);
t1.add(t0,l0,l1); // or in general t1.add(t_00,...,t_0n, l_00,...,l_0n,t10,...,t1n,l10,...,l1n,.... )
Then I would also access different elements of a Tree by means of the operator[ ]. So for example t1[0] returns t0 and t1[0][0] returns l0, while t1[0][1] returns l0.
Also I would like an homogeneous behaviour. So either use -> or the dot for accessing the methods on all levels (tree or leaf).
Is it possible to achieve this behaviour?
The implementation of such classes can be like the following:
class Nature
{
public:
virtual void nature_method() = 0;
virtual~Nature();
//virtual Nature& operator[] (int x);
};
class Leaf: public Nature
{
int value;
public:
Leaf(int val)
{
value = val;
}
void nature_method() override
{
std::cout << " Leaf=="<<value<<" ";
}
};
class Tree: public Nature
{
private:
std::vector <std::shared_ptr< Nature > > children;
int value;
public:
Tree(int val)
{
value = val;
}
void add(const Nature&);
void add(const Leaf& c)
{
children.push_back(std::make_shared<Leaf>(c));
}
void add(const Tree& c)
{
children.push_back(std::make_shared<Tree>(c));
}
void add(std::shared_ptr<Nature> c)
{
children.push_back(c);
}
template<typename...Args>
typename std::enable_if<0==sizeof...(Args), void>::type
add(const Leaf& t,Args...more)
{
children.push_back(std::make_shared<Leaf>(t));
};
template<typename...Args>
typename std::enable_if<0==sizeof...(Args), void>::type
add(const Tree& t,Args...more)
{
children.push_back(std::make_shared<Tree>(t));
};
template<typename...Args>
typename std::enable_if<0<sizeof...(Args), void>::type
add(const Leaf& t,Args...more)
{
children.push_back(std::make_shared<Leaf>(t));
add(more...);
};
template<typename...Args>
typename std::enable_if<0<sizeof...(Args), void>::type
add(const Tree& t,Args...more)
{
children.push_back(std::make_shared<Tree>(t));
add(more...);
};
void nature_method() override
{
std::cout << " Tree=="<< value;
for (int i = 0; i < children.size(); i++)
children[i]->nature_method();
}
}
I could implement the overload operator [] to return a pointer to Nature or a Nature object, like so:
Nature& operator[] (int x) {
return *children[x];
}
std::shared_ptr< Nature > operator[] (int x) {
return children[x];
}
In both cases, the return type is Nature related. This because it could be a Leaf or a Tree, which is not known in advance. But since the return type of the operator has to be known at compile time, I cannot do something else.
However, if the returned type would be Tree related, I cannot use the operator [] anymore, because I have enforced it to be Nature.
How can I dynamically choose the return type, Tree or Leaf related, of []? Is there any workaround for this?
I could consider operator [] a virtual method in the Nature class, but still I would no what to make out of this.
I have read about covariant types as well, but I do not know if they would be applicable here.
Thank you.
I have already explained my issue in this topic Extending (alternative to) the repository design pattern?. I noticed, Facade design pattern make it possible to call all the subsystems from one place. I think combination of facade, repository and unit of work may help to solve this issue. I was wondering if you could share your experience with me.
I'm creating a view entend FrameLayout now that has about 10 parameters.
I was thinking about using the Builder pattern, similar to how the AlertDialog works. However, I'm not exactly sure what would be the best way to implement this, or if it is even a good idea.
Here is an example of what I was thinking, but with many more variables.
there is problem in this.
I want to use the variable adDetailModel' anddataLoaderin the init thatbuilder` get it.
public class DialogContentList extends FrameLayout {
public static DataLoader dataLoader;
static SwipeRefreshRelativeLayout contentList;
public static AdDetailModel adDetailModel;
public DialogContentList(@NonNull Context context) {
super(context);
init(context, null, 0);
}
public DialogContentList(@NonNull Context context, @Nullable AttributeSet attrs) {
super(context, attrs);
init(context, attrs, 0);
}
public DialogContentList(@NonNull Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
init(context, attrs, defStyleAttr);
}
public static class Builder {
private AdDetailModel adDetailModel;
private DataLoader dataLoader;
public Builder() {
}
public Builder setModel(AdDetailModel adDetailModel) {
this.adDetailModel = adDetailModel;
return this;
}
public Builder setDataloder(DataLoader dataLoader) {
this.dataLoader = dataLoader;
return this;
}
public DialogContentList build(final Context context) {
DialogContentList dialogContentList = new DialogContentList(context);
return dialogContentList;
}
}
private void init( Context context, AttributeSet attrs, int defStyleAttr) {
LayoutInflater.from(context).inflate(R.layout.dialog_content_list, this, true);
contentList = (SwipeRefreshRelativeLayout) findViewById(R.id.ContentList);
//
// contentList.build(new viewWrapper() {
// @Override
// public BaseWidget getView() {
// return new AdSample(context1, adDetailModel);
// }
// }, dataLoader);
}
}