答:
When designing code, you alaways have two options.

just get it done, in which case pretty much any solution will work for you

be pedantic and design a solution which exploits the quirks of the language an its ideology (OO languages in this case - the use of polymorphism as a mean to provide the decision)

I am not going to focus on the first of the two, because there is really nothing to be said. If you just wanted to get it to work, you could leave the code as it is.

But what would happen, if you chose to do it the pedantic way and actually solved the problem with design patterns, in the way you wanted it do?

You could be looking at the following process:

When designing OO code, most of the ifs which are in a code do not have to be there. Naturally, if you want to compare two scalar types, such as ints or floats, you are likely to have an if, but if you want to change procedures based on configuration, you can use polymorphism to achieve what you want, move the decisions (the ifs) from your business logic to a place, where objects are instantiated - to factories.

As of now, your process can go through 4 separate paths:

data is neither encrypted nor compressed (call nothing, return data)

data is compressed (call compress(data) and return it)

data is encrypted (call encrypt(data) and return it)

data is compressed and encrypted (call encrypt(compress(data)) and return it)

Just by looking at the 4 paths, you find a problem.

You have one process which calls 3 (theoretically 4, if you count not calling anything as one) different methods that manipulate the data and then returns it. The methods have different names, different so called public API (the way through which the methods communicate their behaviour).

Using the adapter pattern, we can solve the name colision (we can unite the public API) that has occured. Simply said, adapter helps two incompatible interfaces work together. Also, adapter works by defining a new adapter interface, which classes trying to unite their API implement.

This is not a concrete language. It is a generic approach, the any keyword is there to represent it may be of any type, in a language like C# you can replace it with generics (<T>).

I am going to assume, that right now you can have two classes responsible for compression and encryption.

```<code>class Compression
{
    Compress(data : any) : any { ... }
}

class Encryption
{
    Encrypt(data : any) : any { ... }
}
</code>```

In an enterprise world, even these specific classes are very likely to be replaced by interfaces, such as the class keyword would be replaced with interface (should you be dealing with languages like C#, Java and/or PHP) or the class keyword would stay, but the Compress and Encrypt methods would be defined as a pure virtual, should you code in C++.

To make an adapter, we define a common interface.

```<code>interface DataProcessing
{
    Process(data : any) : any;
}
</code>```

Then we have to provide implementations of the interface to make it useful.

```<code>// when neither encryption nor compression is enabled
class DoNothingAdapter : DataProcessing
{
    public Process(data : any) : any
    {
        return data;
    }
}

// when only compression is enabled
class CompressionAdapter : DataProcessing
{
    private compression : Compression;

    public Process(data : any) : any
    {
        return this.compression.Compress(data);
    }
}

// when only encryption is enabled
class EncryptionAdapter : DataProcessing
{
    private encryption : Encryption;

    public Process(data : any) : any
    {
        return this.encryption.Encrypt(data);
    }
}

// when both, compression and encryption are enabled
class CompressionEncryptionAdapter : DataProcessing
{
    private compression : Compression;
    private encryption : Encryption;

    public Process(data : any) : any
    {
        return this.encryption.Encrypt(
            this.compression.Compress(data)
        );
    }
}
</code>```

By doing this, you end up with 4 classes, each doing something completely different, but each of them providing the same public API. The Process method.

In your business logic, where you deal with the none/encryption/compression/both decision, you will design your object to make it depend on the DataProcessing interface we designed before.

```<code>class DataService
{
    private dataProcessing : DataProcessing;

    public DataService(dataProcessing : DataProcessing)
    {
        this.dataProcessing = dataProcessing;
    }
}
</code>```

The process itself could then be as simple as this:

```<code>public ComplicatedProcess(data : any) : any
{
    data = this.dataProcessing.Process(data);

    // ... perhaps work with the data

    return data;
}
</code>```

No more conditionals. The class DataService has no idea what will really be done with the data when it is passed to the dataProcessing member, and it does not really care about it, it is not its responsibility.

Ideally, you would have unit tests testing the 4 adapter classes you created to make sure they work, you make your test pass. And if they pass, you can be pretty sure they will work no matter where you call them in your code.

So doing it this way I will never have ifs in my code anymore?

No. You are less likely to have conditionals in your business logic, but they still have to be somewhere. The place is your factories.

And this is good. You separate the concerns of creation and actually using the code. If you make your factories reliable (in Java you could even go as far as using something like the Guice framework by Google), in your business logic you are not worried about chosing the right class to be injected. Because you know your factories work and will deliver what is asked.

Is it necessary to have all these classes, interfaces, etc.?

This brings us back to the begining.

In OOP, if you choose the path to use polymorphism, really want to use design patterns, want to exploit the features of the language and/or want to follow the everything is an object ideology, then it is. And even then, this example does not even show all the factories you are going to need and if you were to refactor the Compression and Encryption classes and make them interfaces instead, you have to include their implementations as well.

In the end you end up with hundreds of little classes and interfaces, focused on very specific things. Which is not necessarily bad, but might not be the best solution for you if all you want is to do something as simple as adding two numbers.

If you want to get it done and quickly, you can grab Ixrec's solution, who at least managed to eliminate the else if and else blocks, which, in my opinion, are even a tad worse than a plain if.

Take into consideration this is my way of making good OO
  design. Coding to interfaces rather than implementations, this is how
  I have done it for the past few years and it is the approach I am the
  most comfortable with.

I personally like the if-less programming more and would much
  more appreciate the longer solution over the 5 lines of code. It is
  the way I am used to designing code and am very comfortable reading
  it.

Update 2: There has been a wild discussion about the first version of my solution. Discussion mostly caused by me, for which I apologize.

I decided to edit the answer in a way that it is one of the ways to look at the solution but not the only one. I also removed the decorator part, where I meant facade instead, which I in the end decided to leave out completely, because an adapter is a facade variation.

Title: Is there a design pattern to remove the need to check for flags?

Body:
I'm going to save some string payload in the database. I have two global configurations:

encryption

compression

These can be enabled or disabled using the configuration in a way that either only one of them is enabled, both are enabled or both are disabled.

My current implementation is this:

```<code>if (encryptionEnable && !compressEnable) {
    encrypt(data);
} else if (!encryptionEnable && compressEnable) {
    compress(data);
} else if (encryptionEnable && compressEnable) {
    encrypt(compress(data));
} else {
  data;
}
</code>```

I'm thinking about the Decorator pattern. Is it the right choice, or is there perhaps a better alternative?

Body:
When designing code, you alaways have two options.

just get it done, in which case pretty much any solution will work for you

be pedantic and design a solution which exploits the quirks of the language an its ideology (OO languages in this case - the use of polymorphism as a mean to provide the decision)

I am not going to focus on the first of the two, because there is really nothing to be said. If you just wanted to get it to work, you could leave the code as it is.

But what would happen, if you chose to do it the pedantic way and actually solved the problem with design patterns, in the way you wanted it do?

You could be looking at the following process:

When designing OO code, most of the ifs which are in a code do not have to be there. Naturally, if you want to compare two scalar types, such as ints or floats, you are likely to have an if, but if you want to change procedures based on configuration, you can use polymorphism to achieve what you want, move the decisions (the ifs) from your business logic to a place, where objects are instantiated - to factories.

As of now, your process can go through 4 separate paths:

data is neither encrypted nor compressed (call nothing, return data)

data is compressed (call compress(data) and return it)

data is encrypted (call encrypt(data) and return it)

data is compressed and encrypted (call encrypt(compress(data)) and return it)

Just by looking at the 4 paths, you find a problem.

You have one process which calls 3 (theoretically 4, if you count not calling anything as one) different methods that manipulate the data and then returns it. The methods have different names, different so called public API (the way through which the methods communicate their behaviour).

Using the adapter pattern, we can solve the name colision (we can unite the public API) that has occured. Simply said, adapter helps two incompatible interfaces work together. Also, adapter works by defining a new adapter interface, which classes trying to unite their API implement.

This is not a concrete language. It is a generic approach, the any keyword is there to represent it may be of any type, in a language like C# you can replace it with generics (<T>).

I am going to assume, that right now you can have two classes responsible for compression and encryption.

class Compression
{
    Compress(data : any) : any { ... }
}

class Encryption
{
    Encrypt(data : any) : any { ... }
}

In an enterprise world, even these specific classes are very likely to be replaced by interfaces, such as the class keyword would be replaced with interface (should you be dealing with languages like C#, Java and/or PHP) or the class keyword would stay, but the Compress and Encrypt methods would be defined as a pure virtual, should you code in C++.

To make an adapter, we define a common interface.

interface DataProcessing
{
    Process(data : any) : any;
}

Then we have to provide implementations of the interface to make it useful.

// when neither encryption nor compression is enabled
class DoNothingAdapter : DataProcessing
{
    public Process(data : any) : any
    {
        return data;
    }
}

// when only compression is enabled
class CompressionAdapter : DataProcessing
{
    private compression : Compression;

    public Process(data : any) : any
    {
        return this.compression.Compress(data);
    }
}

// when only encryption is enabled
class EncryptionAdapter : DataProcessing
{
    private encryption : Encryption;

    public Process(data : any) : any
    {
        return this.encryption.Encrypt(data);
    }
}

// when both, compression and encryption are enabled
class CompressionEncryptionAdapter : DataProcessing
{
    private compression : Compression;
    private encryption : Encryption;

    public Process(data : any) : any
    {
        return this.encryption.Encrypt(
            this.compression.Compress(data)
        );
    }
}

By doing this, you end up with 4 classes, each doing something completely different, but each of them providing the same public API. The Process method.

In your business logic, where you deal with the none/encryption/compression/both decision, you will design your object to make it depend on the DataProcessing interface we designed before.

class DataService
{
    private dataProcessing : DataProcessing;

    public DataService(dataProcessing : DataProcessing)
    {
        this.dataProcessing = dataProcessing;
    }
}

The process itself could then be as simple as this:

public ComplicatedProcess(data : any) : any
{
    data = this.dataProcessing.Process(data);

    // ... perhaps work with the data

    return data;
}

No more conditionals. The class DataService has no idea what will really be done with the data when it is passed to the dataProcessing member, and it does not really care about it, it is not its responsibility.

Ideally, you would have unit tests testing the 4 adapter classes you created to make sure they work, you make your test pass. And if they pass, you can be pretty sure they will work no matter where you call them in your code.

So doing it this way I will never have ifs in my code anymore?

No. You are less likely to have conditionals in your business logic, but they still have to be somewhere. The place is your factories.

And this is good. You separate the concerns of creation and actually using the code. If you make your factories reliable (in Java you could even go as far as using something like the Guice framework by Google), in your business logic you are not worried about chosing the right class to be injected. Because you know your factories work and will deliver what is asked.

Is it necessary to have all these classes, interfaces, etc.?

This brings us back to the begining.

In OOP, if you choose the path to use polymorphism, really want to use design patterns, want to exploit the features of the language and/or want to follow the everything is an object ideology, then it is. And even then, this example does not even show all the factories you are going to need and if you were to refactor the Compression and Encryption classes and make them interfaces instead, you have to include their implementations as well.

In the end you end up with hundreds of little classes and interfaces, focused on very specific things. Which is not necessarily bad, but might not be the best solution for you if all you want is to do something as simple as adding two numbers.

If you want to get it done and quickly, you can grab Ixrec's solution, who at least managed to eliminate the else if and else blocks, which, in my opinion, are even a tad worse than a plain if.

Take into consideration this is my way of making good OO
  design. Coding to interfaces rather than implementations, this is how
  I have done it for the past few years and it is the approach I am the
  most comfortable with.

I personally like the if-less programming more and would much
  more appreciate the longer solution over the 5 lines of code. It is
  the way I am used to designing code and am very comfortable reading
  it.

Update 2: There has been a wild discussion about the first version of my solution. Discussion mostly caused by me, for which I apologize.

I decided to edit the answer in a way that it is one of the ways to look at the solution but not the only one. I also removed the decorator part, where I meant facade instead, which I in the end decided to leave out completely, because an adapter is a facade variation.


问:
Requirements specification for Multi-Channel website
The company I'm working on has a RUP-like software development process, with very heavy documentation. Right now we're doing a Multi-Channel web site -it's intended to be seen in Desktop, Tablets and Smartphones- and every version of the site has a particular flow of events and content.

I don't see in RUP an artifact were this differences are documented. I'm aware that Uses Cases must be implementation agnostic -we can't mention any device specific terms- so maybe there's something in the Design discipline that serves that purpose.

If there's nothing like that in RUP, It would be nice to know how another Software Process document requirements for Multi-Channel sites.

答:
If your site actually has to work/react differently depending on whether it is accessed from a desktop, tablet or smartphone, then those differences must be visible in the requirements and the use-cases.

A use-case should not specify that there is a 'login' button in the top-right corner of the screen, but they can specify that a user on a tablet can perform action A and a user on a desktop must first do action B.

ContentLicense: CC BY-SA 3.0


问:
Python: Control subprocess from calling thread
I am working on a database interface to a MongoDB using Python Eve as an API.

The database stores several documents containing parameters and values needed for some calculations. I wrote a Python module containing all the calculation routines which need to have access to the desired data.

Since the calculations need some time to complete I would prefer multiprocessing instead of multithreading in order to use several cores for co-current simulations (doing calculations in parallel, one calculation per core, but with different input parameters, not splitting one calculation to several cores).

In order to start those parallel calculations as own (sub)processes I thought about using something like a parent thread which are observed by another thread called 'thread observer'. Since each of these calculation processes needs access to the database I thought about using the eve-API in combination with the requests module.

All in all these thoughts lead to the setup like the following:

Based on this concept I am not sure about how to control the subprocess from its parent thread. How can I make sure that Process 1 is terminated if Thread 1 terminates?

Note: The desired solution needs to work both on UNIX- and Windows-based machines. So using the returned pid of the started process in order to kill it using kill would not work since this would not be doable on a Windows machine.

答: Start with the Python 2 and Python 3 multiprocessing package having classes like Process with Queue and Pipe to exchange messages between them on all platforms where Python runs.  You seem to be interested in the Pool class of multiprocessing to control worker processes.  It is a different style of control than the usual fork/exec, wait, and signals.</p>


问:
Possible way to make java class builder more abstract by using interface required keys
I'm looking for a more abstract pattern for builders that handles required
fields without the need of writing a validator that checks if all requried fields are set.

I like this builder. But is there a way to make the interfaces more abstract
so that I don't need to create a new interface for each required field?

```<code>public class Example {

    private String first;
    private String second;
    private String third;
    private String fourth;
    private String fifth;

    public static RequiredSecond builder(String first) {
        return new ExampleBuilder(first);
    }

    public interface RequiredSecond {
        RequiredThird withSecond(String second);
    }

    public interface RequiredThird {
        RequiredFourth withThird(String third);
    }

    public interface RequiredFourth {
        Build withFourth(String fourth);
    }

    public interface Build {
        Build withFifth(String fifth);

        Example build();
    }

    private static class ExampleBuilder implements RequiredSecond, RequiredThird, RequiredFourth, Build {
        Example example = new Example();

        public ExampleBuilder(String first) {
            example.setFirst(first);
        }

        @Override
        public Build withFifth(String fifth) {
            example.setFifth(fifth);
            return this;
        }

        @Override
        public Example build() {
            return example;
        }

        @Override
        public Build withFourth(String fourth) {
            example.setFourth(fourth);
            return this;
        }

        @Override
        public RequiredFourth withThird(String third) {
            example.setThird(third);
            return this;
        }

        @Override
        public RequiredThird withSecond(String second) {
            example.setSecond(second);
            return this;
        }
    }

    public String getFirst() {
        return first;
    }

    public void setFirst(String first) {
        this.first = first;
    }

    public String getSecond() {
        return second;
    }

    public void setSecond(String second) {
        this.second = second;
    }

    public String getThird() {
        return third;
    }

    public void setThird(String third) {
        this.third = third;
    }

    public String getFourth() {
        return fourth;
    }

    public void setFourth(String fourth) {
        this.fourth = fourth;
    }

    public String getFifth() {
        return fifth;
    }

    public void setFifth(String fifth) {
        this.fifth = fifth;
    }

    @Override
    public String toString() {
        return "Example [first=" + first + ", second=" + second + ", third=" + third + ", fourth=" + fourth +
                ", fifth=" + fifth + "]";
    }

}
public class Labb {

    public static void main(String[] args) {
        // All required including optional
        Example ex1 = Example.builder("first").withSecond("second").withThird("third").withFourth("fourth").withFifth("optional fith").build();
        System.out.println(ex1);
        // Output: Example [first=first, second=second, third=third, fourth=fourth, fifth=optional fith]

        // All required excluding optional
        Example ex2 = Example.builder("first").withSecond("second").withThird("third").withFourth("fourth").build();
        System.out.println(ex2);
        // Output: Example [first=first, second=second, third=third, fourth=fourth, fifth=null]
    }
}
</code>```

答:
But is there a way to make the interfaces more abstract so that I don't need to create a new interface for each required field?

No.  What you've done here is implement a state machine with compile time enforcement.  To make that work, you are going to need an interface for each unique state.  At a minimum, that's going to require one state per required field.


问:
Do you know the name of this algorithm? (cycle with history?)
Context : I'm a IT student who is trying to implement a small application for my family. Every year, we offer each other gifts. Each one of us pick a name of a family member in a hat, and have to offer him a gift. The problem is, we always have some problem doing it:

Problem 1: When we pick, sometimes someone pick his own name and we have to start all over.

Problem 2 : Some people offers for two (or three) years consecutive to the same person

Algorithm

I'm looking for a way in which I can resolve the problem mentioned above. I was thinking the principle is to organize points in a cycle. But it would consider its historic to avoid repetition of pattern.

```<code>A -> B -> C -> D -> E -> A ...
</code>```

I want to avoid A to be the direct child of D again, and B from A etc..
for example next result will be

```<code>B -> A -> D -> C  -> E -> B
</code>```

(no point is the direct parent of last cycle)

The third time, i want A to avoid to be the direct child of E (first cycle) and B (second  cycle) etc...

```<code>A -> E -> C -> B -> D -> A
</code>```

The points don't have to form a single cycle, as long as the problems described above are guaranteed to not happen.

答:
In essence you're performing a verification that the giving->receiving array is a so-called Costas array (i.e. a matrix of binary values where each column and each row holds exactly one 1 value).

Assuming the same set of family members year-on-year, you can build a binary-valued array (row=giver, column=reciever) of the disallowed combinations. You also want to disallow the diagonal self-self combination. Inverting the array gives you the allowed combinations (1=allowed).

Using the array of allowed combinations, you have a few choices:

Enumerate the all possible values of the free bits defining the allowed combinations. Check if the resulting array is a Costas array. If so, the combination is allowed.

Queue the gift givers, and a single array of gift receivers. For each giver, pick an allowed receiver (from the matrix). To help this process the order of gift givers should be from the smallest number of possible receivers to the largest.

In both of the above approaches, you may find that you don't actually have a solution, in which case you will want to relax some of the previous criteria (e.g. remove ban on least recent year) whilst retaining others (i.e. someone can't be given themselves.).


问:
Builder Pattern : Separation of construction from representation
I am reading GoF, and the intent of builder is mentioned as to separate creation of complex object from its representation.

I couldn't understand what representation means in this context.
What does it mean?

The Text parsing example provided in the motivation section doesn't seem to separate construction from representation, but algorithm for interpretation of textual format from creation and representation of converted format.

答:
The representation of interest is here the (presumably) string result obtained from GetASCIIText or GetTexText.

Someone has to create an instance of the abstract TextConverter; this is not shown within the diagram you posted in the question.

Some code somewhere chooses between one of the three sub classes to instantiate and then supplies that to the RTFReader.

This might look as follows:

```<code>var tx = new TexConverter ();
var rdr = new RTFReader ( tx );
rdr.ParseRTF ();
return tx.GetTexText ();
</code>```

and, in another case,

```<code>var cv = new ASCIIConverter ();
var rdr = new RTFReader ( cv );
rdr.ParseRTF ();
return cv.GetASCIIText ();
</code>```

With this additional context, we can see more clearly the separation of construction responsibilities from representation responsibilities, as ParseRTF is reused unchanged between these two snippets even though each snippet generates a different representation.

Further, if we wanted to, we could create an implementation for TextConverter that wrapped the other three and created all those representations with one call to ParseRTF.  This would not be as easy to do if these responsibilities were not separated.

It should be pointed out that in this example, the resulting data structures that are constructed do not necessarily have to conform to each other, so, GetTexText, could, if desired, return a type different from string and different from GetASCIIText; this would illustrate vastly different representations.

ContentLicense: CC BY-SA 4.0

Body:
The representation of interest is here the (presumably) string result obtained from GetASCIIText or GetTexText.

Someone has to create an instance of the abstract TextConverter; this is not shown within the diagram you posted in the question.

Some code somewhere chooses between one of the three sub classes to instantiate and then supplies that to the RTFReader.

This might look as follows:

var tx = new TexConverter ();
var rdr = new RTFReader ( tx );
rdr.ParseRTF ();
return tx.GetTexText ();

and, in another case,

var cv = new ASCIIConverter ();
var rdr = new RTFReader ( cv );
rdr.ParseRTF ();
return cv.GetASCIIText ();

With this additional context, we can see more clearly the separation of construction responsibilities from representation responsibilities, as ParseRTF is reused unchanged between these two snippets even though each snippet generates a different representation.

Further, if we wanted to, we could create an implementation for TextConverter that wrapped the other three and created all those representations with one call to ParseRTF.  This would not be as easy to do if these responsibilities were not separated.

It should be pointed out that in this example, the resulting data structures that are constructed do not necessarily have to conform to each other, so, GetTexText, could, if desired, return a type different from string and different from GetASCIIText; this would illustrate vastly different representations.


问:
Automatic Downcasting
I'm making a framework in Java and have a method in my abstract class, BasicPhase, called processAction (snippet below). It takes two abstract classes as parameters since the user should implement them in child classes. However, it results in the user being required to constantly downcast every time they override the method. How can this be avoided?

BasicPhase.java

```<code>public class BasicPhase {
    ...
    public BasicGameState processAction(BasicAction action, BasicGameState state);
    ...
}
</code>```

Example User Class

MyPhase.java

```<code>public class MyPhase extends BasicPhase {
    @Override
    public BasicGameState processAction(BasicAction basicAction, BasicGameState basicState)  {
        MyGameState state = (MyGameState) basicState; //undesired
        MyAction action = (MyAction) basicAction; //undesired

        //Game Logic Here
    }
}
</code>```

答:
If MyPhase.progressAction would exclusively call methods available in BasicAction or BasicGameState, then there would be no need for any downcast. Those methods might be ordinary methods or methods overridden in MyAction and/or MyGameState. So you should consider to change the design of BasicAction, BasicGameState and/or progressAction to make this possible.

Note, as @ErikEidt correctly stated in his comment, that this may not be the best or most sensible solution for your case, since you gave us not enough information to allow any better advice.

Title: Automatic Downcasting


问:
Is there a design pattern to remove the need to check for flags?
I'm going to save some string payload in the database. I have two global configurations:

encryption

compression

These can be enabled or disabled using the configuration in a way that either only one of them is enabled, both are enabled or both are disabled.

My current implementation is this:

```<code>if (encryptionEnable && !compressEnable) {
    encrypt(data);
} else if (!encryptionEnable && compressEnable) {
    compress(data);
} else if (encryptionEnable && compressEnable) {
    encrypt(compress(data));
} else {
  data;
}
</code>```

I'm thinking about the Decorator pattern. Is it the right choice, or is there perhaps a better alternative?

答:
I guess your question is looking not for practicality, in which case lxrec's answer is the correct one, but to learn about design patterns.

Obviously the command pattern is an overkill for such a trivial problem as the one you propose but for the sake of illustration here it goes:

```<code>public interface Command {
    public String transform(String s);
}

public class CompressCommand implements Command {
    @Override
    public String transform(String s) {
        String compressedString=null;
        //Compression code here
        return compressedString;
    }
}

public class EncryptCommand implements Command {
    @Override
    public String transform(String s) {
        String EncrytedString=null;
        // Encryption code goes here
        return null;
    }

}

public class Test {
    public static void main(String[] args) {
        List<Command> commands = new ArrayList<Command>();
        commands.add(new CompressCommand());
        commands.add(new EncryptCommand());
        String myString="Test String";
        for (Command c: commands){
            myString = c.transform(myString);
        }
        // now myString can be stored in the database
    }
}
</code>```

As you see putting the commands/transformation in a list allows for ther to be executed sequentially. Obviously it will execute both, or only one of them dependind og what you put in the list without if conditions.

Obviously the conditionals will end up in some kind of factory that puts together the command list.

EDIT for @texacre's comment:

There are many ways of avoiding the if conditions in the creational part of the solution, let's take for example a desktop GUI app. You can have checkboxes for the compress and encrypt options. In the on clic event of those checkboxes you instantiate the corresponding command and add it to the list, or remove from the list if you are deselecting the option.

Body:
I guess your question is looking not for practicality, in which case lxrec's answer is the correct one, but to learn about design patterns.

Obviously the command pattern is an overkill for such a trivial problem as the one you propose but for the sake of illustration here it goes:

public interface Command {
    public String transform(String s);
}

public class CompressCommand implements Command {
    @Override
    public String transform(String s) {
        String compressedString=null;
        //Compression code here
        return compressedString;
    }
}

public class EncryptCommand implements Command {
    @Override
    public String transform(String s) {
        String EncrytedString=null;
        // Encryption code goes here
        return null;
    }

}

public class Test {
    public static void main(String[] args) {
        List<Command> commands = new ArrayList<Command>();
        commands.add(new CompressCommand());
        commands.add(new EncryptCommand());
        String myString="Test String";
        for (Command c: commands){
            myString = c.transform(myString);
        }
        // now myString can be stored in the database
    }
}

As you see putting the commands/transformation in a list allows for ther to be executed sequentially. Obviously it will execute both, or only one of them dependind og what you put in the list without if conditions.

Obviously the conditionals will end up in some kind of factory that puts together the command list.

EDIT for @texacre's comment:

There are many ways of avoiding the if conditions in the creational part of the solution, let's take for example a desktop GUI app. You can have checkboxes for the compress and encrypt options. In the on clic event of those checkboxes you instantiate the corresponding command and add it to the list, or remove from the list if you are deselecting the option.


答:
processAction clearly cannot work on the base action and state types, so you need to make the types that need to be passed as parameters specifically the types that processAction can work with. To make the parameter types definable by your derived classes, you need to make the base class generic such that the generic parameters are the types of action and game state the phase accepts.

Do this by making BasicPhase a

```<code>public class BasicPhase<TAction extends BasicAction, TState extends BasicGameState>
</code>```

and the processAction a processAction(TAction action, TState state) then your MyPhase would derive as:

```<code>public class MyPhase extends BasicPhase<MyAction, MyGameState> {
</code>```

Title: Automatic Downcasting

Body:
I'm making a framework in Java and have a method in my abstract class, BasicPhase, called processAction (snippet below). It takes two abstract classes as parameters since the user should implement them in child classes. However, it results in the user being required to constantly downcast every time they override the method. How can this be avoided?

BasicPhase.java

```<code>public class BasicPhase {
    ...
    public BasicGameState processAction(BasicAction action, BasicGameState state);
    ...
}
</code>```

Example User Class

MyPhase.java

```<code>public class MyPhase extends BasicPhase {
    @Override
    public BasicGameState processAction(BasicAction basicAction, BasicGameState basicState)  {
        MyGameState state = (MyGameState) basicState; //undesired
        MyAction action = (MyAction) basicAction; //undesired

        //Game Logic Here
    }
}
</code>```

Body:
processAction clearly cannot work on the base action and state types, so you need to make the types that need to be passed as parameters specifically the types that processAction can work with. To make the parameter types definable by your derived classes, you need to make the base class generic such that the generic parameters are the types of action and game state the phase accepts.

Do this by making BasicPhase a

public class BasicPhase<TAction extends BasicAction, TState extends BasicGameState>

and the processAction a processAction(TAction action, TState state) then your MyPhase would derive as:

public class MyPhase extends BasicPhase<MyAction, MyGameState> {


问:
Using Python's Method Resolution Order for Dependency Injection - is this bad?
I watched Raymond Hettinger's Pycon talk "Super Considered Super" and learned a little bit about Python's MRO (Method Resolution Order) which linearises a classes "parent" classes in a deterministic way. We can use this to our advantage, like in the below code, to do dependency injection. So now, naturally, I want to use super for everything!

In the example below, the User class declares it's dependencies by inheriting from both LoggingService and UserService. This isn't particularly special. The interesting part is that we can use the Method Resolution Order also mock out dependencies during unit testing. The code below creates a MockUserService which inherits from UserService and provides an implementation of the methods we want to mock. In the example below, we provide an implementation of validate_credentials. In order to have MockUserService handle any calls to validate_credentials we need to position it before UserService in the MRO. This done by creating a wrapper class around User called MockUser and having it inherit from User and MockUserService.

Now, when we do MockUser.authenticate and it, in turn, calls to super().validate_credentials() MockUserService is before UserService in the Method Resolution Order and, since it offers a concrete implementation of validate_credentials this implementation will be used. Yay - we've successfully mocked out UserService in our unit tests. Consider that UserService might do some expensive network or database calls - we've just removed the latency factor of this. There is also no risk of UserService touching live/prod data.

```<code>class LoggingService(object):
    """
    Just a contrived logging class for demonstration purposes
    """
    def log_error(self, error):
        pass

class UserService(object):
    """
    Provide a method to authenticate the user by performing some expensive DB or network operation.
    """
    def validate_credentials(self, username, password):
        print('> UserService::validate_credentials')
        return username == 'iainjames88' and password == 'secret'

class User(LoggingService, UserService):
    """
    A User model class for demonstration purposes. In production, this code authenticates user credentials by calling
    super().validate_credentials and having the MRO resolve which class should handle this call.
    """
    def __init__(self, username, password):
        self.username = username
        self.password = password

    def authenticate(self):
        if super().validate_credentials(self.username, self.password):
            return True
        super().log_error('Incorrect username/password combination')
        return False

class MockUserService(UserService):
    """
    Provide an implementation for validate_credentials() method. Now, calls from super() stop here when part of MRO.
    """
    def validate_credentials(self, username, password):
        print('> MockUserService::validate_credentials')
        return True

class MockUser(User, MockUserService):
    """
    A wrapper class around User to change it's MRO so that MockUserService is injected before UserService.
    """
    pass

if __name__ == '__main__':
    # Normal useage of the User class which uses UserService to resolve super().validate_credentials() calls.
    user = User('iainjames88', 'secret')
    print(user.authenticate())

    # Use the wrapper class MockUser which positions the MockUserService before UserService in the MRO. Since the class
    # MockUserService provides an implementation for validate_credentials() calls to super().validate_credentials() from
    # MockUser class will be resolved by MockUserService and not passed to the next in line.
    mock_user = MockUser('iainjames88', 'secret')
    print(mock_user.authenticate())
</code>```

This feels quite clever, but is this a good and valid use of Python's multiple inheritance and Method Resolution Order? When I think about inheritance in the way that I learned OOP with Java this feels completely wrong because we can't say User is a UserService or User is a LoggingService. Thinking that way, using inheritance the way the above code uses it doesn't make much sense. Or is it? If we use inheritance purely just to provide code reuse, and not thinking in terms of parent->children relationships, then this doesn't seem so bad.

Am I doing it wrong?

答:
Using Python's Method Resolution Order for Dependency Injection - is this bad?

No. This is a theoretical intended usage of the C3 linearization algorithm. This goes against your familiar is-a relationships, but some consider composition to be preferred to inheritance. In this case, you composed some has-a relationships. It seems you're on the right track (though Python has a logging module, so the semantics are a bit questionable, but as an academic exercise it's perfectly fine).

I don't think mocking or monkey-patching is a bad thing, but if you can avoid them with this method, good for you - with admittedly more complexity, you have avoided modifying the production class definitions.

Am I doing it wrong?

It looks good. You have overridden a potentially expensive method, without monkey-patching or using a mock patch, which, again, means you haven't even directly modified the production class definitions.

If the intent was to exercise the functionality without actually having credentials in the test, you should probably do something like:

```<code>>>> print(MockUser('foo', 'bar').authenticate())
> MockUserService::validate_credentials
True
</code>```

instead of using your real credentials, and check that the parameters are received correctly, perhaps with assertions (as this is test code, after all.):

```<code>def validate_credentials(self, username, password):
    print('> MockUserService::validate_credentials')
    assert username_ok(username), 'username expected to be ok'
    assert password_ok(password), 'password expected to be ok'
    return True
</code>```

Otherwise, looks like you've figured it out. You can verify the MRO like this:

```<code>>>> MockUser.mro()
[<class '__main__.MockUser'>,
 <class '__main__.User'>,
 <class '__main__.LoggingService'>,
 <class '__main__.MockUserService'>,
 <class '__main__.UserService'>,
 <class 'object'>]
</code>```

And you can verify that the MockUserService has precedence over the UserService.

Body:
Using Python's Method Resolution Order for Dependency Injection - is this bad?

No. This is a theoretical intended usage of the C3 linearization algorithm. This goes against your familiar is-a relationships, but some consider composition to be preferred to inheritance. In this case, you composed some has-a relationships. It seems you're on the right track (though Python has a logging module, so the semantics are a bit questionable, but as an academic exercise it's perfectly fine).

I don't think mocking or monkey-patching is a bad thing, but if you can avoid them with this method, good for you - with admittedly more complexity, you have avoided modifying the production class definitions.

Am I doing it wrong?

It looks good. You have overridden a potentially expensive method, without monkey-patching or using a mock patch, which, again, means you haven't even directly modified the production class definitions.

If the intent was to exercise the functionality without actually having credentials in the test, you should probably do something like:

>>> print(MockUser('foo', 'bar').authenticate())
> MockUserService::validate_credentials
True

instead of using your real credentials, and check that the parameters are received correctly, perhaps with assertions (as this is test code, after all.):

def validate_credentials(self, username, password):
    print('> MockUserService::validate_credentials')
    assert username_ok(username), 'username expected to be ok'
    assert password_ok(password), 'password expected to be ok'
    return True

Otherwise, looks like you've figured it out. You can verify the MRO like this:

>>> MockUser.mro()
[<class '__main__.MockUser'>,
 <class '__main__.User'>,
 <class '__main__.LoggingService'>,
 <class '__main__.MockUserService'>,
 <class '__main__.UserService'>,
 <class 'object'>]

And you can verify that the MockUserService has precedence over the UserService.


答:
I think "design patterns" are unneccesarily geared towards "oo patterns" and completely avoiding much simpler ideas. What we're talking about here is a (simple) data pipeline.

I would try to do it in clojure. Any other language where functions are first-class is probably ok as well. Maybe I could a C# example later on, but it's not as nice.
My way of solving this would be the following steps with some explanations for non-clojurians:

1. Represent a set of transformations.

```<code>(def transformations { :encrypt  (fn [data] ... )
                       :compress (fn [data] ... )})
</code>```

This is a map, i.e. a lookup table/dictionary/whatever, from keywords to functions. Another example (keywords to strings):

```<code>(def employees { :A1 "Alice"
                 :X9 "Bob"})

(employees :A1) ; => "Alice"
(:A1 employees) ; => "Alice"
</code>```

So, writing (transformations :encrypt) or (:encrypt transformations) would return the encrypt function. ((fn [data] ... ) is just a lambda function.)

2. Get the options as a sequence of keywords:

```<code>(defn do-processing [options data] ;function definition
  ...)

(do-processing [:encrypt :compress] data) ;call to function
</code>```

3. Filter all transformations using the supplied options.

```<code>(let [ transformations-to-run (map transformations options)] ... )
</code>```

Example:

```<code>(map employees [:A1]) ; => ["Alice"]
(map employees [:A1 :X9]) ; => ["Alice", "Bob"]
</code>```

4. Combine functions into one:

```<code>(apply comp transformations-to-run)
</code>```

Example:

```<code>(comp f g h) ;=> f(g(h()))
(apply comp [f g h]) ;=> f(g(h()))
</code>```

5. And then together:

```<code>(def transformations { :encrypt  (fn [data] ... )
                       :compress (fn [data] ... )})

(defn do-processing [options data]
  (let [transformations-to-run (map transformations options)
        selected-transformations (apply comp transformations-to-run)]
    (selected-transformations data)))

(do-processing [:encrypt :compress])
</code>```

The ONLY changes if we want to add a new function, say "debug-print", is the following:

```<code>(def transformations { :encrypt  (fn [data] ... )
                       :compress (fn [data] ... )
                       :debug-print (fn [data] ...) }) ;<--- here to add as option

(defn do-processing [options data]
  (let [transformations-to-run (map transformations options)
        selected-transformations (apply comp transformations-to-run)]
    (selected-transformations data)))

(do-processing [:encrypt :compress :debug-print]) ;<-- here to use it
(do-processing [:compress :debug-print]) ;or like this
(do-processing [:encrypt]) ;or like this
</code>```

Body:
I think "design patterns" are unneccesarily geared towards "oo patterns" and completely avoiding much simpler ideas. What we're talking about here is a (simple) data pipeline.

I would try to do it in clojure. Any other language where functions are first-class is probably ok as well. Maybe I could a C# example later on, but it's not as nice.
My way of solving this would be the following steps with some explanations for non-clojurians:

1. Represent a set of transformations.

(def transformations { :encrypt  (fn [data] ... )
                       :compress (fn [data] ... )})

This is a map, i.e. a lookup table/dictionary/whatever, from keywords to functions. Another example (keywords to strings):

(def employees { :A1 "Alice"
                 :X9 "Bob"})

(employees :A1) ; => "Alice"
(:A1 employees) ; => "Alice"

So, writing (transformations :encrypt) or (:encrypt transformations) would return the encrypt function. ((fn [data] ... ) is just a lambda function.)

2. Get the options as a sequence of keywords:

(defn do-processing [options data] ;function definition
  ...)

(do-processing [:encrypt :compress] data) ;call to function

3. Filter all transformations using the supplied options.

(let [ transformations-to-run (map transformations options)] ... )

Example:

(map employees [:A1]) ; => ["Alice"]
(map employees [:A1 :X9]) ; => ["Alice", "Bob"]

4. Combine functions into one:

(apply comp transformations-to-run)

Example:

(comp f g h) ;=> f(g(h()))
(apply comp [f g h]) ;=> f(g(h()))

5. And then together:

(def transformations { :encrypt  (fn [data] ... )
                       :compress (fn [data] ... )})

(defn do-processing [options data]
  (let [transformations-to-run (map transformations options)
        selected-transformations (apply comp transformations-to-run)]
    (selected-transformations data)))

(do-processing [:encrypt :compress])

The ONLY changes if we want to add a new function, say "debug-print", is the following:

(def transformations { :encrypt  (fn [data] ... )
                       :compress (fn [data] ... )
                       :debug-print (fn [data] ...) }) ;<--- here to add as option

(defn do-processing [options data]
  (let [transformations-to-run (map transformations options)
        selected-transformations (apply comp transformations-to-run)]
    (selected-transformations data)))

(do-processing [:encrypt :compress :debug-print]) ;<-- here to use it
(do-processing [:compress :debug-print]) ;or like this
(do-processing [:encrypt]) ;or like this


问:
How to simulate method overloading in langs without such feature?
Langs like Java knows about true method overloading:

```<code>class Overload {
  void demo (int a) {
   System.out.println ("a: " + a);
  }
  void demo (int a, int b) {
   System.out.println ("a and b: " + a + "," + b);
  }
}
</code>```

Whether langs like PHP — doesn't. So when you stand in front of a problem of processing something depending of context, which ways will you think of and which usually choose?

Typical problem could be some abstract payment system, where outside user should not think about concrete payment provider details (which could be different) and just call Provider.pay(PayDetails). In interface of PaymentProvider we must fix that it works with PayDetails. But in concrete implementations concrete provider could work for example only with it's own ConcretePayDetails.

Is it worth to polyfill such things as ad-hoc polymorphism in langs that dont' support it?

How to better solve context-related methods dispatching in such langs?

Example of possible implementation available at https://github.com/garex/php-ad-hoc-polymorphism-polyfill/

答:
Ad-hoc polymorphism (method “overloading”) is a quite unremarkable feature of a language and does not make it more expressive. I.e. there is literally nothing that overloading lets you do that you can't easily do without (ignoring generic programming). All it does is providing a shortcut syntax.

When a language with ad-hoc polymorphism (such as Java) compiles a call to Overload#demo(…), it sees the different overloads void demo(int) and void demo(int, int) as entirely different functions. To resolve the call, the compiler matches the call signature to the available overloads, and selects the best match. This can be re-implemented in a dynamic language by inspecting the number and types of arguments. When ad-hoc polymorphism is resolved based on argument types during runtime, this is actually more expressive than ad-hoc polymorphism, and might be called multi-methods instead.

But we don't need any fancy metaprogramming to get the equivalent of ad-hoc polymorphism. Instead, we can simply give a different name to each overload, and require the programmer to select the proper overload when writing the code. This is exactly equivalent to the stuff the Java compiler would be doing, although clearly more error prone. You actually see this sometime in C APIs where there might be a function something(int) and something2(int, int) where we have different numbers of arguments, or int atoi(const char*) and double atof(const char*) where we have different types. In your example, your interface might be implemented as Provider.payWithPayDetails(PayDetails) instead of Provider.pay(PayDetails).

So if ad-hoc polymorphism is pretty much useless, why do languages have this feature? There are two main reason:

In Java, ad-hoc polymorphism allows us to simulate optional arguments, and to provide multiple constructors with different signatures. E.g. we could initialize a point from three numbers Point(double x, double y, double z), or as a copy constructor from another point Point(Point orig). In my experience, it would have been better for the language to provide actual optional arguments, and to suggest the use of suitably named static factory functions instead of overloading constructors. Note that PHP has real optional arguments, and no need to fake them via ad-hoc polymorphism.

Operator overloading would usually be implemented using ad-hoc polymorphism, since you can't give a different name to the same operator just to use it for different types. You wouldn't want to have +int and +double (though OCaml actually does that with + and +. operators, I think). In a wider sense, any function can be seen as an operator (or at least an operation) on some value. This comes in quite useful when writing generic code, e.g. with C++ templates (“argument-dependent lookup”) or Haskell's generics. Especially with Haskell, we might have dozens of definitions for a global function like fmap, but this can be resolved during compilation to a single instance. However, this use case does not apply to Java where interfaces are the only mechanism to define abstract types.


问:
Is Python's inheritance an "is-a" style of inheritance or a compositional style?
Given that Python allows for multiple inheritance, what does idiomatic inheritance in Python look like?

In languages with single inheritance, like Java, inheritance would be used when you could say that one object "is-a" of an another object and you want to share code between the objects (from the parent object to the child object). For example, you could say that Dog is a Animal:

```<code>public class Animal {...}
public class Dog extends Animal {...}
</code>```

But since Python supports multiple inheritance we can create an object by composing many other objects together. Consider the example below:

```<code>class UserService(object):
    def validate_credentials(self, username, password):
        # validate the user credentials are correct
        pass

class LoggingService(object):
    def log_error(self, error):
        # log an error
        pass

class User(UserService, LoggingService):
    def __init__(self, username, password):
        self.username = username
        self.password = password

    def authenticate(self):
        if not super().validate_credentials(self.username, self.password):
            super().log_error('Invalid credentials supplied')
            return False
         return True
</code>```

Is this an acceptable or good use of multiple inheritance in Python? Instead of saying inheritance is when one object "is-a" of another object, we create a User model composed of UserService and LoggingService.

All the logic for database or network operations can be kept separate from the User model by putting them in the UserService object and keep all the logic for logging in the LoggingService.

I see some problems with this approach are:

Does this create a God object? Since User inherits from, or is composed of, UserService and LoggingService is it really following the principle of single responsibility?

In order to access methods on a parent/next-in-line object (e.g., UserService.validate_credentials we have to use super. This makes it a little bit more difficult to see which object is going to handle this method and isn't as clear as, say, instantiating UserService and doing something like self.user_service.validate_credentials

What would be the Pythonic way to implement the above code?

答:
Is Python's inheritance an “is-a” style of inheritance or a compositional style?

Python supports both styles. You are demonstrating the has-a relationship of composition, where a User has logging functionality from one source and credential validation from another source.  The LoggingService and UserService bases are mixins: they provide functionality and are not intended to be instantiated by themselves.

By composing mixins in the type, you have a User that can Log, but who must add his own instantiation functionality.

This does not mean that one cannot stick to single inheritance. Python supports that too. If your ability to develop is hampered by the complexity of multiple inheritance, you can avoid it until you feel more comfortable or come to a point in design where you believe it to be worth the trade-off.

Does this create a God object?

The logging does seem somewhat tangential - Python does have its own logging module with a logger object, and the convention is that there is one logger per module.

But set the logging module aside. Perhaps this violates single-responsibility, but perhaps, in your specific context, it is crucial to defining a User. Descretizing responsibility can be controversial. But the broader principle is that Python allows the user to make the decision.

Is super less clear?

super is only necessary when you need to delegate to a parent in the Method Resolution Order (MRO) from inside of a function of the same name. Using it instead of hard-coding a call to the parent's method is a best-practice. But if you were not going to  hard-code the parent, you don't need super.

In your example here, you only need to do self.validate_credentials. self is not more clear, from your perspective. They both follow the MRO. I would simply use each where appropriate.

If you had called authenticate, validate_credentials instead, you would have needed to use super (or hard-code the parent) to avoid a recursion error.

Alternative Code suggestion

So, assuming the semantics are OK (like logging), what I would do is, in class User:

```<code>    def validate_credentials(self): # changed from "authenticate" to
                                    # demonstrate need for super
        if not super().validate_credentials(self.username, self.password):
            # just use self on next call, no need for super:
            self.log_error('Invalid credentials supplied')
            return False
        return True
</code>```

Body:
Is Python's inheritance an “is-a” style of inheritance or a compositional style?

Python supports both styles. You are demonstrating the has-a relationship of composition, where a User has logging functionality from one source and credential validation from another source.  The LoggingService and UserService bases are mixins: they provide functionality and are not intended to be instantiated by themselves.

By composing mixins in the type, you have a User that can Log, but who must add his own instantiation functionality.

This does not mean that one cannot stick to single inheritance. Python supports that too. If your ability to develop is hampered by the complexity of multiple inheritance, you can avoid it until you feel more comfortable or come to a point in design where you believe it to be worth the trade-off.

Does this create a God object?

The logging does seem somewhat tangential - Python does have its own logging module with a logger object, and the convention is that there is one logger per module.

But set the logging module aside. Perhaps this violates single-responsibility, but perhaps, in your specific context, it is crucial to defining a User. Descretizing responsibility can be controversial. But the broader principle is that Python allows the user to make the decision.

Is super less clear?

super is only necessary when you need to delegate to a parent in the Method Resolution Order (MRO) from inside of a function of the same name. Using it instead of hard-coding a call to the parent's method is a best-practice. But if you were not going to  hard-code the parent, you don't need super.

In your example here, you only need to do self.validate_credentials. self is not more clear, from your perspective. They both follow the MRO. I would simply use each where appropriate.

If you had called authenticate, validate_credentials instead, you would have needed to use super (or hard-code the parent) to avoid a recursion error.

Alternative Code suggestion

So, assuming the semantics are OK (like logging), what I would do is, in class User:

    def validate_credentials(self): # changed from "authenticate" to
                                    # demonstrate need for super
        if not super().validate_credentials(self.username, self.password):
            # just use self on next call, no need for super:
            self.log_error('Invalid credentials supplied')
            return False
        return True


答:
[ Essentially, my answer is a follow-on to the answer by @Ixrec above. ]

An important question: is the number of distinct combinations that you need to cover is going to grow?  You are better aware of your subject domain.  This is your judgement to make.

Can the number of variants possibly grow?  Well, that's not inconceivable. For example, you may need to accommodate more different encryption algorithms.

If you anticipate that the number of distinct combinations is going to grow, then Strategy pattern can help you.  It's designed to encapsulate algorithms and provide an interchangeable interface to the calling code.  You would still have a small amount of logic when you create (instantiate) the appropriate strategy for each particular string.

You have commented above that you don't expect the requirements to change.  If you don't expect that the number of variants would grow (or if you can defer this refactoring), then keep the logic the way it is.  Currently, you have a small and manageable amount of logic.  (Maybe put a note to self in the comments about a possible refactoring to a Strategy pattern.)


问:
Class design, responsibility granulation, efficiency and performance
I am in a design dilemma. I have a set of data that can be interpreted in numerous ways, but I cannot really decide how finely grained should it be. To illustrate it with some simple code:

class Base {
    Datamembers data;
    virtual void doStuff() = 0;
};

class T1 : public Base {
    void doStuff() {
        // do T1 stuff
    }
};

class T2 : public Base {
    void doStuff() {
        // do T2 stuff
    }
};

class ...

// ---------------------------

class Master {
    enum Role {
        T1, T2 ...
    };

    Role r;
    Datamembers data;

    void doStuff() {
        switch (r) {
        case T1:
            // do T1 stuff
            return;
        case T2:
            // do T2 stuff
            return;
        case ...
        }
    }
};
```

In reality the number of responsibilities is much higher than 2, currently still in the two digit range, but may grow further. Also, it is not one, but several doStuff()s at play.

In the first case, the data is encapsulated in a base class, and doStuff() is a pure virtual, which each derived class implements. Each responsibility is encapsulated in its own, dedicated type.

In the second case doStuff() is not a virtual function, and the responsibility is stored as an extra member in a Role, and the method switches the role and executes the appropriate code.

The two designs achieve the same goal in a different way, but what are the consequences?

Code maintenance:

The first approach seems cleaner, but even though usually clean implies maintainable, I feel it is kind of fragmented, which may end up reducing the ease of maintenance.

In the second approach all the code for the different responsibilities is crammed in the same place, which may sound dirty, but in many cases having it all in the same place may actually be easier, since all you have to do is scroll rather than jump around different files. But then again... it is still a big wall of code, not obvious in the example code above, but in practice it will be 4-5 digit lines of code. Although there is an easy remedy for that, just implement a function for each case that takes this as a parameter to access the data and force inlining to eliminate the overhead of extra function calls (even if not virtual).

Performance:

In my case, I deal with massive trees of objects, where doStuff() will be executed in tight loops, traversing that tree.

In approach one, the method is virtual, this means I get penalty for the indirection. Also, the code is spread across multiple types, which may end up fragmenting it in memory, reducing cache efficiency.

In the second approach the method is not virtual, and all code is essentially in a single function, which means it will be tighter in memory, and potentially more cache friendly. There is the switching penalty vs the indirection and fragmentation of the first approach.

Memory usage:

Although it is missing from the example code above, the hierarchy does have a constructor with plenty of arguments. Meaning that in the first approach each derived class will have its own constructor with the same parameters, redirecting those to the base class constructor. This, aside from tedious to implement for each type, also adds some code bloat. And there is the overhead of the v-tables. Both the extra constructors and v-tables are avoided in the second approach.

Obviously, I've made some considerations, and had this been a smaller undertaking, I'd do both and compare. But it is actually a lot of work and it is not really possible, so I'd appreciate some experienced opinions - are my considerations valid, am I missing something, is there another, better way to do it?

As it seems the scale of the problem isn't entirely clear, I will just summarize it. I am talking about an object tree, potentially tens of millions of nodes big, a responsibility hierarchy of currently 30 roles, expected to grow to over 100. Right now I have approximately about 200 lines of code per role, although the number varies. Parallelization is not an option, since node result depends on parent or children nodes results, so I am limited to a single thread traversing the tree, currently processing 200-300k nodes a second.

答:
As it seems the scale of the problem isn't entirely clear, I will just
  summarize it. I am talking about an object tree, potentially tens of
  millions of nodes big, a responsibility hierarchy of currently 30
  roles, expected to grow to over 100. [...] currently processing
  200-300k nodes a second.

With these kinds of numbers, and provided that there is a strong notion of quality that arises from being able to process nodes faster, I wouldn't call these concerns premature since they relate to interface design in a fairly broad context more than implementation in a teeny, isolated one.

I'm going to venture the unpopular route and actually suggest the second solution for both efficiency and maintainability reasons provided that:

There are very few places that performs this kind of type check.

The state for each role (Datamembers as you've shown), is homogeneous (does not vary) per Role. This part is key, as otherwise my entire answer will be invalidated.

Datamembers is fairly small.

You do not need an open architecture in this context (ex: no need for an external client, say a plugin, to add new roles on the fly).

You find it easier in this case to debug/trace through more centralized code.

Dynamic Dispatch is Cheap Here

Now as a caveat:

Currently that's about 30 roles for about 6k lines of code. On
  average, 200 lines of code. And it is mostly arithmetic on the
  members. There is no branching, no function calling or any of that
  stuff.

With these kinds of numbers, the cost of dynamic dispatch becomes especially cheap in comparison (but this is not the cost we necessarily want to avoid the most). The pipeline ends up being plenty deep enough for effective branch prediction to work, and we still often need some form of branching anyway for the switch. The cost of the optimization barrier (being unable to inline function calls, i.e.) for functions that span an average of 200 LOC is hardly anything to worry about.

Memory Efficiency

There's a bigger, glaring cost I think that people are missing here, and it relates to memory. Given #2 (homogeneous data, only different actions on the same data), a solution that involves polymorphism is going to imply:

A dynamic allocation per role and a loss of a contiguous representation within a tree node.

A vptr overhead per role (this would be quite trivial if sizeof(Datamembers) is hundreds of bytes, e.g., but it would be far from trivial if it's like 32 bytes). This is going to be a bit larger than, say, a 16-bit or 32-bit index on 64-bit systems.

Yet another pointer overhead per tree node to store the memory address to the dynamically-allocated role.

1 could be cheapened considerably using a fixed allocator, and a single fixed allocator can be used for all roles given the homogeneity of Datamembers since they'll all be the same size. Yet that's also degrading the maintainability of your code when a simple alternate solution exists which would allow you to store Datamembers contiguously with your tree nodes using this second Master solution without reaching for custom allocators.

The costs associated with 2 and 3 are unavoidable with a polymorphic solution.

This is the most glaring efficiency and maintenance overhead to me, and the switch version gets around that completely. It's not so much to avoid dynamic dispatch, it's to avoid 1, 2, and 3 above. The biggest problem is that, when processing hundreds of thousands of nodes per second (or more potentially as you optimize further), a polymorphic memory representation would look like this:

When these two memory blocks could potentially be coalesced into a single, contiguous block otherwise.

Maintainability

Given that 1-5 in the top list are valid assumptions, then you might even have an easier time maintaining the second version. It depends on the motions you have to go through when adding a new role.

Naturally in a codebase that uses conditionals in 50 different decentralized places checking for the type of object being passed to it, introducing a new type is going to be a horrendous nightmare (as well as extremely error-prone). But if you have 3 centralized places, it might be even easier with the switch.

This is considering things from a post-optimization side, taking into account that speeding up the first solution will likely involve custom memory allocators and so forth. At the end of this, the second solution might very well be just as easy or easier to maintain.

Hybrid Solution

You can potentially get a hybrid and balance the performance and maintainability needs through your own custom table of function pointers. Note that this is not about function pointers vs. virtual functions (the latter can actually be more efficient in non-homogeneous cases where a single object stores a single vptr as opposed to many function pointers), but about avoiding the memory inefficiencies above while still getting the ability to easily extend the number of roles you can support.

The solution might look like this:

// We have one of these per *type* of role, not per role instance.
// This is like a simulated vtable, but we're not doing it to avoid
// virtual function calls (that would almost always be silly).
// We're doing it to avoid memory fragmentation since we're facing a
// homogeneous data context where sizeof(Role) is always going to be the
// same regardless of the type of role.
struct Role {
    // `data` could be const here depending on whether roles mutate the data.
    typedef void RoleFunction(Datamembers& data);

    RoleFunction* func1;
    RoleFunction* func2;
    // etc
};

// Add new role entries here with the appropriate function pointers set.
// The index can be stored in your tree nodes to indicate which role each
// node has.
vector<Role> roles;

// Store this in your tree nodes.
DataMembers data;
int role_type;      // index into 'roles' above.
... // other stuff you need with your tree node -- arranged to
    // minimize padding (typically descending order from biggest
    // to smallest).
```

... something to this effect. With that the maintenance cost of implementing a new role shrinks down to just implementing a few functions conforming to this RoleFunction signature, and adding pointers to them to this Master class in the form of a bundled Role entry. The resulting index can then be used to associate which role each tree node has.

With this you avoid the memory inefficiencies described above while retaining the ability to easily extend this solution wherever you want (can implement all your roles in one source file if you like).

The dynamic dispatch overhead is still there, but it was never a very big cost in this kind of scenario with a couple hundred lines of code per average to execute (even the optimization barrier will typically be moot with such a deep pipeline).

Body:
As it seems the scale of the problem isn't entirely clear, I will just
  summarize it. I am talking about an object tree, potentially tens of
  millions of nodes big, a responsibility hierarchy of currently 30
  roles, expected to grow to over 100. [...] currently processing
  200-300k nodes a second.

With these kinds of numbers, and provided that there is a strong notion of quality that arises from being able to process nodes faster, I wouldn't call these concerns premature since they relate to interface design in a fairly broad context more than implementation in a teeny, isolated one.

I'm going to venture the unpopular route and actually suggest the second solution for both efficiency and maintainability reasons provided that:

There are very few places that performs this kind of type check.

The state for each role (Datamembers as you've shown), is homogeneous (does not vary) per Role. This part is key, as otherwise my entire answer will be invalidated.

Datamembers is fairly small.

You do not need an open architecture in this context (ex: no need for an external client, say a plugin, to add new roles on the fly).

You find it easier in this case to debug/trace through more centralized code.

Dynamic Dispatch is Cheap Here

Now as a caveat:

Currently that's about 30 roles for about 6k lines of code. On
  average, 200 lines of code. And it is mostly arithmetic on the
  members. There is no branching, no function calling or any of that
  stuff.

With these kinds of numbers, the cost of dynamic dispatch becomes especially cheap in comparison (but this is not the cost we necessarily want to avoid the most). The pipeline ends up being plenty deep enough for effective branch prediction to work, and we still often need some form of branching anyway for the switch. The cost of the optimization barrier (being unable to inline function calls, i.e.) for functions that span an average of 200 LOC is hardly anything to worry about.

Memory Efficiency

There's a bigger, glaring cost I think that people are missing here, and it relates to memory. Given #2 (homogeneous data, only different actions on the same data), a solution that involves polymorphism is going to imply:

A dynamic allocation per role and a loss of a contiguous representation within a tree node.

A vptr overhead per role (this would be quite trivial if sizeof(Datamembers) is hundreds of bytes, e.g., but it would be far from trivial if it's like 32 bytes). This is going to be a bit larger than, say, a 16-bit or 32-bit index on 64-bit systems.

Yet another pointer overhead per tree node to store the memory address to the dynamically-allocated role.

1 could be cheapened considerably using a fixed allocator, and a single fixed allocator can be used for all roles given the homogeneity of Datamembers since they'll all be the same size. Yet that's also degrading the maintainability of your code when a simple alternate solution exists which would allow you to store Datamembers contiguously with your tree nodes using this second Master solution without reaching for custom allocators.

The costs associated with 2 and 3 are unavoidable with a polymorphic solution.

This is the most glaring efficiency and maintenance overhead to me, and the switch version gets around that completely. It's not so much to avoid dynamic dispatch, it's to avoid 1, 2, and 3 above. The biggest problem is that, when processing hundreds of thousands of nodes per second (or more potentially as you optimize further), a polymorphic memory representation would look like this:

When these two memory blocks could potentially be coalesced into a single, contiguous block otherwise.

Maintainability

Given that 1-5 in the top list are valid assumptions, then you might even have an easier time maintaining the second version. It depends on the motions you have to go through when adding a new role.

Naturally in a codebase that uses conditionals in 50 different decentralized places checking for the type of object being passed to it, introducing a new type is going to be a horrendous nightmare (as well as extremely error-prone). But if you have 3 centralized places, it might be even easier with the switch.

This is considering things from a post-optimization side, taking into account that speeding up the first solution will likely involve custom memory allocators and so forth. At the end of this, the second solution might very well be just as easy or easier to maintain.

Hybrid Solution

You can potentially get a hybrid and balance the performance and maintainability needs through your own custom table of function pointers. Note that this is not about function pointers vs. virtual functions (the latter can actually be more efficient in non-homogeneous cases where a single object stores a single vptr as opposed to many function pointers), but about avoiding the memory inefficiencies above while still getting the ability to easily extend the number of roles you can support.

The solution might look like this:

// We have one of these per *type* of role, not per role instance.
// This is like a simulated vtable, but we're not doing it to avoid
// virtual function calls (that would almost always be silly).
// We're doing it to avoid memory fragmentation since we're facing a
// homogeneous data context where sizeof(Role) is always going to be the
// same regardless of the type of role.
struct Role {
    // `data` could be const here depending on whether roles mutate the data.
    typedef void RoleFunction(Datamembers& data);

    RoleFunction* func1;
    RoleFunction* func2;
    // etc
};

// Add new role entries here with the appropriate function pointers set.
// The index can be stored in your tree nodes to indicate which role each
// node has.
vector<Role> roles;

// Store this in your tree nodes.
DataMembers data;
int role_type;      // index into 'roles' above.
... // other stuff you need with your tree node -- arranged to
    // minimize padding (typically descending order from biggest
    // to smallest).

... something to this effect. With that the maintenance cost of implementing a new role shrinks down to just implementing a few functions conforming to this RoleFunction signature, and adding pointers to them to this Master class in the form of a bundled Role entry. The resulting index can then be used to associate which role each tree node has.

With this you avoid the memory inefficiencies described above while retaining the ability to easily extend this solution wherever you want (can implement all your roles in one source file if you like).

The dynamic dispatch overhead is still there, but it was never a very big cost in this kind of scenario with a couple hundred lines of code per average to execute (even the optimization barrier will typically be moot with such a deep pipeline).


问:
Memory management for fast message passing between threads in C++
Suppose there are two threads, which communicate by asynchronously sending data messages to each other. Each thread has some kind of message queue.

My question is very low level: What can be expected to be the most efficient way to manage the memory? I can think of several solutions:

Sender creates the object via new. Receiver calls delete.

Memory pooling (to transfer the memory back to the sender)

Garbage collection (e.g., Boehm GC)

(if the objects are small enough) copy by value to avoid heap allocation completely

1) is the most obvious solution, so I'll use it for a prototype. Chances are that it is already good enough. But independent of my specific problem, I wonder which technique is most promising if you are optimizing for performance.

I would expect pooling to be theoretically the best, especially because you can use extra knowledge about the flow of information between the threads. However, I fear that it is also the most difficult to get right. Lots of tuning... :-(

Garbage collection should be quite easy to add afterwards (after solution 1), and I would expect it to perform very well. So, I guess that it is the most practical solution if 1) turns out to be too inefficient.

If the objects are small and simple, copy by value might be the fastest. However, I fear that it forces unnecessary limitations on the implementation of the supported messages, so I want to avoid it.

答:
If the objects are small and simple, copy by value might be the
  fastest. However, I fear that it forces unnecessary limitations on the
  implementation of the supported messages, so I want to avoid it.

If you can anticipate an upper bound char buf[256], e.g. A practical alternative  if you cannot which only invokes heap allocations in the rare cases:

```<code>struct Message
{
    // Stores the message data.
    char buf[256];

    // Points to 'buf' if it fits, heap otherwise.
    char* data;
};
</code>```

Body:
If the objects are small and simple, copy by value might be the
  fastest. However, I fear that it forces unnecessary limitations on the
  implementation of the supported messages, so I want to avoid it.

If you can anticipate an upper bound char buf[256], e.g. A practical alternative  if you cannot which only invokes heap allocations in the rare cases:

struct Message
{
    // Stores the message data.
    char buf[256];

    // Points to 'buf' if it fits, heap otherwise.
    char* data;
};


问:
Is storing data directly in a list node better than storing a pointer to data?
Suppose we have two different doubly-linked list structures:

One has content of the node embedded directly in the node:

```<code>struct Content {
    // some stuff
};
struct Node {
    struct Node *next;
    struct Node *prev;
    struct Content content;
}
</code>```

The other has a pointer to content:

```<code>struct Content;
struct Node {
    struct Node *next;
    struct Node *prev;
    struct Content *content;
}
</code>```

What are considerations to prefer one option to the other? The points can be about everything: performance in different conditions, architecture, ease of modification, ease of manipulating the list, etc.

I'd like to gather knowledge about the trade-offs present.

Shown code is C, but the question also applies to C++, or any other language which has explicit pointers.

答:
Critical Path: Element Traversal

Let's say your most critical loops sequentially iterate through a list and access Content. In that case, typically in descending order of efficiency and ascending order of flexibility:

1. Intrusive C-Style List Node

The highest performance and least amount of flexibility is often going to go to the "classic" C-style intrusive linked list backed by a fixed allocator. The list pointers and contents are inseparably tied together, yielding a very inflexible (but often most compact) solution, like so:

```<code>struct ContentNode {
    // The content data is *directly* embedded here (either below or above
    // these pointers for optimal alignment at the cost of minimal padding).
    struct ContentNode *prev;
    struct ContentNode *next;
};
</code>```

This is only sometimes more efficient than 2 below while always being far less flexible. It only provides a benefit over the second solution if you can reduce the amount of padding by directly embedding the contents into the list node itself.

The level of flexibility lost here is enormous as the notion of element and list node fuse into one inseparable, tightly-bundled concept. And it's also quite dumb to use (in my strong opinion) unless you are first using a fixed allocator to give back a lot of the spatial locality that linked structures generally lack.

Yet the most performance-critical areas of a codebase will often be looking at elements that are aggregated into one primary data structure (possibly with auxiliary data structures pointing to them, but still one main data structure). In that case, your profiling/tuning sessions might have you ultimately reaching for this kind of very-inflexible solution in some very isolated, performance-critical section of your codebase.

2. Non-Intrusive, Contiguous List Node

This would be like your first version, and is dramatically more flexible as Content and Node do not have to be inseparable (Content could be stored in other data structures that own its memory, e.g.).

```<code>struct Node {
    struct Node *next;
    struct Node *prev;
    struct Content content;
}
</code>```

This only costs more than 1 in the rare event that it results in more padding, yet is always more flexible as it decouples Content from the linked list representation.

3. Disjointed List Node

This describes your second solution and tends to be the least efficient as a result of additional cache misses, page faults, and the need for an additional pointer to be stored (more memory usage overall).

```<code>struct Node {
    struct Node *next;
    struct Node *prev;
    struct Content *content;
}
</code>```

Yet this is the easiest way to achieve flexibility, especially in C if you turn content into a void pointer, as you can generalize your linked list very easily this way. Another way to generalize is to use variable-length structs.

Fixed Allocator

In these cases, where performance is a top priority and the critical paths of the list iterate through list elements and access them, it's insane not to use a fixed allocator.

The biggest immediate performance concern of linked lists in cases where the nodes/elements are smallish in size is the loss of contiguity ("disjointed memory") which translates to at least more compulsory cache misses and page faults and possibly even more non-compulsory ones as well.

The fixed allocator is an easy "reach-around" solution when you are inevitably stuck with a linked structure to dramatically reduce cache misses/page faults.

"Efficient"

It's worth noting that the differences between these diminish if the size of the Content data fields are really large. They show up the most if Content is really small (ex: 16 bytes, maybe 64 bytes, not 400 bytes). If Content is huge (hundreds of bytes or more), then the differences start to become increasingly moot as well as the need for a fixed allocator.

Critical Path: List Manipulation

Let's say, instead, that your most critical paths of execution don't even inspect Content data fields and just manipulate list pointers.

In that case, the tables turn. Now 3 becomes the most efficient solution as a result of hot/cold field splitting (Content fields becomes cold data, rarely accessed, and the list pointers become hot data, frequently accessed).

In this case, you still want to use a fixed allocator pooling chunks of data from contiguous pooled memory for the Node (don't have to for Content quite as much here given that it's cold) to reduce page faults and cache misses (at least compulsory ones even if you end up totally rearranging the list).

When combined with the fixed allocator and the hot/cold field splitting, now more nodes can be allocated and accessed without triggering further page faults/cache misses as a result of the smaller size per node (with the cold Content data being stored elsewhere).

All the dynamics here are going to be related to memory efficiency with respect to the memory hierarchy. If you want to get the most out of your linked structures (trees and linked lists), then this is the place to study.

Body:
Critical Path: Element Traversal

Let's say your most critical loops sequentially iterate through a list and access Content. In that case, typically in descending order of efficiency and ascending order of flexibility:

1. Intrusive C-Style List Node

The highest performance and least amount of flexibility is often going to go to the "classic" C-style intrusive linked list backed by a fixed allocator. The list pointers and contents are inseparably tied together, yielding a very inflexible (but often most compact) solution, like so:

struct ContentNode {
    // The content data is *directly* embedded here (either below or above
    // these pointers for optimal alignment at the cost of minimal padding).
    struct ContentNode *prev;
    struct ContentNode *next;
};

This is only sometimes more efficient than 2 below while always being far less flexible. It only provides a benefit over the second solution if you can reduce the amount of padding by directly embedding the contents into the list node itself.

The level of flexibility lost here is enormous as the notion of element and list node fuse into one inseparable, tightly-bundled concept. And it's also quite dumb to use (in my strong opinion) unless you are first using a fixed allocator to give back a lot of the spatial locality that linked structures generally lack.

Yet the most performance-critical areas of a codebase will often be looking at elements that are aggregated into one primary data structure (possibly with auxiliary data structures pointing to them, but still one main data structure). In that case, your profiling/tuning sessions might have you ultimately reaching for this kind of very-inflexible solution in some very isolated, performance-critical section of your codebase.

2. Non-Intrusive, Contiguous List Node

This would be like your first version, and is dramatically more flexible as Content and Node do not have to be inseparable (Content could be stored in other data structures that own its memory, e.g.).

struct Node {
    struct Node *next;
    struct Node *prev;
    struct Content content;
}

This only costs more than 1 in the rare event that it results in more padding, yet is always more flexible as it decouples Content from the linked list representation.

3. Disjointed List Node

This describes your second solution and tends to be the least efficient as a result of additional cache misses, page faults, and the need for an additional pointer to be stored (more memory usage overall).

struct Node {
    struct Node *next;
    struct Node *prev;
    struct Content *content;
}

Yet this is the easiest way to achieve flexibility, especially in C if you turn content into a void pointer, as you can generalize your linked list very easily this way. Another way to generalize is to use variable-length structs.

Fixed Allocator

In these cases, where performance is a top priority and the critical paths of the list iterate through list elements and access them, it's insane not to use a fixed allocator.

The biggest immediate performance concern of linked lists in cases where the nodes/elements are smallish in size is the loss of contiguity ("disjointed memory") which translates to at least more compulsory cache misses and page faults and possibly even more non-compulsory ones as well.

The fixed allocator is an easy "reach-around" solution when you are inevitably stuck with a linked structure to dramatically reduce cache misses/page faults.

"Efficient"

It's worth noting that the differences between these diminish if the size of the Content data fields are really large. They show up the most if Content is really small (ex: 16 bytes, maybe 64 bytes, not 400 bytes). If Content is huge (hundreds of bytes or more), then the differences start to become increasingly moot as well as the need for a fixed allocator.

Critical Path: List Manipulation

Let's say, instead, that your most critical paths of execution don't even inspect Content data fields and just manipulate list pointers.

In that case, the tables turn. Now 3 becomes the most efficient solution as a result of hot/cold field splitting (Content fields becomes cold data, rarely accessed, and the list pointers become hot data, frequently accessed).

In this case, you still want to use a fixed allocator pooling chunks of data from contiguous pooled memory for the Node (don't have to for Content quite as much here given that it's cold) to reduce page faults and cache misses (at least compulsory ones even if you end up totally rearranging the list).

When combined with the fixed allocator and the hot/cold field splitting, now more nodes can be allocated and accessed without triggering further page faults/cache misses as a result of the smaller size per node (with the cold Content data being stored elsewhere).

All the dynamics here are going to be related to memory efficiency with respect to the memory hierarchy. If you want to get the most out of your linked structures (trees and linked lists), then this is the place to study.