mercredi 2 septembre 2015

Factory pattern with private constructors in C++

I am trying to implement a factory pattern that consists of

  • a factory class
  • an abstract class with protected constructor
  • inherited classes with private constructors and virtual public destructors.

I want to make sure that

  • No other one than the factory can not create any instance
  • If a new inherited class is defined it will not require any modification on interface class and already defined inherited classes. Juts new class implementation and adding into factory classes create method.

I also do not want to write same-like code(like static factory method per inited) for every inherited class and leave the future developers much work for factory connections.

i.e with pseduo code

class Factory;

class Interface
{
    protected:
        Interface(){/*Do something*/};
    public:
        virtual ~Interface(){/*Do something*/}
    /*I wish I could do below and it is valid for all inherited 
    classes but friendship is not inherited in C++*/
    //friend Interface* Factory::create(Type)
};

class InheritedA:public Interface
{
    private:
        InheritedA(){/*Do something*/};
    public:
        virtual ~InheritedA(){/*Do something*/}
    /*I dont want to do below two lines for every inherited class*/
    //friend Interface Factory::create(Type)
    //public: Interface* factoryInheritedA(){return new InheritedA();}
};

class InheritedB:public Interface
{
    private:
        InheritedB(){/*Do something*/};
    public:
        virtual ~InheritedA(){/*Do something*/}
};

class Factory
{
     static Interface* create(Interface type)       
     {
           switch(type)
           {
           case A:
                return new InheritedA();
           case B:
                return new InheritedB();
           default:
                //exceptions etc
           }
     }
}

int main()
{
    Interface* I = Factory::create(A/*or B*/);
    return 0;
}

Design a decathlon competition Java classes structure

My goal is design a elegant classes and relations structure which describes a decathlon competition.

In the competition compete athletes. The competition consist from some rounds.

Competition should have the method to set the list of a ascending order by a sum of competition rounds scores.

I imagine something like that:

enter image description here

But I am confused on the lower part of the UML diagram (Round and AthleticRound classes). For me is not looking very good :). Because i must have on mind to set Competition from cvs file which looks like that:

Siim Susi;12.61;5.00;9.22;1.50;60.39;16.43;21.60;2.60;35.81;5.25.72 
Beata Kana;13.04;4.53;7.79;1.55;64.72;18.74;24.20;2.40;28.20;6.50.76 
Jaana Lind;13.75;4.84;10.12;1.50;68.44;19.18;30.85;2.80;33.88;6.22.75 
Anti Loop;13.43;4.35;8.64;1.50;66.06;19.05;24.89;2.20;33.48;6.51.01

And than competition class will be exported to xml.

My goal is get some recommendations or insights what should be classes structure to reach my goals to implement importer and exporter in Java.

Suitable design pattern for matrix-like feature

Which design pattern or combination of patterns would be correct or most suitable for the following common scenario:

Let's say I have a method which places an order. I have different order types and different countries. The method's implementation differs based on order type and also country.

My idea is to use the strategy pattern where I could have objects like OrderType1Country1Strategy, OrderType1Country2Strategy, OrderType2Country1Strategy etc.

My problem with this is that any two class can have common code which I'm not sure how best to handle. Any ideas for that or alternative patterns? Could decorator be used somehow?

Notify the change in directory in a website asp.net with c#

I want to implement OBSERVER pattern for a website to raise a event if the content of a particular server directory (including sub directory) is changed (files added or deleted or modified). Moreover the directory can't be accessed via mapping in the website url.

mardi 1 septembre 2015

Anonymous generic class and overriding a method

I am working on GWT project with JDK7. It has two entryPoints (two clients) that are located in separate packages of the project. Clients share some code that is located in /common package, which is universal and accessible to both by having the following line in their respective xml-build files:

    <source path='ui/common' />

Both clients have their own specific implementations of the Callback class which serves their running environments and performs various actions in case of failure or success. I have the following abstract class that implements AsyncCallback interface and then gets extended by its respective client.

public abstract class AbstractCallback<T> implements AsyncCallback<T> {
    public void handleSuccess( T result ) {}
    ...
}

Here are the clients classes:

public class Client1Callback<T> extends AbstractCallback<T> {...}

and

public class Client2Callback<T> extends AbstractCallback<T> {...}

In the common package, that also contains these callback classes, I am working on implementing the service layer that serves both clients. Clients use the same back-end services, just handle the results differently. Based on the type of the client I want to build a corresponding instance of AbstractCallback child without duplicating anonymous class creation for each call. I am going to have many declarations that will look like the following:

   AsyncCallback<MyVO> nextCallback = isClient1 ?
                    new Client1Callback<MyVO>("ABC") {
                        public void handleSuccess(MyVO result) {
                            doThatSameAction(result);
                        }
                    }
                    :
                    new Client2Callback<MyVO>("DEF") {
                        public void handleSuccess(MyVO result) {
                            doThatSameAction(result);
                        }
                    };

That will result in a very verbose code.

The intent (in pseudo-code) is to have the below instead:

AsyncCallback<MyVO> nextCallback = new CallbackTypeResolver.ACallback<MyVO>(clientType, "ABC"){
            public void handleSuccess(MyVO result) {
                doThatSameAction(result);
            }
        };

I was playing with the factory pattern to get the right child instance, but quickly realized that I am not able to override handleSuccess() method after the instance is created.

I think the solution may come from one of the two sources:

  1. Different GWT way of dealing with custom Callback implementations, lets call it alternative existent solution.
  2. Java generics/types juggling magic

I can miss something obvious, and would appreciate any advice. I've read some articles here and on Oracle about types erasure for generics, so I understand that my question may have no direct answer.

What design pattern can be used for feature toggle spaghetti?

The company that I work for has gone off the deep end with feature toggles-configuration keys that turn on/off particular behavior based on certain conditions. Martin Fowler actually refers to them as business toggles (http://ift.tt/18DVASs).

We have many clients all using the same service, but each wants slightly different behavior. Even worse, many want certain subgroups of their users to see different behavior. Thus, we use business toggles. The toggles have become a spaghetti ball of if/else logic that with occasionally unexpected interactions.

Are there any design patterns useful in managing a situation such as this?

Cheers!

What is a good pattern for data marshaling between JS modules?

This question is regarding a best practice for structuring data objects using JS Modules on the server for consumption by another module.

We have many modules for a web application, like login view, form handlers, that contain disparate fragments of data, like user state, application state, etc. which we need to be send to an analytics suite that requires a specific object format. Where should we map the data? (Pick things we want to send, rename keys, delete unwanted values.)

  1. In each module. E.g.: Login knows about analytics and its formatting requirements.
  2. In an analytics module. Now analytics has to know about each and every module's source format.
  3. In separate [module]-analytics modules. Then we'll have dozen of files which don't have much context to debug and understand.

My team is split on what is the right design. I'm curious if there is some authoritative voice on the subject that can help us settle this.

Thanks in advance!