问:
When to stop functional decomposition and commence algorithm design
In all my experience decomposing functional requirements from the top down through a hierarchy and successfully using that hierarchy as the basis for building and implementing some pretty cool systems from the bottom up, it shames me to admit that I do not have a guaranteed method for ensuring that all the levels in the functional decomposition hierarchy are at that perfect place to decompose no further.

The question is:  What are the tangible flags or indicators or signals to use that confirm that functional decomposition to a given leaf is both complete and correct so that algorithm design can commence.

答: Continue decomposing functional requirements into smaller requirements until it becomes possible to write a clear, specific, measurable test for each and every smaller requirement such that, when the test is executed and passes, both the customer and the development/QA teams can unambiguously declare that the requirement has been met.</p>


问:
Is it always a best practice to write a function for anything that needs to repeat twice?
Myself, I can't wait to write a function when I need to do something more than twice. But when it comes to things that only appear twice, it's a bit more tricky.

For code that needs more than two lines, I'll write a function. But when facing things like:

```<code>print "Hi, Tom"
print "Hi, Mary"
</code>```

I'm hesitant to write:

```<code>def greeting(name):
    print "Hi, " + name

greeting('Tom')
greeting('Mary')
</code>```

The second one seems too much, doesn't it?

But what if we have:

```<code>for name in vip_list:
    print name
for name in guest_list:
    print name
</code>```

And here is the alternative:

```<code>def print_name(name_list):
    for name in name_list:
        print name

print_name(vip_list)
print_name(guest_list)
</code>```

Things become tricky, no? It's hard to decide now.

What's your opinion about this?

答:
I have come to believe something about refactoring that I haven't seen mentioned here, I know there are a lot of answers here already, but I think this is new.

I've been a ruthless refactorer and a strong believer in DRY since before the terms arose. Mostly it's because I have trouble keeping a large codebase in my head and partly because I enjoy DRY coding and I do not enjoy anything about C&P coding, in fact it's painful and terribly slow for me.

The thing is, insisting on DRY has given me a lot of practice in some techniques that I rarely see others use.  A lot of people insist that Java is difficult or impossible to make DRY, but really they just don't try.

One example from a long time ago that's somewhat similar to your example.  People tend to think java GUI creation is hard.  Of course it is if you code like this:

```<code>Menu m=new Menu("File");
MenuItem save=new MenuItem("Save")
save.addAction(saveAction); // I forget the syntax, but you get the idea
m.add(save);
MenuItem load=new MenuItem("Load")
load.addAction(loadAction)
</code>```

Anyone who thinks this is just crazy is absolutely right, but it's not Java's fault--code should never be written this way.  These method calls are functions intended to be wrapped in other systems.  If you can't find such a system, build it!

You obviously can't code like that so you need to step back and look at the problem, what is that repeated code actually doing?  It's specifying some strings and their relationship(a tree) and joining the leaves of that tree to actions.
So what you really want is to say:

```<code>class Menu {
    @MenuItem("File|Load")
    public void fileLoad(){...}
    @MenuItem("File|Save")
    public void fileSave(){...}
    @MenuItem("Edit|Copy")
    public void editCopy(){...}...
</code>```

Once you've defined your relationship in some way that is succinct and descriptive then you write a method to deal with it--in this case you iterate over the methods of the class passed in and build a tree then use that to build your Menus and Actions as well as (obviously) display a menu. You'll have no duplication, and your method is reusable... and probably easier to write than a large number of menus would have been, and if you actually enjoy programming, you had a LOT more fun.  This isn't hard--the method you need to write is probably less lines than creating your menu by hand would be!

Thing is, in order to do this well you need to practice, a lot.  You need to get good at analyzing exactly what unique information is in the repeated parts, extract that information and figure out how to express it well.  Learning to use tools like string parsing and annotations helps a lot.  Learning to be really clear about error reporting and documentation is very important as well.

You get "Free" practice simply by coding well--heck chances are that once you get good at it you'll find that coding something DRY (including writing a reusable tool) is faster than copying and pasting and all the errors, duplicated errors and difficult changes that type of coding causes.

I don't think I'd be able to enjoy my job if I didn't practice DRY techniques and building tools as much as I could.  If I had to take a cut in pay not to have to do copy and paste programming, I'd take it.

So my points are:

Copy & Paste costs more time unless you don't know how to refactor well.

You learn to refactor well by doing it--by insisting on DRY even in the most difficult and trivial of cases.

You are a programmer, if you need a small tool to make your code DRY, build it.

ContentLicense: CC BY-SA 3.0

Body:
I have come to believe something about refactoring that I haven't seen mentioned here, I know there are a lot of answers here already, but I think this is new.

I've been a ruthless refactorer and a strong believer in DRY since before the terms arose. Mostly it's because I have trouble keeping a large codebase in my head and partly because I enjoy DRY coding and I do not enjoy anything about C&P coding, in fact it's painful and terribly slow for me.

The thing is, insisting on DRY has given me a lot of practice in some techniques that I rarely see others use.  A lot of people insist that Java is difficult or impossible to make DRY, but really they just don't try.

One example from a long time ago that's somewhat similar to your example.  People tend to think java GUI creation is hard.  Of course it is if you code like this:

Menu m=new Menu("File");
MenuItem save=new MenuItem("Save")
save.addAction(saveAction); // I forget the syntax, but you get the idea
m.add(save);
MenuItem load=new MenuItem("Load")
load.addAction(loadAction)

Anyone who thinks this is just crazy is absolutely right, but it's not Java's fault--code should never be written this way.  These method calls are functions intended to be wrapped in other systems.  If you can't find such a system, build it!

You obviously can't code like that so you need to step back and look at the problem, what is that repeated code actually doing?  It's specifying some strings and their relationship(a tree) and joining the leaves of that tree to actions.
So what you really want is to say:

class Menu {
    @MenuItem("File|Load")
    public void fileLoad(){...}
    @MenuItem("File|Save")
    public void fileSave(){...}
    @MenuItem("Edit|Copy")
    public void editCopy(){...}...

Once you've defined your relationship in some way that is succinct and descriptive then you write a method to deal with it--in this case you iterate over the methods of the class passed in and build a tree then use that to build your Menus and Actions as well as (obviously) display a menu. You'll have no duplication, and your method is reusable... and probably easier to write than a large number of menus would have been, and if you actually enjoy programming, you had a LOT more fun.  This isn't hard--the method you need to write is probably less lines than creating your menu by hand would be!

Thing is, in order to do this well you need to practice, a lot.  You need to get good at analyzing exactly what unique information is in the repeated parts, extract that information and figure out how to express it well.  Learning to use tools like string parsing and annotations helps a lot.  Learning to be really clear about error reporting and documentation is very important as well.

You get "Free" practice simply by coding well--heck chances are that once you get good at it you'll find that coding something DRY (including writing a reusable tool) is faster than copying and pasting and all the errors, duplicated errors and difficult changes that type of coding causes.

I don't think I'd be able to enjoy my job if I didn't practice DRY techniques and building tools as much as I could.  If I had to take a cut in pay not to have to do copy and paste programming, I'd take it.

So my points are:

Copy & Paste costs more time unless you don't know how to refactor well.

You learn to refactor well by doing it--by insisting on DRY even in the most difficult and trivial of cases.

You are a programmer, if you need a small tool to make your code DRY, build it.


问:
Testing - Test for Specific Paths?
When (unit) testing, is is bad to expect the code to use certain paths.

For example, should I be testing for specifically "/build/static/public/css/", or just that server.cssPath has been set to a string and is a valid path?

I'm testing a web server.

答:
Is the path statically or dynamically generated?

If it is dynamic, then you can maybe test for a specific path because there is importance in testing the calculation of the path. I like to reference the same string constants the app uses when possible - that's one way to help.

But if it's static, well - what are you really getting by testing? I think then you care more about the "qualities" of the path, not the value - is it assigned, does the path exist, etc.

About the only exception I've seen to this is if a path is really, really important and that changing it in one place will unexpectedly break something else (bad!) - then it's a warning to others.

Title: Testing - Test for Specific Paths?


问:
If I replace N objects with N pointers, is my space complexity still O(N)?
Lets say I get N objects as input, and I need to rearrange them into a different data structure. This means the space complexity of my algorithm will be O(N). But what if I replace the objects with pointers to objects? I'll still have N pointers, but will it still be O(N) space complexity despite the fact that there is clearly going to be less memory taken?

答:
Let's get philosophical for a minute.

Has the number of objects changed from N? No? Then it is still O(N) because you started with the premise that N was the number of input objects and that was what was chosen to measure against.

Now you could start with a different premise for a given data structure, say in a case where the individual data structures is actually a complex unit itself. Sometimes that might make sense.

Now for examples.

With regards to your original question, suppose you have a list of integers to sort. If you state that your space complexity is O(N), it doesn't matter whether you choose a 16 bit integer or a 64 bit integer or a 32 bit pointer to an 8 bit integer from a "big-Oh" perspective - it's still O(N) because you're measuring the number of items to sort.

But now suppose you wish to upgrade to support any length of integer rather than bounding the problem. Now, technically your space complexity is still O(N). But if you start dealing with large numbers, variation in number size eventually has to lead to variation in underlying data structure size. This means that measuring with respect to N may no longer make sense, and you as an intelligent programmer decide to pick something different to measure and analyze. Maybe now you want to start to think of space complexity with respect to digits instead!


问:
Does it make sense to say if an OS is Turing complete
The book "Modern Operating systems",
says

The Operating System is an Extended Machine.

So I wonder if an OS is a model of computaion, and whether it makes sense to say if an OS is Turing complete? Thanks.

答:
Probably not.

Operating systems expose an API that provides services.  Despite the apparent complexity, the vast majority of service calls in a OS API are just that: service calls, and nothing more.  Operating systems do not typically provide looping services, or any of the other mechanics of a Turing-Complete machine; programming languages provide such mechanisms (i.e. the programming languages that call the OS API).

If an OS call does provide a looping service (e.g. traversing all the files in a folder) or some other operation that characterizes a Turing-complete mechanism, it does so at the behest of code written by some programmer in a Turing-complete programming language.


问:
Should I try it straight or should I first check if it can be done?
I have a set of items, and each item in the set must be unique. Item are composed from multiple properties and each property of each item can be changed. But after each change every item in the set must still be unique.

Should I simply try to change the property:

```<code>int err = setOfItems.SetPropertyOfItem( item, property, newValue )
if ( err != 0 ) {
    MessageBox( "You cannot change property to this value" );
    return;
}
// ( ...or similar exception based code )
</code>```

Or should I first check if the property can be changed and only then change it:

```<code>if ( !setOfItems.CanBePropertyChanged( item, property, newValue ) ) {
    MessageBox( "You cannot change property to this value" );
    return;
}
setOfItems.SetPropertyOfItem( item, property, newValue );
</code>```

Which approach is better and why?

答:
As long as the SetPropertyOfItem method reliably doesn't change the property when it detects a conflict, I would always choose the first way of doing things. Separating checks from actions can work, but it's prone to misuse by callers who perform the action without performing the check. And folding the check into the action method can lead to wasted effort if you also have a separate check method that a confused caller might call without need.

One problem with returning error codes is that the caller might forget to check it, and falsely assume that a change has occurred when it hasn't. If this is likely to be a problem, raising exceptions instead of error codes is an option.

(There are also people who advocate that you should never return anything from a method with side effects. I consider that short-sighted extremism, like claiming that the 100% pure functional style is the right choice for everything. I think design decisions always have to be made considering the pressures and context in the current situation.)


答:
I would generally say "no" with a caveat.

The main difficulty is that the phrase "operating system" is very broad -- an "OS" could be a standalone microkernel without any attached services, or an OS could be a multi-user graphical environment with a hundred subsystems, or anywhere in between.

When you decompose a modern operating system, you may find that it includes components or services which are Turing complete. For example, the "Debian" OS includes "bash" as a central part of the system -- without bash (or some workalike), you wouldn't recognize it as the same operating system. Bash, of course, provides a Turing complete programming language.

You might say that Debian is indirectly Turing-complete - because it has a Turing-complete component. But that's misattribution. If you wanted to have a discussion about the computational soundness of Unix-style UX, you would talk to the authors of bash -- not the authors of Debian.

Title: Does it make sense to say if an OS is Turing complete

Body:
The book "Modern Operating systems",
says

The Operating System is an Extended Machine.

So I wonder if an OS is a model of computaion, and whether it makes sense to say if an OS is Turing complete? Thanks.


问:
Options for constructing an object that is not logically initialized until all fields are set
I am working on a Pokemon game at the moment, and am running into some design concerns. The easiest example is as follows:

Each Species of Pokemon has several traits that are required before it is logically initialized. These include, but are not limited to:

id: an English representation of the name (usually just the name lowercase). Example: charizard

name: the localized name of the Species. Example: Charizard in English, Rizardon in Japanese, and Dracaufeu in French.

primaryType: the primary element of this Species. Example: Charizard's primary type is Fire because it is a fire-breathing dragon.

secondaryType: (optional) each Species may also have a secondary type. Example: Charizard's secondary type is Flying, but it's pre-evolution does not have wings, so it does not have a secondaryType. null is okay here.

baseStats: the base combat abilities of all members of a Species

evPointYield: the type of experience gained after defeating a member of a Species

For brevity, I'll stop there. There are at least 4 other fields that are required, but are not important for the example.

In this example, because all fields are required before a Species is constructed (read: no Species can possibly exist without all of these fields), a constructor would look something like

```<code>public Species(final String id, final String name, final Type primaryType,
    final Type secondaryType, final StatSet baseStats, final StatSet evPointYield) {
    // argument checking omitted for brevity
    this.id = id;
    this.name = name;
    this.primaryType = primaryType;
    this.secondaryType = secondaryType;
    this.baseStats = baseStats;
    this.evPointYield = evPointYield;
}
</code>```

There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor.

My first attempt at a solution was to make a Builder

```<code>public class Species {
    public static final class Builder {

        // setters for all 6 fields

        public Pokemon build() {
            return new Pokemon(this);
        }
    }

    public Species(final Species.Builder builder) {
        // ensure builder is not null
        // set fields from builder
    }
}
</code>```

But this would all users to build, while not calling any methods like so

```<code>Species species = new Species.Builder().build();
</code>```

So, I modified the build method to include a validation method

```<code>public Species build() {
    if (!stateIsValid()) {
        // actual message is more descriptive, including which specific fields
        // were missed
        throw new IllegalStateException("not all fields were initialized before building");
    }
    return new Species(this);
}

private boolean stateIsValid() {
    return
        idIsValid() &&
        nameIsValid() &&
        primaryTypeIsValid() &&
        secondaryTypeIsValid() &&
        baseStatsAreValid() &&
        evPointYieldIsValid();
}

private boolean idIsValid() {
    // return it was set to a valid value
}

// other state checkers
</code>```

I should also note that I am using Species as more of a data type. Meaning, that the fields will be loaded from somewhere, and there are very few logical operations that would be necessary in this class. This class (sh/w)ouldn't be used for specific Species like:

```<code>public class Charizard extends Species {

}
</code>```

but rather for adding additional functionality to all Species

```<code>public class ComparableSpecies extends Species implements Comparable {
    // ...
}
</code>```

This happens other times in the code, where an object isn't logically constructed until all fields are set. If I recall correctly, a constructor should contain all information necessary to logically complete construction of an object, but what happens if that involves a lot of data (like in this example)?

So to the question: Would a Builder be the right approach for this problem? Is there another pattern that would be better suited for this type of construction? Or have I just gone down the Builder rabbit hole so far that I can't see what's right in my face?

(Note: Don't worry/focus about/on how changes to the classes will impact any downstream consumers of my API. There are no consumers yet, as all of the code is still private, and not even ready for alpha testing yet)

Any feedback would be appreciated.

答:
There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor.

I think this is the essence in your problem.

First, the Builder pattern is normally used in this situation as best practice. However, for me personally, I don't like it and even consider it an anti pattern. You in some way too, else you would not ask here, right? ;)

So, I feel like some of the properties can still be grouped. However, a good logical grouping is one of the harder design decisions. So let's start from your given information (I removed the final for easier reading):

```<code>String id,
String name,
Type  primaryType,
Type secondaryType,
StatSet baseStats,
StatSet evPointYield
</code>```

Here it immediatly catches my eye is the type-pairs. While id and name looks like they could be grouped, they serve different purposes (identifying vs. displaying). So no grouping here, you are right.

The Types and StatSets however serve the same purpose - they and only they influence how the species behaves in game interactions. I would therefore group all these into a general Behaviour object. Its properties can be further grouped. The Types could be grouped into a TypeStats object. The StatSets seem to be only used in combat, so that would be the combatStats. Names are not best chosen here, I admit.

This has some advantages. You can now share common behaviour between different species if you want. You can make sure that when creating TypeStats that there are none where both first and second type are the same. This should be a concern of the TypeStats not of the Species in my opinion. It is also easier to explain the class:

Species contain an Id by which they are identified unique. When playing, they are displayed to the user by their names, depending on the country. Each Species also has their own behaviour in this game. This behaviour consists of how it behaves in combats and what you can do with it when not in combat.

However, my answer may be incomplete or even partly incorrect, depending on the meaning of the properties you mentioned and those that you didnt mention.

One last point: don't make your second type null. This is really not good. If you use Java 8, go for the Optional class. If you use Java below 7, take a look at googles guava library which provides such a class for you.

Body:
There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor.

I think this is the essence in your problem.

First, the Builder pattern is normally used in this situation as best practice. However, for me personally, I don't like it and even consider it an anti pattern. You in some way too, else you would not ask here, right? ;)

So, I feel like some of the properties can still be grouped. However, a good logical grouping is one of the harder design decisions. So let's start from your given information (I removed the final for easier reading):

String id,
String name,
Type  primaryType,
Type secondaryType,
StatSet baseStats,
StatSet evPointYield

Here it immediatly catches my eye is the type-pairs. While id and name looks like they could be grouped, they serve different purposes (identifying vs. displaying). So no grouping here, you are right.

The Types and StatSets however serve the same purpose - they and only they influence how the species behaves in game interactions. I would therefore group all these into a general Behaviour object. Its properties can be further grouped. The Types could be grouped into a TypeStats object. The StatSets seem to be only used in combat, so that would be the combatStats. Names are not best chosen here, I admit.

This has some advantages. You can now share common behaviour between different species if you want. You can make sure that when creating TypeStats that there are none where both first and second type are the same. This should be a concern of the TypeStats not of the Species in my opinion. It is also easier to explain the class:

Species contain an Id by which they are identified unique. When playing, they are displayed to the user by their names, depending on the country. Each Species also has their own behaviour in this game. This behaviour consists of how it behaves in combats and what you can do with it when not in combat.

However, my answer may be incomplete or even partly incorrect, depending on the meaning of the properties you mentioned and those that you didnt mention.

One last point: don't make your second type null. This is really not good. If you use Java 8, go for the Optional class. If you use Java below 7, take a look at googles guava library which provides such a class for you.


问:
Is there a pattern for a more "natural" way of adding items to collections?
I think the most common way of adding something to a collection is to use some kind of Add method that a collection provides:

```<code>class Item {}
var items = new List<Item>();
items.Add(new Item());
</code>```

and there is actually nothing unusual about that.

I wonder however why don't we do it this way:

```<code>var item = new Item();
item.AddTo(items);
</code>```

it seems to be somehow more natural then the first method. This would have the andvantange that when the Item class has a property like Parent:

```<code>class Item
{
    public object Parent { get; private set; }
}
</code>```

you can make the setter private. In this case of course you cannot use an extension method.

But perhaps I'm wrong and I've just never seen this pattern before because it's so uncommon? Do you know whether there is any such pattern?

In C# an extension method would be useful for that

```<code>public static T AddTo(this T item, IList<T> list)
{
    list.Add(item);
    return item;
}
</code>```

How about other languages? I guess in most of them the Item class had to provide a let's call it ICollectionItem interface.

Update-1

I've been thinking about it a little bit more and this pattern would be really usefull for example if you don't want an item to be added to multiple collections.

test ICollectable interface:

```<code>interface ICollectable<T>
{
    // Gets a value indicating whether the item can be in multiple collections.
    bool CanBeInMultipleCollections { get; }

    // Gets a list of item's owners.
    List<ICollection<T>> Owners { get; }

    // Adds the item to a collection.
    ICollectable<T> AddTo(ICollection<T> collection);

    // Removes the item from a collection.
    ICollectable<T> RemoveFrom(ICollection<T> collection);

    // Checks if the item is in a collection.
    bool IsIn(ICollection<T> collection);
}
</code>```

and a sample implementation:

```<code>class NodeList : List<NodeList>, ICollectable<NodeList>
{
    #region ICollectable implementation.

    List<ICollection<NodeList>> owners = new List<ICollection<NodeList>>();

    public bool CanBeInMultipleCollections
    {
        get { return false; }
    }

    public ICollectable<NodeList> AddTo(ICollection<NodeList> collection)
    {
        if (IsIn(collection))
        {
            throw new InvalidOperationException("Item already added.");
        }

        if (!CanBeInMultipleCollections)
        {
            bool isInAnotherCollection = owners.Count > 0;
            if (isInAnotherCollection)
            {
                throw new InvalidOperationException("Item is already in another collection.");
            }
        }
        collection.Add(this);
        owners.Add(collection);
        return this;
    }

    public ICollectable<NodeList> RemoveFrom(ICollection<NodeList> collection)
    {
        owners.Remove(collection);
        collection.Remove(this);
        return this;
    }

    public List<ICollection<NodeList>> Owners
    {
        get { return owners; }
    }

    public bool IsIn(ICollection<NodeList> collection)
    {
        return collection.Contains(this);
    }

    #endregion
}
</code>```

usage:

```<code>var rootNodeList1 = new NodeList();
var rootNodeList2 = new NodeList();

var subNodeList4 = new NodeList().AddTo(rootNodeList1);

// Let's move it to the other root node:
subNodeList4.RemoveFrom(rootNodeList1).AddTo(rootNodeList2);

// Let's try to add it to the first root node again...
// and it will throw an exception because it can be in only one collection at the same time.
subNodeList4.AddTo(rootNodeList1);
</code>```

答:
No, item.AddTo(items) it is not more natural. I think you mix this up with the following:

```<code>t3chb0t.Add(item).To(items)
</code>```

You are right in that items.Add(item) is not very near to the natural english language. But you also don't hear item.AddTo(items) in natural english language, do you? Normally there is someone who supposed to add the item to the list. Be it when working at a supermarket or while cooking and adding ingredients.

In the case of programming languages, we made it so that a list does both: storing its items and being responsible for adding them to itself.

The problem with your approach is that an item has to be aware that a list exists. But an item could exist even if there were no lists at all, right? This shows that it should not be aware of lists. Lists should not occur in its code in any way at all.

Lists however don't exist without items (at least they would be useless). Therefore its fine if they know about their items - at least in a generic form.

Body:
No, item.AddTo(items) it is not more natural. I think you mix this up with the following:

t3chb0t.Add(item).To(items)

You are right in that items.Add(item) is not very near to the natural english language. But you also don't hear item.AddTo(items) in natural english language, do you? Normally there is someone who supposed to add the item to the list. Be it when working at a supermarket or while cooking and adding ingredients.

In the case of programming languages, we made it so that a list does both: storing its items and being responsible for adding them to itself.

The problem with your approach is that an item has to be aware that a list exists. But an item could exist even if there were no lists at all, right? This shows that it should not be aware of lists. Lists should not occur in its code in any way at all.

Lists however don't exist without items (at least they would be useless). Therefore its fine if they know about their items - at least in a generic form.


答:
With your extension method you still have to call Add() so its not adding anything useful to your code. Unless your addto method did some other processing there's no reason for it to exist. And writing code that has no functional purpose is bad for readability and maintainability.

If you leave it non generic the problems become even more apparent. You now have an item that needs to know about different kinds of collections it can be in. That violates the single responsibility principle. Not only is an item a holder for it's data, it also manipulates collections. Which is why we leave the responsibility for adding items to collections up to the piece of code that is consuming both of them.

Title: Is there a pattern for a more "natural" way of adding items to collections?

Body:
I think the most common way of adding something to a collection is to use some kind of Add method that a collection provides:

```<code>class Item {}
var items = new List<Item>();
items.Add(new Item());
</code>```

and there is actually nothing unusual about that.

I wonder however why don't we do it this way:

```<code>var item = new Item();
item.AddTo(items);
</code>```

it seems to be somehow more natural then the first method. This would have the andvantange that when the Item class has a property like Parent:

```<code>class Item
{
    public object Parent { get; private set; }
}
</code>```

you can make the setter private. In this case of course you cannot use an extension method.

But perhaps I'm wrong and I've just never seen this pattern before because it's so uncommon? Do you know whether there is any such pattern?

In C# an extension method would be useful for that

```<code>public static T AddTo(this T item, IList<T> list)
{
    list.Add(item);
    return item;
}
</code>```

How about other languages? I guess in most of them the Item class had to provide a let's call it ICollectionItem interface.

Update-1

I've been thinking about it a little bit more and this pattern would be really usefull for example if you don't want an item to be added to multiple collections.

test ICollectable interface:

```<code>interface ICollectable<T>
{
    // Gets a value indicating whether the item can be in multiple collections.
    bool CanBeInMultipleCollections { get; }

    // Gets a list of item's owners.
    List<ICollection<T>> Owners { get; }

    // Adds the item to a collection.
    ICollectable<T> AddTo(ICollection<T> collection);

    // Removes the item from a collection.
    ICollectable<T> RemoveFrom(ICollection<T> collection);

    // Checks if the item is in a collection.
    bool IsIn(ICollection<T> collection);
}
</code>```

and a sample implementation:

```<code>class NodeList : List<NodeList>, ICollectable<NodeList>
{
    #region ICollectable implementation.

    List<ICollection<NodeList>> owners = new List<ICollection<NodeList>>();

    public bool CanBeInMultipleCollections
    {
        get { return false; }
    }

    public ICollectable<NodeList> AddTo(ICollection<NodeList> collection)
    {
        if (IsIn(collection))
        {
            throw new InvalidOperationException("Item already added.");
        }

        if (!CanBeInMultipleCollections)
        {
            bool isInAnotherCollection = owners.Count > 0;
            if (isInAnotherCollection)
            {
                throw new InvalidOperationException("Item is already in another collection.");
            }
        }
        collection.Add(this);
        owners.Add(collection);
        return this;
    }

    public ICollectable<NodeList> RemoveFrom(ICollection<NodeList> collection)
    {
        owners.Remove(collection);
        collection.Remove(this);
        return this;
    }

    public List<ICollection<NodeList>> Owners
    {
        get { return owners; }
    }

    public bool IsIn(ICollection<NodeList> collection)
    {
        return collection.Contains(this);
    }

    #endregion
}
</code>```

usage:

```<code>var rootNodeList1 = new NodeList();
var rootNodeList2 = new NodeList();

var subNodeList4 = new NodeList().AddTo(rootNodeList1);

// Let's move it to the other root node:
subNodeList4.RemoveFrom(rootNodeList1).AddTo(rootNodeList2);

// Let's try to add it to the first root node again...
// and it will throw an exception because it can be in only one collection at the same time.
subNodeList4.AddTo(rootNodeList1);
</code>```


答:
item.AddTo(items) is not used because it is passive. C.f. "The item is added to the list" and "the room is painted by the decorator".

Passive constructions are fine, but, at least in English, we tend to prefer active constructions.

In OO programming, the pardigm gives prominence to actors, not those acted upon, so we have items.Add(item). The list is the thing doing something. It is the actor, so this is the more natural way.


答:
This depends on how the operating system is implemented, and on how you answer the question of what is part of the operating system and what isn't.

As other answers have already commented,  an operating system may provide a scripting language as part of its shell. Whether this can be said to make the system itself turing complete is a question of semantics: is the shell viewed as being the operating system. Many would answer "no" - a shell is just user interface, the operating system itself is lower level than that.

In most cases, an operating system is implemented as an abstraction layer on top of hardware. The hardware provides processing, and both user software and the OS are implemented using it. In this case, it's quite clear that the operating system itself is not turing complete - the underlying hardware provides that property.

But there a handful of cases that are different, primarily in academic research systems:

In some systems the hardware and operating system are inextricably linked in such a fashion that from an end-user perspective it does not really make sense to distinguish one from the other. An example would be CAP or the Flex machine.

In some systems the operating system provides a programming language that all user applications must be written in, or a virtual machine that they must use. Examples include the LISP Machine OS aka Genera and Microsoft's Singularity.

In either of these cases, the answer is probably yes.


问:
Using a bytearray rather than a string to store password in memory
Using a bytearray datatype to store a password (in memory) has an advantage over using a string datatype for a password in that a bytearray is mutable and can be overwritten with 0x00 values when the password is no longer needed for processing and until the password variable is garbage collected.  It's not clear to me, however, whether overwriting 0x00 values will achieve what is intended.  When a password is no longer needed, it should be wiped from memory, prior to GC.  Is this possible in python 3.4 using bytearray?</p>

答:
At least using CPython, overwriting a bytearray is the way forward. Like most systems, CPython does not clear memory prior to garbage collection, so a manual erase is required. It also does not make copies of data unless specifically requested.

Be wary of other Python implementations, however. They often differ in specifics of how memory is managed and may, for example, use either a copying or compacting garbage collector. In such a case, manually erasing the password may not be enough, as the garbage collector may have moved the object reference, leaving behind a copy of the array's contents at the old location.


问:
Using conditions again and again or just create different methods
I have a method,

```<code>function DoThis(bool isHuman)
{
  // Do something

  if(isHuman)
  {
    //call his dad
  }
  else
  {
    //its a animal - let animal resuce know
  }

  // add some blah blah code
  // some more blah blah code

  if(isHuman)
  {
    //call his mother
  }
  else
  {
    heheeee now heeeheee
  }

  // more code

}
</code>```

Should I keep Using conditions again and again or just create different methods.

答:
The obvious refactoring is to remove the duplication like this:

```<code>  if(isHuman)
  {
    //call his dad
    doCommonStuff()
    //call his mother
  }
  else
  {
    // do animal stuff
    doCommonStuff()
    // do more animal stuff
  }
</code>```

Don't be afraid to introduce well-named methods, even if they are only called once. It's the single best way of increasing readability.

Body:
The obvious refactoring is to remove the duplication like this:

  if(isHuman)
  {
    //call his dad
    doCommonStuff()
    //call his mother
  }
  else
  {
    // do animal stuff
    doCommonStuff()
    // do more animal stuff
  }

Don't be afraid to introduce well-named methods, even if they are only called once. It's the single best way of increasing readability.


答:
Well if it makes sense you can probably use the visitor pattern or some other trick with double dispatch.

Note, these methods require you send an object since they rely on function overloading. You can maybe use the isHuman to create dummy object just for the sake of the dispatching, but I guess that if you look at your code at a larger scale, you probably find an object that you want to send instead of the isHuman and can be used for the design pattern.

If you are not familiar with function overloading you maybe want to start learning about vtable.

Body:
I have a method,

```<code>function DoThis(bool isHuman)
{
  // Do something

  if(isHuman)
  {
    //call his dad
  }
  else
  {
    //its a animal - let animal resuce know
  }

  // add some blah blah code
  // some more blah blah code

  if(isHuman)
  {
    //call his mother
  }
  else
  {
    heheeee now heeeheee
  }

  // more code

}
</code>```

Should I keep Using conditions again and again or just create different methods.


问:
How to detect client character encoding?
I programmed a telnet server using C as programming language but I have a problem to send characters with emphases (é, è, à ...). The character encoding is different between the telnet clients (windows, linux, putty, ...).

What can I do to detect the character encoding of the clients which are connected to my server ?

答:
Guessing the encoding of a message based on its byte values is always imperfect, although it can be made to give relatively accurate results. There are libraries available to do this, e.g. IBM's ICU.

But the preferable option is always either to standardize client and server on one encoding and always use that, or to force the client to declare the encoding of messages explicitly. It requires only a little programming effort and solves the entire question once and for all.


答:
The Builder pattern is most useful when the product you are building consists of multiple discrete parts, where external information specifies which parts, or if the product has many optional properties.

In your case, you have a long list of required properties. Here the Builder pattern only gives you the appearance of a less complex constructor at the cost of not being able to detect at compile-time that a property was missed.

You are essentially trading code like this

```<code>type1 property1 = ...
type2 property2 = ...
type3 property3 = ...
.
.
.
typeN propertyN = ...
Species x = new Species(property1, property2, property3, ..., propertyN);
</code>```

for

```<code>Builder builder;
builder.setProperty1(...);
builder.setProperty3(...);
.
.
.
builder.setPropertyN(...);
Species x = builder.build();
</code>```

The Species construction looks deliciously simple, but how long will it take you to see why this code doesn't work?

I know there are guidelines that methods should not take more than 3 (or 4) arguments. However, there is a reason why all languages in practical use don't impose that as a hard limit: Sometimes you just need more arguments. If even the most aggressive grouping of arguments into parameter objects can't get you lower than 6 or 7 parameters, then you just need that many.

Title: Options for constructing an object that is not logically initialized until all fields are set

Body:
I am working on a Pokemon game at the moment, and am running into some design concerns. The easiest example is as follows:

Each Species of Pokemon has several traits that are required before it is logically initialized. These include, but are not limited to:

id: an English representation of the name (usually just the name lowercase). Example: charizard

name: the localized name of the Species. Example: Charizard in English, Rizardon in Japanese, and Dracaufeu in French.

primaryType: the primary element of this Species. Example: Charizard's primary type is Fire because it is a fire-breathing dragon.

secondaryType: (optional) each Species may also have a secondary type. Example: Charizard's secondary type is Flying, but it's pre-evolution does not have wings, so it does not have a secondaryType. null is okay here.

baseStats: the base combat abilities of all members of a Species

evPointYield: the type of experience gained after defeating a member of a Species

For brevity, I'll stop there. There are at least 4 other fields that are required, but are not important for the example.

In this example, because all fields are required before a Species is constructed (read: no Species can possibly exist without all of these fields), a constructor would look something like

```<code>public Species(final String id, final String name, final Type primaryType,
    final Type secondaryType, final StatSet baseStats, final StatSet evPointYield) {
    // argument checking omitted for brevity
    this.id = id;
    this.name = name;
    this.primaryType = primaryType;
    this.secondaryType = secondaryType;
    this.baseStats = baseStats;
    this.evPointYield = evPointYield;
}
</code>```

There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor.

My first attempt at a solution was to make a Builder

```<code>public class Species {
    public static final class Builder {

        // setters for all 6 fields

        public Pokemon build() {
            return new Pokemon(this);
        }
    }

    public Species(final Species.Builder builder) {
        // ensure builder is not null
        // set fields from builder
    }
}
</code>```

But this would all users to build, while not calling any methods like so

```<code>Species species = new Species.Builder().build();
</code>```

So, I modified the build method to include a validation method

```<code>public Species build() {
    if (!stateIsValid()) {
        // actual message is more descriptive, including which specific fields
        // were missed
        throw new IllegalStateException("not all fields were initialized before building");
    }
    return new Species(this);
}

private boolean stateIsValid() {
    return
        idIsValid() &&
        nameIsValid() &&
        primaryTypeIsValid() &&
        secondaryTypeIsValid() &&
        baseStatsAreValid() &&
        evPointYieldIsValid();
}

private boolean idIsValid() {
    // return it was set to a valid value
}

// other state checkers
</code>```

I should also note that I am using Species as more of a data type. Meaning, that the fields will be loaded from somewhere, and there are very few logical operations that would be necessary in this class. This class (sh/w)ouldn't be used for specific Species like:

```<code>public class Charizard extends Species {

}
</code>```

but rather for adding additional functionality to all Species

```<code>public class ComparableSpecies extends Species implements Comparable {
    // ...
}
</code>```

This happens other times in the code, where an object isn't logically constructed until all fields are set. If I recall correctly, a constructor should contain all information necessary to logically complete construction of an object, but what happens if that involves a lot of data (like in this example)?

So to the question: Would a Builder be the right approach for this problem? Is there another pattern that would be better suited for this type of construction? Or have I just gone down the Builder rabbit hole so far that I can't see what's right in my face?

(Note: Don't worry/focus about/on how changes to the classes will impact any downstream consumers of my API. There are no consumers yet, as all of the code is still private, and not even ready for alpha testing yet)

Any feedback would be appreciated.

Body:
The Builder pattern is most useful when the product you are building consists of multiple discrete parts, where external information specifies which parts, or if the product has many optional properties.

In your case, you have a long list of required properties. Here the Builder pattern only gives you the appearance of a less complex constructor at the cost of not being able to detect at compile-time that a property was missed.

You are essentially trading code like this

type1 property1 = ...
type2 property2 = ...
type3 property3 = ...
.
.
.
typeN propertyN = ...
Species x = new Species(property1, property2, property3, ..., propertyN);

for

Builder builder;
builder.setProperty1(...);
builder.setProperty3(...);
.
.
.
builder.setPropertyN(...);
Species x = builder.build();

The Species construction looks deliciously simple, but how long will it take you to see why this code doesn't work?

I know there are guidelines that methods should not take more than 3 (or 4) arguments. However, there is a reason why all languages in practical use don't impose that as a hard limit: Sometimes you just need more arguments. If even the most aggressive grouping of arguments into parameter objects can't get you lower than 6 or 7 parameters, then you just need that many.


答:
The Template Method Pattern applies to such situations.</p>

```<code>void DoThis() {
  FirstSpecificPart();
  common code
  SecondSpecificPart();
}

void Human.FirstSpecificPart() {
  call(dad)
}
void Animal.FirstSpecificPart() {
  call(animal shelter)
}
</code>```

Title: Using conditions again and again or just create different methods

Body:
The Template Method Pattern applies to such situations.

void DoThis() {
  FirstSpecificPart();
  common code
  SecondSpecificPart();
}

void Human.FirstSpecificPart() {
  call(dad)
}
void Animal.FirstSpecificPart() {
  call(animal shelter)
}


问:
Automatic Type Promotion in JAVA
I have started studying JAVA .
In there,

```<code>byte ch=50;
ch*=2;
</code>```

works fine.
But

```<code>byte ch=50;
ch=ch*2;
</code>```

does not.
error:possible loss of precision
  required:byte
  found:int

Why this do not happen in 1st case.

答:
The second case contains a general multiplication expression, which is of type int, and assignment of int to byte doesn't work because information loss could occur (there are many more ints than bytes).

But the first one contains only a *= operator, and that operator is well-defined for any input value, so no loss occurs. The trick is that byte is defined to "wrap around" when you exceed its range via arithmetic, so a technically correct (although not very useful) result can be computed.

In other words, loss still occurs, but since it's defined to occur in the language definition, the compiler doesn't complain. (There is a hint in the specification, that says the result of the binary operation is converted to the type of the left-hand variable, Java Specification 1.7) There is no such rule defined for assignment; assigning 12345 to a byte does not silently result in Byte.MAX_VALUE, instead it's simply a type error.

And why were things done that way? Because all obvious alternatives would have been worse! If integer arithmetic didn't wrap around, it would have to throw an exception (bad), or yield undefined results (very bad), or it would have to be disallowed unless the compiler could prove that overflow will not occur (basically impossible to guarantee). So we took silent wrapping as the least bad alternative.

But with assignment we can use the strong type system to catch all possible overflow situations and allow most reasonable uses, so that option was chosen.

Title: Automatic Type Promotion in JAVA


问:
.NET WCF: Persistent connection or Open/Close as needed?
I have a .NET WCF web service currently running in production right now. I would say 95% of the time it works flawlessly and as intended. However; there are times when I am throwing an exception that says.

```<code>CommunicationException:
An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
</code>```

I have been looking around online for the cause of this, and it seems like this is happening when an exception is being thrown on the Host Service side, and it is not being handled properly and being passed back to the client. In this case my service is the client and a third party is the Host. I cannot feasibly ask the third party to change their code to handle this better.

Here is the assumption on my part: Once this exception is thrown, it closes the channel between client and host. Because I am not properly disposing of this connection, I have to wait for it to time-out before I can bring it back. This seems to be about 30 seconds, which is slightly too long to expect the users to wait for. I think I have found a possible workaround.

In my currently implementation I am instantiating my client at the start of my program and making it a global resource that can be called anywhere as needed. I am wondering if is better to use an approach like

```<code>using(WCFServiceClient client = new WCFServiceClient ())
{
    //More codes here
}
</code>```

and use that at each place that my client needs to communicate to the host. Essentially only having the connection opened when I needed it, and disposing of it right afterward.

The downside here, I would assume, is that there is extra overhead that is going on behind the scenes to open this connection and close it every time. So to me it comes down to whether or not the throughput is high enough to where my process would be effected by waiting for this overhead at each request. Right now I think that there is only about 12 calls to the host a minute, but the catch is they come in groups of three and the three requests all happen in the same second, so this is where the overhead might be the deal breaker.

Does anyone know what the best practice is?

答:
So, I'm not sure if what I'm about to tell you is still correct but according to  Mark Seeman in his book "Dependency Injection in .NET" he states that:

Although the correct usage pattern concerning ADO.NET connections should be common knowledge, it's far less known that the same is true for WCF Clients. They should be closed as soon as we're finished with a particular set of operations on a service.

Based on that view point, I believe you should close your connection after each request.

That being said, you've commented that they are always in batches of 3. It could be a worth while exercise introducing a cache/queue into your system where you collect the requests then open your connection, process all entries in the cache/queue, and then close the connection.

This combination of both aspects could give you a solution to your issue, however you could still find that the error occurs if it is generated from the server side. In which case you still need to implement some error handling into it.


答:
It depends on domain and UI requirements. Should a site/programs warn a user about possible problems? If so, you need a method to check.

```<code>bool CanBeChanged(item, property, newValue);
</code>```

An usual setter must be an usual. It's void, i.e. it raises an exeption:

```<code>void Change(item, property, newValue);
</code>```

What if a user doesn't want an exception, he wants the return code:

```<code>bool TryChange(item, property, newValue);
</code>```

The "Try" word tells to a user of class, that the method doesn't raise any exceptions.

Since a check for uniqueness can be a long operation, TryChange can lead to error in multithreading app. A user may be in doubt: is your method thread-safe?

```<code>bool TryChangeConcurrently(item, property, newValue);
</code>```

In general it's a bad practice to disclose details of the implementation in names of domain's classes and methods, so TryChange is still preferable. Consider, domain classes must be thread-safe as possible.

Of course, all of this are general considerations.

In C++ can_be_changed should be declared as const. Declaration of change in Java should contain throws clause, while canBeChanged and tryChange shouldn't. In C# any setter method has a form set[item, property] = value. Each language offers its own idioms and we can best follow them.

Summary: I would leave all three methods, and I'd try to make the class thread-safe.

Title: Should I try it straight or should I first check if it can be done?

Body:
I have a set of items, and each item in the set must be unique. Item are composed from multiple properties and each property of each item can be changed. But after each change every item in the set must still be unique.

Should I simply try to change the property:

```<code>int err = setOfItems.SetPropertyOfItem( item, property, newValue )
if ( err != 0 ) {
    MessageBox( "You cannot change property to this value" );
    return;
}
// ( ...or similar exception based code )
</code>```

Or should I first check if the property can be changed and only then change it:

```<code>if ( !setOfItems.CanBePropertyChanged( item, property, newValue ) ) {
    MessageBox( "You cannot change property to this value" );
    return;
}
setOfItems.SetPropertyOfItem( item, property, newValue );
</code>```

Which approach is better and why?

Body:
It depends on domain and UI requirements. Should a site/programs warn a user about possible problems? If so, you need a method to check.

bool CanBeChanged(item, property, newValue);

An usual setter must be an usual. It's void, i.e. it raises an exeption:

void Change(item, property, newValue);

What if a user doesn't want an exception, he wants the return code:

bool TryChange(item, property, newValue);

The "Try" word tells to a user of class, that the method doesn't raise any exceptions.

Since a check for uniqueness can be a long operation, TryChange can lead to error in multithreading app. A user may be in doubt: is your method thread-safe?

bool TryChangeConcurrently(item, property, newValue);

In general it's a bad practice to disclose details of the implementation in names of domain's classes and methods, so TryChange is still preferable. Consider, domain classes must be thread-safe as possible.

Of course, all of this are general considerations.

In C++ can_be_changed should be declared as const. Declaration of change in Java should contain throws clause, while canBeChanged and tryChange shouldn't. In C# any setter method has a form set[item, property] = value. Each language offers its own idioms and we can best follow them.

Summary: I would leave all three methods, and I'd try to make the class thread-safe.


答:
@valenterry is quite right about the problem of separation of concerns.  Classes should know nothing about the various collections which might contain them.   You would not want to have to change the item class each time you create a new kind of collection.

That said...

1. Not Java

Java is no help to you here, but some languages have more flexible, extensible syntax.

In Scala, items.add(item) looks like this:

```<code>  item :: items
</code>```

Where :: is an operator which adds items to lists.  That seems very much what you want.  It is actually syntactic sugar for

```<code>  items.::(item)
</code>```

where :: is a Scala list method which is effectively equivalent to Java's list.add.  So while it looks in the first version as if item is adding itself to items, in truth items is doing the adding.  Both versions are valid Scala

This trick is done in two steps:

In Scala, operators are really just methods.  If you import Java lists into Scala, then  items.add(item) can also be written items add item.  In Scala, 1 + 2 is actually 1.+(2).  In the version with spaces rather than dots and brackets, Scala sees the first object, looks for a method matching the next word and (if the method takes parameters) passes the next thing (or things) to that method.

In Scala, operators which end in a colon are right-associative rather than left.  So when Scala sees the method, it looks for the method owner on the right and feeds in the value on the left.

If you are not comfortable with lots of operators and want your addTo, Scala offers another option: implicit conversions.  This requires two steps

Create a wrapper class called, say, ListItem which takes an item in its constructor and has an addTo method which can add that item to a given list.

Create a function which takes an item as a parameter and returns a ListItem containing that item.  Mark it as implicit.

If implicit conversions are enabled and Scala sees

```<code>  item addTo items
</code>```

or

```<code>  item.addTo(items)
</code>```

and item does not have addTo, it will search the current scope for any implicit conversion functions.  If any of the conversion functions returns a type which does have an addTo method, this happens:

```<code>  ListItem.(item).addTo(items)
</code>```

Now, you may find the implicit conversions route more to your taste, but it adds danger, because code can do unexpected things if you are not clearly aware of all the implicit conversions in a given context.  This is why this feature is no longer enabled by default in Scala.  (However, while you can choose whether or not to enable it in your own code, you can do nothing about its status in other people's libraries.  Here be dragons).

The colon-terminated operators are uglier but do not pose a threat.

Both approaches preserve the principle of separation of concerns.  You can make it look as if item knows about collection, but the work is actually done somewhere else.  Any other language which wants to give you this feature should be at least as careful.

2.  Java

In Java, where the syntax is not extensible by you, the best you can do is create some kind of wrapper/decorator class which knows about lists.  In the domain where your items are placed in lists, you could wrap them in that.  When they leave that domain, take them out.  Maybe the visitor pattern is closest.

3. tl;dr

Scala, like some other languages, can help you with more natural syntax.  Java can only offer you ugly, baroque patterns.

Body:
@valenterry is quite right about the problem of separation of concerns.  Classes should know nothing about the various collections which might contain them.   You would not want to have to change the item class each time you create a new kind of collection.

That said...

1. Not Java

Java is no help to you here, but some languages have more flexible, extensible syntax.

In Scala, items.add(item) looks like this:

  item :: items

Where :: is an operator which adds items to lists.  That seems very much what you want.  It is actually syntactic sugar for

  items.::(item)

where :: is a Scala list method which is effectively equivalent to Java's list.add.  So while it looks in the first version as if item is adding itself to items, in truth items is doing the adding.  Both versions are valid Scala

This trick is done in two steps:

In Scala, operators are really just methods.  If you import Java lists into Scala, then  items.add(item) can also be written items add item.  In Scala, 1 + 2 is actually 1.+(2).  In the version with spaces rather than dots and brackets, Scala sees the first object, looks for a method matching the next word and (if the method takes parameters) passes the next thing (or things) to that method.

In Scala, operators which end in a colon are right-associative rather than left.  So when Scala sees the method, it looks for the method owner on the right and feeds in the value on the left.

If you are not comfortable with lots of operators and want your addTo, Scala offers another option: implicit conversions.  This requires two steps

Create a wrapper class called, say, ListItem which takes an item in its constructor and has an addTo method which can add that item to a given list.

Create a function which takes an item as a parameter and returns a ListItem containing that item.  Mark it as implicit.

If implicit conversions are enabled and Scala sees

  item addTo items

or

  item.addTo(items)

and item does not have addTo, it will search the current scope for any implicit conversion functions.  If any of the conversion functions returns a type which does have an addTo method, this happens:

  ListItem.(item).addTo(items)

Now, you may find the implicit conversions route more to your taste, but it adds danger, because code can do unexpected things if you are not clearly aware of all the implicit conversions in a given context.  This is why this feature is no longer enabled by default in Scala.  (However, while you can choose whether or not to enable it in your own code, you can do nothing about its status in other people's libraries.  Here be dragons).

The colon-terminated operators are uglier but do not pose a threat.

Both approaches preserve the principle of separation of concerns.  You can make it look as if item knows about collection, but the work is actually done somewhere else.  Any other language which wants to give you this feature should be at least as careful.

2.  Java

In Java, where the syntax is not extensible by you, the best you can do is create some kind of wrapper/decorator class which knows about lists.  In the domain where your items are placed in lists, you could wrap them in that.  When they leave that domain, take them out.  Maybe the visitor pattern is closest.

3. tl;dr

Scala, like some other languages, can help you with more natural syntax.  Java can only offer you ugly, baroque patterns.


问:
How to access large amounts of data for machine learning in a microservices architecture
Imagine you are building a product recommendation algorithm for an eccommerce application which is built as a microservices architecture, this architecture having separate services for users and products. The algorithm should be exposed as a recommendation service which, given a user id, returns a list of recommended products based on their buying history.

Here's the problem, assume that the reccomendation algorithm is offline so runs in batches and requires every user's buying history for each run, how do you get this data from the user service? In a monolithic architecture you would just read directly from a reporting copy of the database allowing large complex queries without impacting production performance.

The obvious answer to me seems to be that you just make a huge request to the users service on each run and make sure you have capacity to deal with that request, are there better solutions?

答:
Keep a copy of the users' purchasing history within your recommendations service.  Then, for each new batch run, it only has to request the updated users from the users service (a delta update, if you want to call it like that).

You will need a big update to ramp up the recommendations service, and possibly a big synchronization update from time to time, but you do not need to request the whole purchasing history each time.


答:
I think you should have a reason to create a procedure. There are a number of reasons to create a procedure. The ones that I think are most important are:

abstraction

modularity

code navigation

update consistency

recursion

testing

Abstraction

A procedure can be used to abstract a general algorithm from the details of particular steps in the algorithm. If I can find a suitably coherent abstraction, this helps me to structure the way I think about what the algorithm does. For example, I can design an algorithm that works on lists without having to necessarily consider the list representation.

Modularity

Procedures can be used to organise code into modules. The modules can often be treated separately. For example, built and tested separately.

Well designed module typically capture some coherent meaningful unit of functionality. Therfore they can often be owned by different teams, replaced completely with an alternative or reused in a different context.

Code Navigation

In large systems, finding the code associated with a particular system behaviour can be challenging. Hierarchical organisation of the code within libraries, modules and procedures can help with this challenge. Particularly if you try to a) organise functionality under meaningful and predictable names b) place the procedures relating to similar functionality near each other.

Update Consistency

In large systems it can be challenging to find all the code that needs to be changed to achieve a particular change in behavior. Using procedures to organise the functionality of the program can make this easier. In particular, if each bit of functionality of your program appears only once and in a cohesive group of procedures it is less likely (in my experience) that you will miss somewhere you should have updated or make an inconsistent update.

Note that you should organise procedures based on the functionaility and abstractions in the program. Not based on whether two bits of code happen to be the same at the moment.

Recursion

Using recursion requires that you create procedures

Testing

You can usually test procedures independently of each other. Testing different parts of the body of a procedure independently is more difficult, because you typically have to execute the first part of the procedure before the second part. This observation also often applies to other approaches to specifying/verifying programs behavior.

Conclusion

Many of these points relate to the comprehensibility of the program. You could say that procedures are a way to create a new language, specific to your domain, with which to organise, write, and read, about the problems and processes in your domain.

Title: Is it always a best practice to write a function for anything that needs to repeat twice?

Body:
Myself, I can't wait to write a function when I need to do something more than twice. But when it comes to things that only appear twice, it's a bit more tricky.

For code that needs more than two lines, I'll write a function. But when facing things like:

```<code>print "Hi, Tom"
print "Hi, Mary"
</code>```

I'm hesitant to write:

```<code>def greeting(name):
    print "Hi, " + name

greeting('Tom')
greeting('Mary')
</code>```

The second one seems too much, doesn't it?

But what if we have:

```<code>for name in vip_list:
    print name
for name in guest_list:
    print name
</code>```

And here is the alternative:

```<code>def print_name(name_list):
    for name in name_list:
        print name

print_name(vip_list)
print_name(guest_list)
</code>```

Things become tricky, no? It's hard to decide now.

What's your opinion about this?


答:
One option is to use a parameter object.

Take the parameters required by every instance and bundle them as a seperate class.

See also this question


答:
You are pretty much stuck which something hokey like sending:</p>

```<code>Which character looks like e with an acute accent:
1 -> è, 2 -> ò, 3 -> õ, 4 -> é, 5 -> none of these
enter choce 1-5:
</code>```

Title: How to detect client character encoding?

Body:
I programmed a telnet server using C as programming language but I have a problem to send characters with emphases (é, è, à ...). The character encoding is different between the telnet clients (windows, linux, putty, ...).

What can I do to detect the character encoding of the clients which are connected to my server ?

Body:
You are pretty much stuck which something hokey like sending:

Which character looks like e with an acute accent:
1 -> è, 2 -> ò, 3 -> õ, 4 -> é, 5 -> none of these
enter choce 1-5:


问:
Implement a virtual tag on the database level
I have a set of objects, for which users manually applied tags, whatever they invented. I'd like to implement a task engine, where each task might be applied to objects from a tag. For convenience, I'd like to have an additional virtual tag "All objects" to have a task be applied to all objects regardless of tags.

A single task might require two (or more) sets of objects, e.g. "notify me about changes in all documents from tag X that were published on website tagged Y".

I see three ways of implementing this requirement:

Have a separate user interface and business code paths for the "All" case. This could be feasible for simple cases, but in my case it leads to having four cases for the example above, and potentially even worse in other cases.

Have a user interface that treats the "All" case like a normal tag (except maybe for making it impossible to remove items from the tag), and have business code add the tag automatically every time I list tags in the app, or have special cases for the "All" tag every time I handle a tag.

Have a user interface and business code handle the "All" case like a normal tag, and implement the virtual "All" tag on the database level. That would mean using database views that would add the "All" tag to the table of tags, and another view that would add the "All" tag to the m2m relationship listing which objects have which tags.

The third solution looks the most sane to me, but I don't have that much experience with programming on the database level. I can see the pros and cons of the first two solutions. What are the issues I might encounter if I chose to implement the third solution?

答:
You can potentially mix 1 and 2 but create less work in the process.

I would initially build your query logic on the assumption that all requests would be of the form "show all documents published on all websites" and then extend it to support filtering by tags (adding parameters to queries is easier than taking them away). You'd achieve this by simply checking whether the user had selected a tag for that object and adding a "where" clause (or whatever equivalent for your chosen DBMS) if they have.

From a UI perspective the "All" tag would just be an visual indicator that no tag filters are being applied.


答:
I think you are obsessing with the word "add". Try looking for an alternative word instead, such as "collect", which would give you a more English-friendly syntax with no change in pattern:

```<code>items.collect(item);
</code>```

The above method is exactly the same as items.add(item);, with the only difference being different word choice, and flows very nicely and "naturally" in English.

Sometimes, merely re-naming variables, methods, classes, etc. will prevent the taxing re-designing of the pattern.

Body:
I think you are obsessing with the word "add". Try looking for an alternative word instead, such as "collect", which would give you a more English-friendly syntax with no change in pattern:

items.collect(item);

The above method is exactly the same as items.add(item);, with the only difference being different word choice, and flows very nicely and "naturally" in English.

Sometimes, merely re-naming variables, methods, classes, etc. will prevent the taxing re-designing of the pattern.


答:
In Java, a typical collection doesn't hold things--it holds references to things, or more accurately copies of references to things.  Dot-member syntax, by contrast, is generally used to act upon the thing identified by a reference, rather than upon the reference itself.

While placing an apple in a bowl would alter some aspects of the apple (e.g. its location), placing a slip of paper that says "object #29521" into a bowl wouldn't change the apple in any way even if it happens to be object #29521.  Further, because collections hold copies of references, there's no Java equivalent to placing a slip of paper saying "object #29521" into a bowl.  Instead, one copies the number #29521 to a new slip of paper, and show (not give) that to the bowl, which will them make its own copy, leaving the original unaffected.

Indeed, since object references (the "slips of paper") in Java can be passively observed, neither the references, nor the objects identified thereby, have any way of knowing what is being done with them.  There are some kinds of collections which, rather than merely holding a bunch of references to objects that may know nothing of the collection's existence, instead establish a bidirectional relationship with the objects encapsulated therein.  With some such collections, it may make sense to ask a method to add itself to a collection (especially if an object is only capable of being in one such collection at a time).  In general, though, most collections don't fit that pattern, and may accept references to objects without any involvement whatsoever on the part of the objects identified by those references.


问:
Saving to file before storing into a database in a REST service
A mobile back-end I am building should receive a larger amount of data (some sensor recordings) from an Android phone. The phone does not have much use of it so it was most efficient to store the data into plain files (SQLite can get quite slow with larger amounts). Now when we upload the data to a REST service backed with a distributed database, we have another issue. Storing to it takes some time, since it is really a lot. I thought of uploading the file to the web service as fast as possible, leave the phone alone, cache the file somewhere on the server and then some long-running workers will pick the data up and chunk it into databases. We have some other mechanisms to verify the data is properly stored and so on, but that is not important.

I would like to know is the REST->file->database approach valid? My concern is where to store the file? Disk, some in-memory database, a cache? Web servers fail (we can request a re-upload, but I would rather mitigate the risk earlier), or the server can get cluttered. I'm afraid the local storage on the web servers does not scale really well, if we have multiple workers and servers.

Thank you in advance.

答:
You may want to consider a Message Queuing service like Rabbit MQ, this would allow you to send data to a server that would simply keep hold of it until you had a consumer/worker available to process it. You would have to consider things like memory usage on the message queue server if your datasets are very large (or find a way to send the data in smaller chunks), but it does support things like message persistence (saving the data to disk before it is processed, meaning data isn't lost if the server dies) and clustering if your usage requires it.

If that's not possible though, your basic idea of REST Upload > Store on Disk > Process in to DB is perfectly valid, if you're worried about data loss you can apply standard redundancy processes to your storage (replication etc.) and you should ensure your Process in to DB stage deletes the uploaded files once they're not needed any more.


问:
Is there actually an advantage to using Win API calls for file access?
I remember coding file access using the Win API about 15 years ago. It was much faster than using the FileStream of my language at the time (Delphi).

I spent a while today experimenting in C# under .Net 4.5, and I cannot see a real advantage to using the Win API. Most of the time the standard FileStream is faster, even with its buffering behavior (I know that used to add a substantial overhead a decade ago).

I've studied this research article by Microsoft, but it's over 10 years old now and not very applicable.

So my question is this: when is it advantageous to use the Win API as opposed to the standard FileStream?

答:
When using .NET (particularly recent versions of .NET), a good guideline is to always use the built-in .NET functionality until and unless there is a marked benefit to doing otherwise. In other words: assume .NET is the right way to get the job done until you strongly suspect (or know) that it isn't. Nine times out of ten, the Framework (having been used so widely) will take into account checks and performance improvements that you won't consider.

It's really the same reason people say not to roll your own security solution if you can avoid it - because it's already been done by someone who is probably smarter than you and knows more about it, and other people have already tested it. The same applies to a widespread library like .NET. If someone has already done the work for you, and that work has been vetted by thousands or millions of users, why not go with that until you have a reason not to (such as it not providing the functionality or speeds you need).


问:
Creative Commons ShareAlike
Some of the CC licenses define ShareAlike term:

ShareAlike — If you remix, transform, or build upon the material, you
  must distribute your contributions under the same license as the
  original.

http://creativecommons.org/licenses/by-sa/3.0/deed.en

What does it mean to "build upon"? If image licensed under ShareAlike term becomes a part of some software, does it mean that software was built upon the image and it must become CC? Is it just a graphics on screen that is built upon image? Or is image considered a separate part on its own rights, with software being a medium mentioned by Share term:

Share — copy and redistribute the material in any medium or format

So that it can be used without affecting the software license.

答:
If you build something "from scratch," this doesn't apply.

But if you use "Application X" as your starting point, and tweak or "take off" on it, you are likely covered by the same license, even if your end product is rather different.

This is a fine point, to be covered by lawyers, but it could turn on something as simple as whether or not you downloaded Application X to your computer and worked off the copy, or whether you merely "saw" the image on Application X, were "inspired" by it, and developed something from scratch that had a few "coincidental" similarities.

Title: Creative Commons ShareAlike


答:
Using Win API, you can support long paths in your application:

[PathTooLongException]: The specified path, file name, or both are too
long. The fully qualified file name must be less than 260 characters,
and the directory name must be less than 248 characters.

For more information about using long paths in .NET applications, see this blog series:

Link

Title: Is there actually an advantage to using Win API calls for file access?

Body:
I remember coding file access using the Win API about 15 years ago. It was much faster than using the FileStream of my language at the time (Delphi).

I spent a while today experimenting in C# under .Net 4.5, and I cannot see a real advantage to using the Win API. Most of the time the standard FileStream is faster, even with its buffering behavior (I know that used to add a substantial overhead a decade ago).

I've studied this research article by Microsoft, but it's over 10 years old now and not very applicable.

So my question is this: when is it advantageous to use the Win API as opposed to the standard FileStream?

ContentLicense: CC BY-SA 4.0


问:
Open source code with no license... can I fork it?
Years ago somebody created a bunch of really awesome and popular scripts. But they were not updated for a long, now they no-longer work (target platform were updated, and some changes are needed).

He hasn't released it under any license.  I want to fix the bug (currently, many of the target users can't use it), and post it on GitHub, preferably under a public-domain style OSS license. I wonder what the legal ramifications might be?

I have sent an email to the author, but (let's say) he didn't reply to my email.

What we should do in the following this into 2 cases:

If the script is posted on a private website (without any source control).

If the script is posted on GitHub (without any licensing hints).

However, one can clearly see, that it seems open source - intended to be used/modified/whatever.

答:
Note: for any non-open-source code on github, you can still fork it - at least on github.  This is useful because many of us will see the title "code with no license ... can I fork it?" and come here wondering about github. (I did not reproduce the words "open source" in the question text for the reasons mentioned in other answers.)

This minimal license is a result of the github terms of service and clarified in the Open Source FAQ:

What happens if I don't choose a license?

You're under no obligation to choose a license. It's your right not to include one with your code or project, but please be aware of the implications. Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. This might not be what you intend.

Even if this is what you intend, if you publish your source code in a public repository on GitHub, you have accepted the Terms of Service which do allow other GitHub users some rights. Specifically, you allow others to view and fork your repository.

If you want to share your work with others, we strongly encourage you to include an open source license.

Here is the exact language from the Terms of Service:

... By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
  ...

By the logic on patching, I believe this means you may even be able to upload 'patches' to your github fork, but I am not a lawyer and you should consult one if you have anything worth suing for...

To be very clear, this answer ONLY applies to github - and the terms may change over time - although other collaborative sites may have limited or permissive licenses if you search for them...


问:
Which are the significant algorithms for humankind in past decades?
Which world most important algorithms have contributed most to humankind in past decades?

I thought this is a good general knowledge for a developer to know about.

Update:

If possible, please keep the answer to a specific programming algorithm.

I would like to get a list of the most important ones, only one algorithm per answer.

Please consider to state why the algorithm is significant and important...

答:
TimSort

This is the sorting algorithm now used in Python, Java 7 and Android

Basically:

O(N log N) worst case (does not degenerate)

O(N) for almost sorted list (in fact N-1 exactly on already sorted list)

And the beauty of it ? It's stable! And therefore suitable for multipass sorting according to various criterion.

By the way, if anyone has an optimized C++ implementation on hand...

ContentLicense: CC BY-SA 2.5


答:
Operating Systems Are Languages. And Operating Systems Are Machines. So, yes, it does in fact make sense to talk about all the same things that we talk about for Languages and Machines: Computational Power, Expressivity, Orthogonality, Compositionality, Modularity, etc.

The fact that Operating Systems Are Languages seems to be so obvious that there isn't even any discussion about it that one could link to. The dual (Languages Are Operating Systems) seems to be discussed more vividly, and there is a quote on that page saying:

The converse, that operating systems are languages is widely known. Where does an OS designer get inspiration from if not from various languages? This is especially true in the case of functional languages. (Damn those bastards, always twenty years ahead of the rest of us.)

(Emphasis mine.)

Body:
The book "Modern Operating systems",
says

The Operating System is an Extended Machine.

So I wonder if an OS is a model of computaion, and whether it makes sense to say if an OS is Turing complete? Thanks.


答:
In times like this I try to step back, forget the implementation, and focus on the requirements.

Essentially, you want to:

- Define discrete entities using primitive data elements

- Validate entities using domain-specific rules

- Construct a domain model from valid entities

- Perform useful and interesting computations with your domain model

If you're in pre-alpha, the Builder pattern will work just fine to get you started. You could probably skip Builder altogether and just use an interface to hide your setters. Either way, get your most valuable features finished before worrying about low-level implementation details. Your features will drive the requirements of your domain model.

When you have your domain model requirements figured out, you'll be in a better position to decide if Builder is an acceptable (not necessarily the best) solution. You may find that fields you thought were required aren't really required at all. For example, does a Pokemon need to own its EV point yield? Could you instead map a Pokemon to its EV point yield in a separate model? With less required fields, Builder may look like a better solution. Useful concepts here include the Law of Demeter and the interface segregation principle.

If the Builder pattern still doesn't meet your requirements, try looking at data binding with the Java Architecture for XML Binding (JAXB). It's a standard that defines how to create an entity using data stored as XML, and includes validation as well. Oracle has a basic tutorial to get you started.

If your XML looks like this:

```<code><pokemon>
    <id>Charizard</id>
    <!-- Other elements -->
</pokemon>
</code>```

Your Pokemon might look like this:

```<code>@XmlRootElement(name="pokemon")
public class Pokemon {

    @XmlElement(required=true)
    private String id;
}
</code>```

Normally I try to avoid XML, and JAXB is definitely overkill for small projects. But for large, human-readable data sets with well-defined validation rules that integrate with Java, it works pretty well.

Body:
In times like this I try to step back, forget the implementation, and focus on the requirements.

Essentially, you want to:

- Define discrete entities using primitive data elements

- Validate entities using domain-specific rules

- Construct a domain model from valid entities

- Perform useful and interesting computations with your domain model

If you're in pre-alpha, the Builder pattern will work just fine to get you started. You could probably skip Builder altogether and just use an interface to hide your setters. Either way, get your most valuable features finished before worrying about low-level implementation details. Your features will drive the requirements of your domain model.

When you have your domain model requirements figured out, you'll be in a better position to decide if Builder is an acceptable (not necessarily the best) solution. You may find that fields you thought were required aren't really required at all. For example, does a Pokemon need to own its EV point yield? Could you instead map a Pokemon to its EV point yield in a separate model? With less required fields, Builder may look like a better solution. Useful concepts here include the Law of Demeter and the interface segregation principle.

If the Builder pattern still doesn't meet your requirements, try looking at data binding with the Java Architecture for XML Binding (JAXB). It's a standard that defines how to create an entity using data stored as XML, and includes validation as well. Oracle has a basic tutorial to get you started.

If your XML looks like this:

<pokemon>
    <id>Charizard</id>
    <!-- Other elements -->
</pokemon>

Your Pokemon might look like this:

@XmlRootElement(name="pokemon")
public class Pokemon {

    @XmlElement(required=true)
    private String id;
}

Normally I try to avoid XML, and JAXB is definitely overkill for small projects. But for large, human-readable data sets with well-defined validation rules that integrate with Java, it works pretty well.


问:
Scheduling a Jenkins job to only run integration test
My current company has a Jenkins/DotCi setup. Our current process for CI is when dev pushes to github, jenkins runs unit tests on all branches and reports back to us via email if the unit tests failed.

If on master, we then run a deploy to a UAT environment and we will soon be activating our integration tests after a deploy occurs successfully.

We want to run our integration tests against our Staging environment on a daily basis.

With the "Build Periodically" feature under Config i know we can specify when we trigger it to occur, however is there a way to have it trigger the integration test only rather than having to deploy?

答:
Yes. You can put the deployment and the integration tests into two different Jenkins projects.

Then you can configure the project with the integration tests to be built (executed) when the deployment build succeeds and also on a regular schedule.


问:
How do you prioritize initial sprints to maximise the chance of catching architecture errors early?
I've worked on several projects that have used agile successfully as a means of providing continuous improvement on an already mature piece of software. But I've found it's much harder to be "agile" when pre-planning something. An element of waterfall is necessary to produce initial functional specifications and a sensible architecture, as per this question: How do you explain to an "agile" team that they still need to plan the software they write?

However, you still want to be as fast, as light and most of all as flexible as possible. One of the big dangers in traditional software design is misunderstandings, resulting in major architectural changes that are only caught late in the process.

I have recently joined a project which had woefully insufficient planning and is in the most horrendous mess. While salvaging what I can, I'm left wondering what previous developers could have done (besides some planning) to catch the huge architectural problems in the system at an early stage.

If we presume a moderate amount of pre-project planning, how can I best allocate work in initial sprints to catch the (probably inevitable) architectural issues in the solution as early as possible?

EDIT: After reading the answers, and some suggested articles, I feel I made need a bit of clarity in the question. I understand that Agile requires some upfront design, but that it ought to be kept to a minimum, and it needs to be done with an eye to flexibility.

What I'm trying to discover are whether there are any tricks, tips or techniques to ensure that we correctly identify the parts of the project that need the most rigidity, prototype and iterate them first, and catch problems there as early as possible?

答:
The first mistake that often gets made is that people don´t look beyond the stories in the current sprint.

While it is correct that those stories are not in scope now and might change or be removed at a moments notice, completely ignoring them when making high-level design decisions is a nice route to chaos.

When making high-level design decisions, you must also look to the stories that are still on the product backlog to see how your decision affects those stories and to revise your decision if it turns out that it makes those future stories hard to implement.

Stories higher on the backlog should have a higher priority in this evaluation, as they are more likely to be implemented.


问:
Is there any material difference between queries joined by WHERE clauses, and queries using an actual JOIN?
In Learn SQL the Hard Way (exercise six), the author presents the following query:

```<code>SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";
</code>```

and then goes on to say that:

There are actually other ways to get these kinds of queries to work called "joins". I'm avoiding those concepts for now because they are insanely confusing. Just stick to this way of joining tables for now and ignore people who try to tell [you] that this is somehow slower or "low class".

Is that true? Why or why not?

答: Whether it's slower depends on the Query Optimizer and how it streamlines the query (what you write isn't actually what is executed). However, the big problem with this quote is that it completely ignores the fact that there are different types of joins which operate completely differently. For instance, what is being said is (theoretically) true for inner joins, but it doesn't hold true for outer joins (left joins and right joins).


答:
The example is equivalent to the simple reformulation with inner JOINs. The difference lies solely in the additional possibilities that the JOIN syntax allows. For instance, you can specify the order in which the columns of the two tables involved are processed; see e.g. https://stackoverflow.com/a/1018825/259310.

The received wisdom is, when in doubt, to write your queries in the way that makes them more readable. But whether JOIN or WHERE formulations are easier to read appears to be a matter of personal preference, which is why both forms are so widespread.

Title: Is there any material difference between queries joined by WHERE clauses, and queries using an actual JOIN?

Body:
In Learn SQL the Hard Way (exercise six), the author presents the following query:

```<code>SELECT pet.id, pet.name, pet.age, pet.dead
    FROM pet, person_pet, person
    WHERE
    pet.id = person_pet.pet_id AND
    person_pet.person_id = person.id AND
    person.first_name = "Zed";
</code>```

and then goes on to say that:

There are actually other ways to get these kinds of queries to work called "joins". I'm avoiding those concepts for now because they are insanely confusing. Just stick to this way of joining tables for now and ignore people who try to tell [you] that this is somehow slower or "low class".

Is that true? Why or why not?


答:
Guy is making a classic error. He's trying to teach an abstract concept with a specific implementation. As soon as you do that you get into this sort of mess.

Should have taught basic database concepts first, then shown SQL as one way of describing them.

Left and right joins, could be argued they don't matter too much. Outer Join, well you could use the old *= and =* syntax.

Now you could argue that syntax is simpler, but only for simple queries. As soon as you start trying to do a complex query with this version, you can get in a horrible mess. The "new" syntax wasn't introduced so you could do complex queries, it was so you do complex queries in a readable and therefore maintainable way.