问:
Programming to Data Oriented Interfaces
There is a portion of our codebase written in the following style:

```<code>// IScheduledTask.cs
public interface IScheduledTask
{
    string TaskName { get; set; }
    int TaskPriority { get; set; }
    List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein
}

// ScheduledTaskImpl.cs
public class ScheduledTaskImpl : IScheduledTask
{
    public string TaskName { get; set; }
    public int TaskPriority { get; set; }
    public List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein,
    // perhaps a constructor or two for convenience.
}
</code>```

That is, there are a large number of interfaces specifying just a set of properties with no behavior each with a sole corresponding implementation that implements these with auto-properties. The code is written by someone fairly senior (much more so than myself) and is apart from this use of interfaces reasonable procedural code. I was wondering if anyone else had encountered/used this style and if it has any advantages over just using concrete DTOs everywhere without the interfaces.

答:
A particular problem I've seen with DTOs that use interfaces is that it allows this:

```<code>public interface ISomeDTO { string SomeProperty { get; set; }}

public class SomeDTO : ISomeDTO
{
    public string SomeProperty { get; set; }
    string ISomeDTO.SomeProperty { get { /* different behavior */ } set { SomeProperty = value; } }
}
</code>```

I've seen this pattern applied as a quick, dirty hack to implement some critical behavior. This leads to code which can have very confusing behavior:

```<code>SomeDTO a = GetSomeDTO();
ISomeDTO ia = a;
Assert.IsTrue(a.SomeProperty == ia.SomeProperty); // assert fails!
</code>```

This is difficult to maintain and confusing to try to untangle or refactor. IMO, adding behavior to DTOs violates the single responsibility principle. The purpose of a DTO is to represent data in a format that can be persisted and populated by a persistence framework.

DTOs are not domain models. We shouldn't be concerned if DTOs are anemic. To quote Martin Fowler's discussion of the anemic domain model:

It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities.

Title: Programming to Data Oriented Interfaces

Body:
A particular problem I've seen with DTOs that use interfaces is that it allows this:

public interface ISomeDTO { string SomeProperty { get; set; }}

public class SomeDTO : ISomeDTO
{
    public string SomeProperty { get; set; }
    string ISomeDTO.SomeProperty { get { /* different behavior */ } set { SomeProperty = value; } }
}

I've seen this pattern applied as a quick, dirty hack to implement some critical behavior. This leads to code which can have very confusing behavior:

SomeDTO a = GetSomeDTO();
ISomeDTO ia = a;
Assert.IsTrue(a.SomeProperty == ia.SomeProperty); // assert fails!

This is difficult to maintain and confusing to try to untangle or refactor. IMO, adding behavior to DTOs violates the single responsibility principle. The purpose of a DTO is to represent data in a format that can be persisted and populated by a persistence framework.

DTOs are not domain models. We shouldn't be concerned if DTOs are anemic. To quote Martin Fowler's discussion of the anemic domain model:

It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities.


问:
Is it bad practice that a controller calls a repository instead of a service?
Is it bad practice that a controller calls a repository instead of a service?

To explain more:

I figure out that in good design controllers call services and services use repositories.

But sometimes in controller I don't have/need any logic and just need to fetch from the database and pass it to the view.

And I can do it by just calling the repository - no need to call the service. Is this bad practice?

答:
No, think of it this way: a repository is a service (also).

If the entities you retrieve through the repository handle most of the business logic there is no need for other services. Just having the repository is enough.

Even if you have some services that you must pass through to manipulate your entities. Grab the entity from the repository first and then pass it to said service. Being able to toss up a HTTP 404 before even trying is very convenient.

Also for read scenario's it's common you just need the entity to project it to a DTO/ViewModel. Having a service layer in between then often results in a lot of pass through methods which is rather ugly.

ContentLicense: CC BY-SA 4.0

ContentLicense: CC BY-SA 3.0


问:
Is it bad practice to run Node.js and apache in parallel?
I have an idea in mind and would like to know if that's the way to go for my end application.

Think of my application as a social networking system in which I want to implement chat functionality. For that, I'd like to push data from the server to the client. I have heard I could use Node.js for that.

In the meanwhile, I want a 'regular' system for posting status updates and such, for which I'd like to use PHP and an apache server.

The only way I can think of is having Node.js and apache running parallel. But is that the way to go here? I'd think there would be a somewhat neater solution for this.

答:
You could use node.js as the server:

you can set up a server in node, adding the following modules:

express: static html server

ws:      websocket support

sphp:    PHP support

You can make a simple and fast webserver, with websockets binding to port 80 and using PHP as server side scripting language.
You can almost use the example server in sphp, as is.

I should mention that I'm the author of sphp. There are other options for PHP integration into node.

You install npm (Node package manager) to your system and then install the node modules you need:

In project directory

```<code>npm install express ws sphp
</code>```

then you copy the example.js and modify it to needs.

See examples her: https://github.com/paragi/sphp

For the basics see also: https://github.com/paragi/was

Body:
You could use node.js as the server:

you can set up a server in node, adding the following modules:

express: static html server

ws:      websocket support

sphp:    PHP support

You can make a simple and fast webserver, with websockets binding to port 80 and using PHP as server side scripting language.
You can almost use the example server in sphp, as is.

I should mention that I'm the author of sphp. There are other options for PHP integration into node.

You install npm (Node package manager) to your system and then install the node modules you need:

In project directory

npm install express ws sphp

then you copy the example.js and modify it to needs.

See examples her: https://github.com/paragi/sphp

For the basics see also: https://github.com/paragi/was


问:
Circular dependencies: Recursive grammar parser (e.g. json)
(TLDR) To build a parser for a recursive grammar by composition of individual parsers (e.g. with a parser combinator framework), there are often circular dependencies between some of the individual parsers. While circular dependencies are generally a sign of bad design, is this a valid case where the circular dependency is inevitable? If so, which solution would be preferable to deal with the circular dependency? Or are parser combinators just a bad idea altogether? (/TLDR)

There are other questions asking about dependency injection with circular dependencies. Typically, the answer is to change the design to avoid the circularity.

How to solve circular dependency?

How to handle "circular dependency" in dependency injection

Is circular Dependency Injection a good practice?

I have come across a typical case where I encounter circular dependencies: If I want to have different services to inspect a recursive structure.

I have been thinking about other examples, but so far the best I come up with is a parser for a recursive grammar. Let's use json as an example, because it is simple and well-known.

A json "value" can be a string (".."), an object ({..}) or an array ([..]).

A string is simple to parse, and has no further children.

An object is made up of keys and values, and the surrounding object syntax.

An array is made up of values, and the surrounding array syntax.

A "key" within an object is basically the same as a string.

Now I am going to create a number of parser objects:

A value parser, which depends on the other 3 parsers.

An object parser, which depends on string parser and value parser.

An array parser, which depends on value parser.

A string parser.

I want to manage the 4 parsers with a dependency injection container.
Or, even if I don't want a container, we still have to figure out in which order to create the different parsers. There is a chicken-and-egg problem.

There are known solutions to this, which can be observed in existing parser libraries. So far I have mostly seen the "stub" solution.

Avoid the circular dependency..

.. by passing the value parser as an argument to the object and array parsers' parse() method.

This works, but it taints the signature of the parse() method. Imagine we want this to be something like a parser combinator, which can be reused for other grammars. We would want a parser interface that is generic and independent of the specific grammar, so we can't have it require a specific parser to be passed around.

Use a stub.

Instead of requiring each dependency in the constructor, we could use a set() or add() method on one of the parsers. E.g. we first create an empty value parser ("stub"), and then add the object, array and string parsers to it via the add() method.

Use a proxy.

Instead of creating the actual value parser, we create a proxy object, with a reference to the container. Only when the parse() method is called the first time on the proxy value parser, the real value parser is created.

Now this is all fine, and I suppose it is just a matter of taste, which solution I prefer.

But how does this fit with the typical high-horse response that circular dependencies are a sign of bad design? The example seems totally valid, and there is an entire class of problems like this.

答:
First, there is no way of expressing a JSON parser in a way that is not ultimately "circular". We can however, stave off the circularity. To express this in a simpler way, we use a simple formal language defined as

```<code>array = squareArray | angleArray
squareArray = "[" array* "]"
angleArray = "<" array* ">"
</code>```

and a corresponding type (in pseudo-code)

```<code>type Array = SquareArray List[Array] | AngleArray List[Array]
</code>```

We then define a simple parser of this type (using a fictional monadic parser library).

```<code>arrayParser : Parser[Array]
arrayParser = try squareArray `or` angleArray

squareArrayParser : Parser[Array]
squareArrayParser =
      from start  in parseText "["
      from arrays in many arrayParser
      from end    in parseText "]"
      select SquareArray arrays

angleArrayParser : Parser[Array]
angleArrayParser =
      from start  in parseText "<"
      from arrays in many arrayParser
      from end    in parseText ">"
      select AngleArray arrays
</code>```

There is, to my mind, absolutely nothing wrong with the above definition. If we are dead set on removing circularity, we can note that arrayParser, squareArrayParser and angleArrayParser are all defined recursively. We can factor out this recursive nature by first making each take the other as a parameter.

```<code>arrayParserF : forall t. Parser[t] -> Parser[t] -> Parser[t]
arrayParserF pSquareArray pAngleArray = try pSquareArray `or` pAngleArray

squareArrayParserF : forall s, t. (s -> t) -> Parser[s]  -> Parser[t]
squareArrayParserF pSquareArray pArrayParser =
      from start  in parseText "["
      from arrays in many pArrayParser
      from end    in parseText "]"
      select pSquareArray arrays

angleArrayParserF : forall s, t. (s -> t) -> Parser[s] -> Parser[t]
angleArrayParserF pAngleArray pArrayParser =
      from start  in parseText "<"
      from arrays in many pArrayParser
      from end    in parseText ">"
      select pAngleArray arrays
</code>```

We see that we can immediately get back what we started with by saying

```<code>arrayParser' : Parser[Array]
arrayParser' = arrayParserF squareArrayParser' angleArrayParser'
  where
    squareArrayParser' : Parser[Array]
    squareArrayParser' = squareArrayParserF SquareArray arrayParser'

    angleArrayParser' : Parser[Array]
    angleArrayParser' = angleArrayParserF AngleArray arrayParser'
</code>```

Or equivalently

```<code>arrayParser' : Parser[Array]
arrayParser' = (\ pArrayParser ->
                  arrayParserF
                    (squareArrayParserF pArrayParser)
                    (angleArrayParserF pArrayParser)) arrayParser'
</code>```

Or equivalently (for fun)

```<code>arrayParser' : Parser[Array]
arrayParser' = fix makeArrayParser SquareArray AngleArray

makeArrayParser : ([t] -> t) -> ([t] -> t) -> Parser[T] -> Parser[T]
makeArrayParser pSquareArray pAngleArray pArrayParser =
    arrayParserF
        (squareArrayParserF pSquareArray pArrayParser)
        (angleArrayParserF  pAngleArray  pArrayParser)
</code>```

While this is mostly academic, it is not entirely useless, as we can now very easily define a parser that parses up to some fixed nesting of brackets.

```<code>fixedArrayParser : Parser [Array]
fixedArrayParser 1 = makeArrayParser SquareArray AngleArray blankParser
fixedArrayParser (n + 1) = makeArrayParser SquareArray AngleArray (fixedArrayParser n)
</code>```

We can even get more creative with our combinators and interpret our language as expressions of sums and products

```<code>sumsAndProductParser : Parser [int]
sumsAndProductsParser = fix (makeArrayParser product sum)
</code>```

So factoring out our parser into subparsers can help us achieve flexibility and usability -- it does make it much easier to parse restrictions and extensions of the original grammar -- but it does so at a cost of complexity. If all you want to do is parse JSON then this may well be too much.

Body:
First, there is no way of expressing a JSON parser in a way that is not ultimately "circular". We can however, stave off the circularity. To express this in a simpler way, we use a simple formal language defined as

array = squareArray | angleArray
squareArray = "[" array* "]"
angleArray = "<" array* ">"

and a corresponding type (in pseudo-code)

type Array = SquareArray List[Array] | AngleArray List[Array]

We then define a simple parser of this type (using a fictional monadic parser library).

arrayParser : Parser[Array]
arrayParser = try squareArray `or` angleArray

squareArrayParser : Parser[Array]
squareArrayParser =
      from start  in parseText "["
      from arrays in many arrayParser
      from end    in parseText "]"
      select SquareArray arrays

angleArrayParser : Parser[Array]
angleArrayParser =
      from start  in parseText "<"
      from arrays in many arrayParser
      from end    in parseText ">"
      select AngleArray arrays

There is, to my mind, absolutely nothing wrong with the above definition. If we are dead set on removing circularity, we can note that arrayParser, squareArrayParser and angleArrayParser are all defined recursively. We can factor out this recursive nature by first making each take the other as a parameter.

arrayParserF : forall t. Parser[t] -> Parser[t] -> Parser[t]
arrayParserF pSquareArray pAngleArray = try pSquareArray `or` pAngleArray

squareArrayParserF : forall s, t. (s -> t) -> Parser[s]  -> Parser[t]
squareArrayParserF pSquareArray pArrayParser =
      from start  in parseText "["
      from arrays in many pArrayParser
      from end    in parseText "]"
      select pSquareArray arrays

angleArrayParserF : forall s, t. (s -> t) -> Parser[s] -> Parser[t]
angleArrayParserF pAngleArray pArrayParser =
      from start  in parseText "<"
      from arrays in many pArrayParser
      from end    in parseText ">"
      select pAngleArray arrays

We see that we can immediately get back what we started with by saying

arrayParser' : Parser[Array]
arrayParser' = arrayParserF squareArrayParser' angleArrayParser'
  where
    squareArrayParser' : Parser[Array]
    squareArrayParser' = squareArrayParserF SquareArray arrayParser'

    angleArrayParser' : Parser[Array]
    angleArrayParser' = angleArrayParserF AngleArray arrayParser'

Or equivalently

arrayParser' : Parser[Array]
arrayParser' = (\ pArrayParser ->
                  arrayParserF
                    (squareArrayParserF pArrayParser)
                    (angleArrayParserF pArrayParser)) arrayParser'

Or equivalently (for fun)

arrayParser' : Parser[Array]
arrayParser' = fix makeArrayParser SquareArray AngleArray

makeArrayParser : ([t] -> t) -> ([t] -> t) -> Parser[T] -> Parser[T]
makeArrayParser pSquareArray pAngleArray pArrayParser =
    arrayParserF
        (squareArrayParserF pSquareArray pArrayParser)
        (angleArrayParserF  pAngleArray  pArrayParser)

While this is mostly academic, it is not entirely useless, as we can now very easily define a parser that parses up to some fixed nesting of brackets.

fixedArrayParser : Parser [Array]
fixedArrayParser 1 = makeArrayParser SquareArray AngleArray blankParser
fixedArrayParser (n + 1) = makeArrayParser SquareArray AngleArray (fixedArrayParser n)

We can even get more creative with our combinators and interpret our language as expressions of sums and products

sumsAndProductParser : Parser [int]
sumsAndProductsParser = fix (makeArrayParser product sum)

So factoring out our parser into subparsers can help us achieve flexibility and usability -- it does make it much easier to parse restrictions and extensions of the original grammar -- but it does so at a cost of complexity. If all you want to do is parse JSON then this may well be too much.


答:
Many grammars have mutually recursive production rules, JSON being a prime example. It is not a mark of a bad design.

With regards to using parser combinator frameworks, if the host language allows mutually recursive definitions (e.g. Haskell) , then there is no problem. In languages which do not (e.g. Java), then one trick is to allow for lazily initialised parsers - I used this in my framework. An example of it's usage, for a JSON grammar, is here.

The lazily initialised parser is jvalue:

```<code>private static final Parser.Ref<Character, Node> jvalue = Parser.ref();
</code>```

which is declared at the beginning of the grammar, and initialised at the end:

```<code>static {
    jvalue.set(
        choice(
            jnull,
            jbool,
            jnumber,
            jtext,
            jarray,
            jobject
        ).label("JSON value")
    );
}
</code>```

The Parser.Ref type is itself a Parser (i.e. it implements the Parser interface).

One of the prime advantages of the parser combinator approach is that it provides a DSL for defining grammars, which is hosted in the programming language you're already using. This itself has benefits, such as making the semantic actions associated with your grammar production rules subject to the type-checking provided by the host language - i.e. your rules have to be well-typed. Another benefit is being able to extend the DSL with your own combinators.

Title: Circular dependencies: Recursive grammar parser (e.g. json)

Body:
(TLDR) To build a parser for a recursive grammar by composition of individual parsers (e.g. with a parser combinator framework), there are often circular dependencies between some of the individual parsers. While circular dependencies are generally a sign of bad design, is this a valid case where the circular dependency is inevitable? If so, which solution would be preferable to deal with the circular dependency? Or are parser combinators just a bad idea altogether? (/TLDR)

There are other questions asking about dependency injection with circular dependencies. Typically, the answer is to change the design to avoid the circularity.

How to solve circular dependency?

How to handle "circular dependency" in dependency injection

Is circular Dependency Injection a good practice?

I have come across a typical case where I encounter circular dependencies: If I want to have different services to inspect a recursive structure.

I have been thinking about other examples, but so far the best I come up with is a parser for a recursive grammar. Let's use json as an example, because it is simple and well-known.

A json "value" can be a string (".."), an object ({..}) or an array ([..]).

A string is simple to parse, and has no further children.

An object is made up of keys and values, and the surrounding object syntax.

An array is made up of values, and the surrounding array syntax.

A "key" within an object is basically the same as a string.

Now I am going to create a number of parser objects:

A value parser, which depends on the other 3 parsers.

An object parser, which depends on string parser and value parser.

An array parser, which depends on value parser.

A string parser.

I want to manage the 4 parsers with a dependency injection container.
Or, even if I don't want a container, we still have to figure out in which order to create the different parsers. There is a chicken-and-egg problem.

There are known solutions to this, which can be observed in existing parser libraries. So far I have mostly seen the "stub" solution.

Avoid the circular dependency..

.. by passing the value parser as an argument to the object and array parsers' parse() method.

This works, but it taints the signature of the parse() method. Imagine we want this to be something like a parser combinator, which can be reused for other grammars. We would want a parser interface that is generic and independent of the specific grammar, so we can't have it require a specific parser to be passed around.

Use a stub.

Instead of requiring each dependency in the constructor, we could use a set() or add() method on one of the parsers. E.g. we first create an empty value parser ("stub"), and then add the object, array and string parsers to it via the add() method.

Use a proxy.

Instead of creating the actual value parser, we create a proxy object, with a reference to the container. Only when the parse() method is called the first time on the proxy value parser, the real value parser is created.

Now this is all fine, and I suppose it is just a matter of taste, which solution I prefer.

But how does this fit with the typical high-horse response that circular dependencies are a sign of bad design? The example seems totally valid, and there is an entire class of problems like this.

Body:
Many grammars have mutually recursive production rules, JSON being a prime example. It is not a mark of a bad design.

With regards to using parser combinator frameworks, if the host language allows mutually recursive definitions (e.g. Haskell) , then there is no problem. In languages which do not (e.g. Java), then one trick is to allow for lazily initialised parsers - I used this in my framework. An example of it's usage, for a JSON grammar, is here.

The lazily initialised parser is jvalue:

private static final Parser.Ref<Character, Node> jvalue = Parser.ref();

which is declared at the beginning of the grammar, and initialised at the end:

static {
    jvalue.set(
        choice(
            jnull,
            jbool,
            jnumber,
            jtext,
            jarray,
            jobject
        ).label("JSON value")
    );
}

The Parser.Ref type is itself a Parser (i.e. it implements the Parser interface).

One of the prime advantages of the parser combinator approach is that it provides a DSL for defining grammars, which is hosted in the programming language you're already using. This itself has benefits, such as making the semantic actions associated with your grammar production rules subject to the type-checking provided by the host language - i.e. your rules have to be well-typed. Another benefit is being able to extend the DSL with your own combinators.


答:
Recursive data structures are always a bit tricky, and you will either need some kind of laziness, or to mutate your data structure after initial construction.
Of these two, mutation is simpler, and can be easily used to implement laziness.
However, external set()ers lead to quite fragile design where you are forced to perform easily forgettable, manual steps to make sure your parser object has been properly initialized.

For that reason, I would consider a dependency container that is queried lazily to be the far cleaner solution:

```<code>class ObjectParser(parsers) {
    parse(input) { ... parsers.getArrayParser().parse(input) ... }
}

class ArrayParser(parsers) {
    parse(input) { ... parsers.getObjectParser().parse(input) ... }
}

class Parsers {
   // Instead of creating a new object each time,
   // you could use the getter to lazily initialize some field.
   getArrayParser()  { return new ObjectParser(this) }
   getObjectParser() { return new ArrayParser(this) }
}

new Parsers().getObjectParser().parse(input)
</code>```

Note that the parser “objects” ObjectParser and ArrayParser only have a single public method parse() in your design, so they would actually be equivalent to functions or closures. We can inline parsres.getArrayParser().parse(input) to parsers.parseArray(input):

```<code>class Parsers {
  parseArray(input) { ... this.parseObject(input) ... }
  parseObject(input) { ... this.parseArray(input) ... }
}

new Parsers().parseObject(input);
</code>```

So magically, the latter code is exactly equivalent and equally extensible, but uses far less code. Why? Because the host language object system already introduces the required indirection to make this work: the implicit this parameter (previously the explicit parsers) is already pointer-like, and method lookup must be done fairly lazily if you might have subclasses (“late binding”). But we don't even need that for a recursive descent parser, if our language allows us to pre-declare functions, or does not even need predeclarations. In C, this would work as well:

```<code>// predeclarations
ResultT parseArray(InputT input);
ResultT parseObject(InputT input);

// implementation
ResultT parseArray(InputT input) { ... parseObject(input) ... }
ResultT parseObject(InputT input)  { ... parseArray(input) ... }
</code>```

Where does the indirection come from now? From the compiler: due to the predeclarations, a call to one function can be compiled before the call target is known. This is fairly straightforward if both functions are in the same compilation unit, otherwise a linker is required to “tie the knot”.

If you are just writing a recursive descent parser (which works for JSON but doesn't work well for more complicated languages that aren't LL(1)), then using the simplest thing that could work is the solution you should choose: no mutability, no proxy objects, not virtual dispatch, just mutually recursive procedures.

If you want to use a parser generator that simulates a recursive descent parser for you, you will need some values or objects to pass around. Should your language happen to support functional programming or at least higher-order functions, nothing changes because you can just pass handles to those parser function around (e.g. function pointers in C, method objects in Java8, …). If your language is more purist OOP (e.g. Java < 8, C++ < 11), you will need the explicit objects ObjectParser, ArrayParser etc. as in the first example. Only then would I consider this massive waste of code to be a viable solution.

Body:
Recursive data structures are always a bit tricky, and you will either need some kind of laziness, or to mutate your data structure after initial construction.
Of these two, mutation is simpler, and can be easily used to implement laziness.
However, external set()ers lead to quite fragile design where you are forced to perform easily forgettable, manual steps to make sure your parser object has been properly initialized.

For that reason, I would consider a dependency container that is queried lazily to be the far cleaner solution:

class ObjectParser(parsers) {
    parse(input) { ... parsers.getArrayParser().parse(input) ... }
}

class ArrayParser(parsers) {
    parse(input) { ... parsers.getObjectParser().parse(input) ... }
}

class Parsers {
   // Instead of creating a new object each time,
   // you could use the getter to lazily initialize some field.
   getArrayParser()  { return new ObjectParser(this) }
   getObjectParser() { return new ArrayParser(this) }
}

new Parsers().getObjectParser().parse(input)

Note that the parser “objects” ObjectParser and ArrayParser only have a single public method parse() in your design, so they would actually be equivalent to functions or closures. We can inline parsres.getArrayParser().parse(input) to parsers.parseArray(input):

class Parsers {
  parseArray(input) { ... this.parseObject(input) ... }
  parseObject(input) { ... this.parseArray(input) ... }
}

new Parsers().parseObject(input);

So magically, the latter code is exactly equivalent and equally extensible, but uses far less code. Why? Because the host language object system already introduces the required indirection to make this work: the implicit this parameter (previously the explicit parsers) is already pointer-like, and method lookup must be done fairly lazily if you might have subclasses (“late binding”). But we don't even need that for a recursive descent parser, if our language allows us to pre-declare functions, or does not even need predeclarations. In C, this would work as well:

// predeclarations
ResultT parseArray(InputT input);
ResultT parseObject(InputT input);

// implementation
ResultT parseArray(InputT input) { ... parseObject(input) ... }
ResultT parseObject(InputT input)  { ... parseArray(input) ... }

Where does the indirection come from now? From the compiler: due to the predeclarations, a call to one function can be compiled before the call target is known. This is fairly straightforward if both functions are in the same compilation unit, otherwise a linker is required to “tie the knot”.

If you are just writing a recursive descent parser (which works for JSON but doesn't work well for more complicated languages that aren't LL(1)), then using the simplest thing that could work is the solution you should choose: no mutability, no proxy objects, not virtual dispatch, just mutually recursive procedures.

If you want to use a parser generator that simulates a recursive descent parser for you, you will need some values or objects to pass around. Should your language happen to support functional programming or at least higher-order functions, nothing changes because you can just pass handles to those parser function around (e.g. function pointers in C, method objects in Java8, …). If your language is more purist OOP (e.g. Java < 8, C++ < 11), you will need the explicit objects ObjectParser, ArrayParser etc. as in the first example. Only then would I consider this massive waste of code to be a viable solution.


问:
What deters developers from using automated refactoring tools?
I was having a discussion with my colleagues about using the automated refactoring tools in IDEs (Eclipse, NetBeans, IntelliJ, Xcode, Visual Studio, etc) and was surprised that many of them were uncomfortable using such tools. One of them is a seasoned developer (Smalltalk, C/C++, Java, Javascript) for 20 years and he seldom uses an IDE and even when he does, he doesn't use the automated refactoring tools. He does a lot of refactorings, but he does them all by hand.

Personally, I rely a lot on refactoring tools. Whenever I work on a project, I try to pick an IDE that supports automated refactorings and use those refactorings whenever possible.

I am interested in finding out if professional developers here at Stack Exchange use automated refactoring tools. And, if you don't, why not?

To get things started, here are some reasons why my colleagues don't use the automated refactoring tools:

Trust - Sometimes they don't trust what the tool is doing especially if it is a complex refactoring like Pull-Up which might affect multiple files; they are worried that the tool might introduce subtle bugs.

Discoverability - Sometimes they don't even realize that such a refactoring is available in the IDE because it is not immediately obvious

Flexibility - Sometimes the tool is too rigid and they always feel like they have to configure it too much to get it to work the way they want.

Updated - summary

Based on the responses so far, I think I can summarize three things:

Developers don't have the time to try out all the different refactorings available. And because they can't try them out, they are suspicious of what they will do to the code (all the corner cases). This suspicion is warranted for production code under time pressure (even if you have tests to check). Perhaps better UI tools can alleviate this.

Developers have also been frustrated by the limitations of the refactoring tools especially when they use metaprogramming/reflection or have external files (xml, configuration, properties). Automated refactoring tools keep on improving but there will always be limitations. Sometimes the limitations are acceptable and other times they are not. I've spoken to several other colleagues and some of them are more tolerant of the limitations. For instance, if rename refactoring doesn't rename all the files but does a good job of renaming 90% of it, they are still happy to use the tool and fix up the remaining 10% by hand because it still saves time and effort.

[In my opinion from what I have gathered], developers feel that refactoring tools are nice-to-have features so if it doesn't work the first time (or does something unacceptable), they seem to be more incline to abandon them and make changes by hand. Compare this to other tools like compilers/debuggers which also have limitations and bugs. Developers are likely to stick with them despite their limitations because they are essential features that you can't just abandon in your workflow.

Thanks for all the responses. If this topic is of interest to more people, I suggest turning it into a Community Wiki.

It would be interesting to find out whether the size of the project, the availability of tests, the maturity of the IDE affect people's decision to use automated refactoring tools.

答: I use an IDE to refactor code.  It does a decent job, but gets it wrong sometimes.  I also do whole codebase regex search and replace, and I often get them wrong too.  I use my revision-control software (or diff) to show me what changed in the codebase.  It happens often enough I check diffs now whenever I let my IDE do the refactoring.</p>


问:
Should I be using any algorithm to sort/find items, or use a language's built-in ways?
I'm currently a first semester IT student, and I'm wondering if it's better to write my method to find something e.g. in a C# List, or to use any built in method to do these, such as LINQ or .Find or .OrderBy method with lambdas?
I heard from a senior that the .NET optimizes my code according to the contents and amount of data in my list, and finds the best way of searching in it, or sorting it. Is that true?

The question stands basically for any built-in-method vs pseudocode learned. The C# is only an example of what I've meant with the question. I know that learning the pseudocodes will solve problems if interpreted to any language, still I'm curious about it's efficiency.

答:
Generally speaking, if the language or standard library provides a function to do what you want done, use it until or unless you have a specific reason you need to use something else. That latter can happen, but it's fairly unusual as a general rule.

Of course, in at least some cases it can make sense to consider some middle ground, such as writing a wrapper that usually uses the standard routine, but handles some corner cases it doesn't handle well, but happen to be important for your particular purpose (for one example, I once wrote a wrapper for the qsort in a C standard library because it did really poorly when asked to sort a collection that contained lots of duplicate items, and we expected a lot of duplicates much of the time).


答:
If your language's standard library provides a feature you need, and you have no reason to believe there is something wrong with its implementation or API, then use the standard.

Re-implementing the feature yourself will at best be a waste of time, since you'll be duplicating work other people have already done for you. At worst, your version will be slow and buggy because you won't have nearly as much time on the finer points of sorting algorithm implementations as the language implementers have, and the inevitable subtle differences between your version and the standard one will cause endless confusion for other developers.

It is important to have some clue how these algorithms are implemented, at least conceptually, because that's crucial to understanding why some methods (such as sorting methods) have the particular behaviors, performance characteristics and APIs that they do. For instance, if you never take an algorithms and data structures course, then you'll have no idea why a hash table can't be sorted (without copying all the entries to some other structure, or using a terrible hash function).

Of course, if there really is something wrong with the standard library feature, then you don't have much of a choice. But that's not very common, and if you read enough good books/blogs/etc about your language of choice you'll soon learn where the genuine flaws are and how to avoid them.

Title: Should I be using any algorithm to sort/find items, or use a language's built-in ways?

Body:
I'm currently a first semester IT student, and I'm wondering if it's better to write my method to find something e.g. in a C# List, or to use any built in method to do these, such as LINQ or .Find or .OrderBy method with lambdas?
I heard from a senior that the .NET optimizes my code according to the contents and amount of data in my list, and finds the best way of searching in it, or sorting it. Is that true?

The question stands basically for any built-in-method vs pseudocode learned. The C# is only an example of what I've meant with the question. I know that learning the pseudocodes will solve problems if interpreted to any language, still I'm curious about it's efficiency.


答:
While the advice being given here about not implementing your own sorting algorithm in the real world is, I think, sound, you still have to choose among initial data structures, and a List is not always the best starting point for sorting/searching.

Searching the List once is one thing, but searching it many times is another.

In the latter case, the List might be better transformed into a more search-oriented data structure (an array, a sorted array, a tree, a hash table, a specialized tree, a B+ tree, etc...), with a lot depending on factors around mutability.

In some cases it may be reasonable to load the data into a database and offload the search/sort to it.


问:
Coordinating threads in a multithreaded server
The goal is to develop something similar with a quiz application: there is a server to which players connect. At some point, a game is started. The game consists in asking the players a few multiple answer questions and determining the winner based on some criteria.

The server spawns a new thread for each client (I know it might be better and easier to use select, but the point is to understand/learn multithreading). The users are "pending" until a sufficient number of users are available such that the game can start.

The problem is what happens when the game starts? My current best approach is to use a lot of shared data that is constantly pooled by all threads and spawn a game controller thread that controls the game.

More specifically, I would have a data structure Player that has some flag inGame. When sufficient players are available, the player that notices this starts the game control thread and passes the available players to it. The game control thread marks all available players as being "inGame" and assigns a question to them. After some time, it checks for an answer. In the meantime, the players constantly check for updates from the game control thread.

I feel that this shared data approach is not the best. Do you have any suggestion on how could I improve the architecture of my application?

答:
If you want to block a number of threads until they are all ready, the common construct is a "barrier". You initialize it with a count, and once that many threads are waiting on the barrier, they are released.

If your library doesn't have a barrier, you can implement one using two mutexes and some logic, as described in this SO answer citing The Little Book of Semaphores.


问:
How are objects stored in unordered_sets?
I've been doing a bit of research on the subject. I know unordered_sets are hash tables, where the key and value are one and the same. What I'd like to know is how the compiler figures out where in the table each object belongs.</p>

答:
An unordered_set is specified quite a bit more "tightly" than most people seem to realize, so it's difficult (if possible at all) to implement it as anything except a hash table that resolves hash collisions by chaining.

In particular, the standard requires that the hash table consist of buckets, that each bucket contain items that hashed to the same value, that the size of a bucket be obtainable with constant complexity, and that traversing the items in a bucket be possible with linear complexity.

Those requirements are trivial to meet if you use collision chaining--and difficult or impossible to meet otherwise.

As such, the basic data structure would typically look something like this (ignoring some extra template parameters we don't care about right now):

```<code>template <class T>
class unordered_set {
    std::vector<std::vector<T> > data;

    // ...
</code>```

The insert member might look vaguely like this:

```<code>pair<iterator, bool>
insert(T t) {
    auto raw_pos = hash(t); // hash the input
    auto pos = raw_pos % data.size(); // reduce the range to that of the table

    auto &bucket = data[pos];

    // try to find existing item:
    auto existing = std::find(bucket.begin(), bucket.end(), t);

    // if there was no existing item, add the new one
    if (existing == bucket.end()) {
        bucket.push_back(t);
        return {bucket.back(), true};
    }
    // if there was an existing item, return iterator and false to indicate we didn't add
    return {existing, false};
}
</code>```

Note that this definitely isn't an attempt at anything similar to production code--just a general sketch of basic logic. And when I say "basic", I mean it--a real implementation needs considerably more logic, such as to re-size the table in case the new addition increases the load factor beyond the specified limit. In fact, some of the code isn't just simplified, it's technically wrong as it is right now (but fixing it would make the code more complex without really adding much).

Body:
An unordered_set is specified quite a bit more "tightly" than most people seem to realize, so it's difficult (if possible at all) to implement it as anything except a hash table that resolves hash collisions by chaining.

In particular, the standard requires that the hash table consist of buckets, that each bucket contain items that hashed to the same value, that the size of a bucket be obtainable with constant complexity, and that traversing the items in a bucket be possible with linear complexity.

Those requirements are trivial to meet if you use collision chaining--and difficult or impossible to meet otherwise.

As such, the basic data structure would typically look something like this (ignoring some extra template parameters we don't care about right now):

template <class T>
class unordered_set {
    std::vector<std::vector<T> > data;

    // ...

The insert member might look vaguely like this:

pair<iterator, bool>
insert(T t) {
    auto raw_pos = hash(t); // hash the input
    auto pos = raw_pos % data.size(); // reduce the range to that of the table

    auto &bucket = data[pos];

    // try to find existing item:
    auto existing = std::find(bucket.begin(), bucket.end(), t);

    // if there was no existing item, add the new one
    if (existing == bucket.end()) {
        bucket.push_back(t);
        return {bucket.back(), true};
    }
    // if there was an existing item, return iterator and false to indicate we didn't add
    return {existing, false};
}

Note that this definitely isn't an attempt at anything similar to production code--just a general sketch of basic logic. And when I say "basic", I mean it--a real implementation needs considerably more logic, such as to re-size the table in case the new addition increases the load factor beyond the specified limit. In fact, some of the code isn't just simplified, it's technically wrong as it is right now (but fixing it would make the code more complex without really adding much).


问:
Is an AST enough to build any translator?
Note: In my ignorance of the difference between Programmers vs StackOverflow sites (which I know now), I had posted this question on StackOverflow earlier. What I'm looking for is some elaboration, for example, on the comment by Gene.

Once I am able to build an abstract syntax tree (AST) for an input, then:

regardless of the type of the grammar used for building the AST (LR, LL*, or even no formal grammar as with Perl 5);

regardless of the parser-generator used for building the AST (bison, antlr, or my own hand-written code); and

regardless of the number of passes I do over my input for building the AST;

... is it true that I can implement any feature of any language ever created just by visiting the AST N number of times?

I'm not worried about the complexity of the resulting code, or its performance, I just need to know whether an AST is sufficient to allow the building of a translator (a compiler or an interpreter) regardless of the feature I am trying to build.

I am not looking for an exhaustive list of what cannot be done with an AST, just 1 example should suffice. If an AST is a sufficiently fundamental (and thus versatile/powerful) structure to allow the building of just about any translator, then a I'd like to see a confirmation of this fact. Getting the source of the book or a URL (if one exists) would be an additional bonus.

Just as an AST, being a tree, would be more powerful data structure than (and, thus, can also emulate) a flat or linear intermediate representation (IR) such as the Three-Address Code as covered in the Dragon book, so also an abstract syntax graph (ASG, if you will), being a graph, would be more powerful than an AST. Thus, elaborating further on my original post: Is there any translator feature known to mankind as of this writing that cannot be implemented by an AST and requires the use of an ASG?

答:
Theoretically, yes, assuming you have an AST for a Turing Complete language. It may mean interpreting a+b as something not meaning "add the variables referenced by these two identifiers together", or building your own compiler in the source language to implement the feature, or something else particularly impractical. But once you can model one Turing Complete language, you can do whatever you want.

Practically though, no. If your source language (and AST) has no concept of functions, then it may be tricky to implement them as a feature just by AST translations. Could you do it in the source language? Sure. Could you add AST nodes to support it? Sure. Those are pretty easy.

But changing the meaning of the syntax nodes in any coherent way gets a lot more (order of magnitude+) difficult.


问:
Should I be returning promises from any function that uses them?
Promises is a fairly new pattern for me, so I'm still building my intuition for them.

I recently came across a case where some code in an adapter-like bit of code was once synchronous, and then became asynchronous, so promises were introduced.
Consider:

```<code>function runCalculation() {
  var params = this.getParams();
  this.callLibraryCalculation(params);
}
</code>```

Here, getParams collects values from various places and puts them in one object that can be used by callLibraryCalculation, which wraps, as you would expect, a call from an external source.  All this is obviously simplified for the purpose of the question.

So this all worked, until a new use case required getParams to retrieve some of it's values from an external API, introducing asynchronous behavior. So that function was altered to handle async, using and returning a promise. Which means consuming it has changed.

```<code>function runCalculation() {
  return this.getParams().then(function(params) {
    this.callLibraryCalculation(params);
  });
}
</code>```

I choose to return the promise here because the functions that call runCalculation have dependent logic that needs to be .then()-ed. but my question is about the callers of runCalculation. They are now producing their own promises as a result of consuming the one returned here. I can currently let most of those promises escape into the ether, because the callers represent the end of execution. But I notice that in the case where it is not end of execution, this passing of promises begins to invade a great deal of code, bubbling from caller to caller.

My inclination is to always return a promise from a function that must use one to order it's logic.

Is that inclination good intuition? Should I be worried that Promises, once introduced, start to take over my code?

Or to ask in a more answerable question: Are there considerations I may have missed that speak for or against such a practice?

答:
My inclination is to always return a promise from a function that must
  use one to order it's logic.

If you have a function with an async operation and you're using promises and there's ever ANY reason for the caller of the function to want to know when the async operation is done or what its final value is, then by all means just return the promise you already have internally.

This gives the caller more flexibility.  If the caller chooses to not use the returned promise, that's no problem.  At least it's there if the caller wants to use it.

Should I be worried that Promises, once introduced, start to take over
  my code?

I'm not sure what you mean by "take over your code".  If you want to give a caller access to async completion, then return a promise.  If you don't want to give a caller access to the async completion, then don't return a promise.  It's no more complex than that.

Any async operation in a function makes the containing function async.  It's contagious in that regard.  And, promises are the best way to deliver async results and coordinate multiple async operations.  So, all code that uses async operations should use promises.  This isn't "taking over your code" - it's the intelligent way to design your async code.  If it seems unnatural to you now, then you just need more experience and practice doing it and it will start to become natural and easy. At that point, it won't feel like anything took over your code, but rather that you're using the right tools for the job.


问:
Architecting an application with a single page javascript driven UI
I have a single page application where everything in the UI is javascript driven so any operation requiring data or updating of data is done via Ajax requests. The way things are setup right now is that my Ajax called are made to one ajax.php file which takes care of routing them to the proper service method. This works well but there's one problem. Whenever I have operations that require a user ID, I don't want to pass them as part of an ajax request so as to prevent tampering. Since I have a session running server-side, I have a Security service from which I can retrieve the user ID of the user currently logged in. The security does so by using a Session object that abstracts the access to the session (in my case, $_SESSION in PHP) implementing an interface. My security service gets injected into other services as needed, so for example, if I have a PostService->findUserPosts() method, that method uses the getUserId() method of the injected SecurityService object to figure out the user ID instead of having it passed as an argument.

The problem is I suspect (and others seem to agree) that not passing in the user ID to the service is bad design. But how do I get around doing that without sending the user ID via ajax? I can think of a few options, none of which I really like or know of a good way to implement:

1) Add a controller layer on the server side, in which case I can call SecurityService->getUserId() in the controller and pass in a separate call to PostService->findUserPosts($userId); the problem with this approach is that it requires me to add a bunch of controllers that are for the most part pretty redundant. As it is, I already a PostService->findPosts() method that basically just calls PostGateway->findPosts(). I can live with that redundancy because there will be a lot of places where the service will need to do more. But adding a third layer with a controller with a findPosts() method, that seems too much of a pain.

2) Pass the user ID in the ajax request and come up with some kind of tampering mechanism to make sure the ajax request can't be altered. I could do that by hashing the URL string of my request and appending that as a parameter, and then on the server comparing the hash. This is more obfuscation than anything though, since the hash would need to be generated client side, which means somebody looking through the code could figure out how the hash is generated.

3) Keep things as they are, bearing in mind that my user ID is at least not hard coded and various implementations of the Session object could be used, that way the user ID can be retrieved in multiple ways, not tying me to the PHP $_SESSION object.

4) Use a hybrid method of #1 and the current setup where if I need to access session info I use a controller, otherwise I call the service directly. This could work, though it doesn't feel like a clean, unified approach.

I tried to figure this out with two separate questions dealing with separate smaller problems, but I think the lack of context made it difficult to answer, so figured I'd formulate a question with the entire problem. Suggestions are welcome. Suggestions are welcome. Or should I say, much needed!

UPDATE: maybe a valid compromise would be to have a PostService->findByUser($userId) method and then have a UserService->findPosts() method that gets the userId from SecurityService the same way PostService is doing now?

答: If the user is already logged in and has a session then the browser is already using a session cookie which is a token.  I can't see why you would want to roll your own token solution when session management is standard and reliable.  Your php file is on your server so you can use your own password to get to the services which the user will never see on the browser.  You already can have their user id in your session because they already logged in.  Pass that user id to your services for record keeping but "login" to the services using your own web application password to that service which is stored on your php server.  I like your solution because you are not trying to go to multiple services straight from the browser but are instead using your php server as a sort of proxy.  It also sounds like since you are using php that your delivering layout combined with data but using innerhtml to display it in the DOM.  You might want to look at an HTML injection framework so that you don't have to reinvent the wheel while doing this.</p>


问:
Do we need to validate entire module usage or just arguments of public methods?
I've heard that it is recommended to validate arguments of public methods:

Should one check for null if he does not expect null?

Should a method validate its parameters?

MSDN - CA1062: Validate arguments of public methods (I have .NET background but question is not C# specific)

Motivation is understandable. If a module will be used in a wrong way, we want to throw exception immediately instead of any unpredictable behavior.

What bothers me, is that wrong arguments is not the only error which can be made while using a module. Here's some error scenarios where we need to add checking logic if we follow recommendations and don't want error escalation:

Incoming call - unexpected arguments

Incoming call - module is in a wrong state

External call - unexpected results returned

External call - unexpected side-effects (double-entry to a calling
module, breaking other dependencies states)

I've tried to take into account all these conditions and write a simple module with one method (sorry, not-C# guys):

```<code>public sealed class Room
{
    private readonly IDoorFactory _doorFactory;
    private bool _entered;
    private IDoor _door;
    public Room(IDoorFactory doorFactory)
    {
        if (doorFactory == null)
            throw new ArgumentNullException("doorFactory");
        _doorFactory = doorFactory;
    }
    public void Open()
    {
        if (_door != null)
            throw new InvalidOperationException("Room is already opened");
        if (_entered)
            throw new InvalidOperationException("Double entry is not allowed");
        _entered = true;
        _door = _doorFactory.Create();
        if (_door == null)
            throw new IncompatibleDependencyException("doorFactory");
        _door.Open();
        _entered = false;
    }
}
</code>```

Now It's safe =)

It's quite creepy. But imagine how creepy it can be in a real module with dozens of methods, complex state and a lot of external calls (hi, dependency injection lovers!). Note that if you're calling a module which behavior can be overridden (non-sealed class in C#) then you're making an external call and consequences are not predictable at the scope of the caller.

Summing up, what is the right way and why? If you can choose from options below, answer additional questions, please.

Check entire module usage. Do we need unit tests? Is there examples of such code? Should dependency injection be limited in usage (since it will cause more checking logic)? Isn't it practical to move those checks to debug-time (do not include in release)?

Check only arguments. From my experience, argument checking - especially null checking - is the least effective check, because argument error rarely lead to complex mistakes and error escalations. Most of the time you'll get a NullReferenceException at the next line. So why argument checks are so special?

Don't check module usage. It's quite unpopular opinion, can you explain why?

答:
TL;DR: Validate state change, rely on [validity of] current state.

Below I only consider release-enabled verifications. Debug-only active assertions are a form of documentation, which is useful in its own way and is out of scope for this question.

Consider following principles:

Common sense

Fail fast

DRY

SRP

Definitions

Component - an unit providing API

Client - user of component's API

Mutable state

Problem

In imperative languages, error symptom and its cause may be separated by hours of heavy lifting. State corruption can hide itself and mutate to result in inexplicable failure, as inspection of current state can't reveal full process of corruption and, therefore, origin of error.

Solution

Every change of the state should be carefully crafted and verified. One way to deal with mutable state is to keep it to its minimum. This is achieved by:

type system (const and final members declarations)

introducing invariants

verifying every change of component's state via public API's

When extending state of a component, consider doing so by letting compiler enforce immutability of new data. Also, enforce every sensible runtime constraint, limiting potential resulting states to a smallest possible well-defined set.

Example

```<code>// Wrong
class Natural {
    private int number;
    public Natural(int number) {
        this.number = number;
    }
    public int getInt() {
      if (number < 1)
          throw new InvalidOperationException();
      return number;
    }
}

// Right
class Natural {
    private readonly int number;
    /**
     * @param number - positive number
     */
    public Natural(int number) {
      // Going to modify state, verification is required
      if (number < 1)
        throw new ArgumentException("Natural number should be  positive: " + number);
      this.number = number;
    }
    public int getInt() {
      // State is guaranteed by construction and compiler
      return number;
    }
}
</code>```

Repetition and responsibility cohesion

Problem

Checking preconditions and post-conditions of operations leads to duplication of verification code in both client and component. Validating component invocation often forces client to take some of component's responsibilities.

Solution

Rely on component to perform state verification when possible. Components are to provide an API that does not require special usage verification (arguments verification or operation sequence enforcement, for example) to keep component state to be well-defined. They oblige to verify API invocation arguments as required, report failures by means necessary, and  strive to prevent their state corruption.

Clients should rely on components to verify use of their API. Not only repetition is avoided,  client no longer depends on extra implementation details of component.  Consider framework to be a component.
Only write custom verification code when component's invariants are not strict enough or to encapsulate  components exception as implementation detail.

If an operation does not change state and is not covered by state change verifications, verify every argument on deepest possible level.

Example

```<code>class Store {
  private readonly List<int> slots = new List<int>();
  public void putToSlot(int slot, int data) {
    if (slot < 0 || slot >= slots.Count) // Unnecessary, validated by List, only needed for custom error message
      throw new ArgumentException("data");
    slots[slot] = data;
  }
}

class Natural {
   int _number;
   public Natural(int number) {
       if (number < 1)
          number = 1;  //Wrong: client can't rely on argument verification, additional state uncertainity is introduced.  Right: throw new ArgumentException(number);
       _number = number;
   }
}
</code>```

Answer

When described principles are applied to the example in question, we get:

```<code>public sealed class Room
{
    private bool _entered = false;
    // Do not use lazy instantiation if not absolutely necessary, this introduces additional mutable state
    private readonly IDoor _door;
    public Room(IDoorFactory doorFactory)
    {
        // Rely on system null check
        IDoor door = _doorFactory.Create();
        // Modifying own state, verification is required
        if (door == null)
           throw new ArgumentNullException("Door");
        _door = door;
    }
    public void Enter()
    {
        // Room invariants do not guarantee _entered value. Door state is indirectly a part of our state. Verification is required to prevent second door state change below.
        if (_entered)
           throw new InvalidOperationException("Double entry is not allowed");
        _entered = true;
        // rely on immutability for _door field to be non-null
        // rely on door implementation to control resulting door state
        _door.Open();
    }
}
</code>```

Summary

Client's state consists of own fields values and parts of component's state that are not covered by its own invariants. Verification should only be done before actual state change of a client.

Body:
TL;DR: Validate state change, rely on [validity of] current state.

Below I only consider release-enabled verifications. Debug-only active assertions are a form of documentation, which is useful in its own way and is out of scope for this question.

Consider following principles:

Common sense

Fail fast

DRY

SRP

Definitions

Component - an unit providing API

Client - user of component's API

Mutable state

Problem

In imperative languages, error symptom and its cause may be separated by hours of heavy lifting. State corruption can hide itself and mutate to result in inexplicable failure, as inspection of current state can't reveal full process of corruption and, therefore, origin of error.

Solution

Every change of the state should be carefully crafted and verified. One way to deal with mutable state is to keep it to its minimum. This is achieved by:

type system (const and final members declarations)

introducing invariants

verifying every change of component's state via public API's

When extending state of a component, consider doing so by letting compiler enforce immutability of new data. Also, enforce every sensible runtime constraint, limiting potential resulting states to a smallest possible well-defined set.

Example

// Wrong
class Natural {
    private int number;
    public Natural(int number) {
        this.number = number;
    }
    public int getInt() {
      if (number < 1)
          throw new InvalidOperationException();
      return number;
    }
}

// Right
class Natural {
    private readonly int number;
    /**
     * @param number - positive number
     */
    public Natural(int number) {
      // Going to modify state, verification is required
      if (number < 1)
        throw new ArgumentException("Natural number should be  positive: " + number);
      this.number = number;
    }
    public int getInt() {
      // State is guaranteed by construction and compiler
      return number;
    }
}

Repetition and responsibility cohesion

Problem

Checking preconditions and post-conditions of operations leads to duplication of verification code in both client and component. Validating component invocation often forces client to take some of component's responsibilities.

Solution

Rely on component to perform state verification when possible. Components are to provide an API that does not require special usage verification (arguments verification or operation sequence enforcement, for example) to keep component state to be well-defined. They oblige to verify API invocation arguments as required, report failures by means necessary, and  strive to prevent their state corruption.

Clients should rely on components to verify use of their API. Not only repetition is avoided,  client no longer depends on extra implementation details of component.  Consider framework to be a component.
Only write custom verification code when component's invariants are not strict enough or to encapsulate  components exception as implementation detail.

If an operation does not change state and is not covered by state change verifications, verify every argument on deepest possible level.

Example

class Store {
  private readonly List<int> slots = new List<int>();
  public void putToSlot(int slot, int data) {
    if (slot < 0 || slot >= slots.Count) // Unnecessary, validated by List, only needed for custom error message
      throw new ArgumentException("data");
    slots[slot] = data;
  }
}

class Natural {
   int _number;
   public Natural(int number) {
       if (number < 1)
          number = 1;  //Wrong: client can't rely on argument verification, additional state uncertainity is introduced.  Right: throw new ArgumentException(number);
       _number = number;
   }
}

Answer

When described principles are applied to the example in question, we get:

public sealed class Room
{
    private bool _entered = false;
    // Do not use lazy instantiation if not absolutely necessary, this introduces additional mutable state
    private readonly IDoor _door;
    public Room(IDoorFactory doorFactory)
    {
        // Rely on system null check
        IDoor door = _doorFactory.Create();
        // Modifying own state, verification is required
        if (door == null)
           throw new ArgumentNullException("Door");
        _door = door;
    }
    public void Enter()
    {
        // Room invariants do not guarantee _entered value. Door state is indirectly a part of our state. Verification is required to prevent second door state change below.
        if (_entered)
           throw new InvalidOperationException("Double entry is not allowed");
        _entered = true;
        // rely on immutability for _door field to be non-null
        // rely on door implementation to control resulting door state
        _door.Open();
    }
}

Summary

Client's state consists of own fields values and parts of component's state that are not covered by its own invariants. Verification should only be done before actual state change of a client.


问:
Blurred line between a framework and an SDK
I have been programming professionally for a couple of decades. Some years ago, the framework word was not so widely used as it is today, but I still believe we've been using "frameworks" for a very long time before they were called that.

For example, the Java SDK has parts that can be considered frameworks; like for example the Collections framework. Also J2EE gives some structure, classes, interfaces and directives for building web solutions. Isn't that a framework? Well, Wikipedia calls it a platform.

Usually throughout the years, one builds up a plethora of interfaces and classes that conform a common practice allowing you to build apps in less time than before by leveraging your previous achievements. Isn't that body of structures, steps, analysis and design products (interfaces to implement and abstract classes to extend) a framework?

Is there a canonical, and quotable, hard line separating what a framework is and what a comprehensive set of APIs or a SDK is?

When was the term framework introduced in computer science?

Note: this other question is about API vs SDK, so it's not a duplicate.

Wikipedia only says this:

"An architecture framework establishes a common practice for creating,
  interpreting, analyzing and using architecture descriptions within a
  particular domain of application or stakeholder community.

答:
The definition of a Framework has evolved. When Sun released the Java collections framework, it was just a fancy way of saying "library". Today, a framework means more than that. It's code that hosts your code. It calls your code versus your code calling it. (The Hollywood Principle)

From Martin Fowler:

"Inversion of Control is a key part of what makes a framework
  different to a library. A library is essentially a set of functions
  that you can call, these days usually organized into classes. Each
  call does some work and returns control to the client.

"A framework embodies some abstract design, with more behavior built
  in. In order to use it you need to insert your behavior into various
  places in the framework either by subclassing or by plugging in your
  own classes. The framework's code then calls your code at these
  points."

Wikipedia:

"In a framework, unlike in libraries or normal user applications, the
  overall program's flow of control is not dictated by the caller, but
  by the framework.

"(...)A framework has a default behavior."

If the name of a framework is confusing (e.g. the .NET Framework), it was likely named before the modern definition gelled.

Compare this to an SDK. An SDK is everything you need to build a specific type of software deliverable for a specific platform -- the Java SDK (all Java apps), the Android SDK (apps that run on the Android OS), the Windows device driver SDK (device driver for Windows), Google App engine SDK (apps that run on Google's App Engine), etc.


问:
How do constructor parameters of a MVC Controller get set?
How does construction work with dependency injection?

With the following code:

```<code>public class AdvancedSearchController : Controller
{
    private EmployeeController _employeeController;

    public AdvancedSearchController(EmployeeController employeeController)
    {
        _employeeController = employeeController;
    }
</code>```

When and how does the employeeController in the code above get set or passed into the constructor? How does this magic happen?

答:
There's no magic unless you consider dependency injection magic. If you dig around in that app's start-up/bootstrap code, you'll almost certainly find an IoC container. Look in Global.asax.cs and follow the paths from your application start event handler. You'll find component/service registration in there somewhere. Sometimes it's right in the Global.asax, sometimes it's stored in App_Start, sometimes it's in the root, and sometimes it's elsewhere. It's there, though.

The latest versions of ASP.NET ship with built-in dependency injection. The latest versions of MVC put it to use.

If you're using an older framework, there are many third-party containers. A few examples:

Unity

Autofac (my current favorite)

Ninject

The principle is simple. You register some concrete type as the active representation of a contract. (The contract is usually an interface, but could also be a concrete type.) Then in code, you always refer to things as contracts. The container gives you the registered type, but you don't have to think about the details. This makes it easy to swap out implementations in one and only one place. Which in turn makes it easy to do things like test pieces of code using predictable mock objects versus using unpredictable, complex objects. Complex objects make it difficult to understand what you're really testing.

In addition to registering types as contracts, IoC containers also do fancy things like automatically inject types into managed components. That's what you're seeing in your example. The container is managing your controllers, so it knows to provide an EmployeeController to your AdvancedSearchController. Who knows? Maybe it injected some other type into the EmployeeController before it passed it on. (You didn't ask, but I'm not crazy about passing controllers around. If you have any say in the matter, ditch it. Replace it with some non-controller that does the needed work. Controllers should only knit models to views. )

Some containers also let you decide the lifetime of your registered types -- maybe they're instantiated each time they're used, maybe an object sticks around for the duration of a web request (slick for managing a unit-of-work in a web service), or maybe there's only ever just one.


问:
"Untriggered events" in Reactive Programming
The premise is that you have a Stream - a source of events spread over time.

You can connect to Stream and create a logical chain that will fire when a new event is emitted:

```<code>var button = document.querySelector('#button');
var clickStream = Rx.Observable.fromEvent(button, 'click');

clickStream
    .map(...)
    .subscribe(...)
</code>```

You define a potential change in your system and connect a reaction chain to it.

What I am trying to fit within this relatively straightforward paradigm is initial data loading (or any other "untriggered" logical chain) - where you want to load some initial data "upfront", upon creation of the corresponding component, perhaps.

It seems to me that, at least in Rx, the paradigm is to have something similar to:

```<code>var source = Rx.Observable.just(somePerhapsAsyncDataSource);
var subscription = source.subscribe(...);
</code>```

So, as far as I can tell, it's an "immediately invoked observable" (within event loop constraints, naturally), which feels a bit forced.

Is this the commonly accepted paradigm for "untriggered"/initial loading of data or any other activity?

Other solutions involve abominations like synthetic observables (where you have a shouldLoadData property on some EventEmitter or similar, with the load chain attached, and set it to true when the component is created). Awful.

答:
Disclaimer: I'm an rx/FRP noob, and my answer comes from consuming rx knowledge much more than producing rx solutions.  Since this question has considerably less than a flood of responses, then I'll chime in :)

Quick answer: yes, from what I understand, "kickstarting" a sequence by having the initial rx value be the result of a subscription is a pattern, and rx's "cold observables" support this usecase.

Longer ramblings:

I come from a java SE / server background, but I've been working with RxSwift on ios recently.
I think I see what you mean by "forced" -- if you'll let me paraphrase, you're thinking "hey I want rx for pure streams and why should a pure stream be sullied by kickstarting a blocking op on initial subscription?"

In my iOS group's production code, I see network programming using Observable<T> to provide .Next(T) responses.  More particularly, I see clients which bootstrap the 0th net-blocking call to get their first .Next(T), etc.  Although this looks "forced" from the server (observable-emitter's) view, the flipside client-view makes sense to me, abstractly -- as a client, I want T's and I don't/shouldn't care about marshalling the resources to get my first T.  As I client, I assume a ladder :)

This "reactive streams in Rx" YT helped me with concepts.  Specific to your question:

https://www.youtube.com/watch?v=g-ixzOcMDF4&t=210  [observable - multiple & async]

https://www.youtube.com/watch?v=g-ixzOcMDF4&t=294  [cold, for blocking access eg filesystem]

pull quotes:

"futures are a pretty effective way of handling single responses".

"you can always handle a single value if you're capable of handling multiple values" (obvious yet true)

As for shouldLoadData hoop-jumping yeah, I just saw some production code yesterday that did this.  It sure seems wrong, but hey -- here we are :)

Good luck.


问:
Should you charge clients hours spent on the wrong track?
I took up a small CSS challenge to solve for a client and I'm going to be paid on a hourly rate.
I eventually solved it, it took 5 hours but I spent roughly 25% of the time in the wrong track, trying a CSS3 solution that only worked in recent browsers and finally discovering that no fallback is possible via JS (like I originally thought). Should I charge the client that 25%?

More details:
I didn't provide an estimate, I liked the challenge per se, so I started working on it before giving an estimate (but I have worked with him before, so I know he's not one of those people that have unrealistic expectations). At the very worst I will have spent 5 unpaid hours on an intriguing CSS challenge. And I will give the fairest possible estimate for both of us, since I will have already done the work. :)

Edit:
Thank you all, I wish I could accept more than one answer! I ended up not billing him for the extra hours (I billed him for 3 and a half), but I mentioned them, so that he knows I worked more on it than I billed him for. Maybe that's why he immediately accepted the "estimate" (which in that case wasn't an estimate, hence the quotes).

答:
I look at it this way: at the end of the day, it's your call what you charge. There are many variables like how happy you want the client, the existing relationship, your sales skills, etc... we're all familiar with them. What you're ultimately providing the client, and what they really want, is value. What value did you give the client and what's the solution/deliverable you're providing worth to them?

It may take you 10 minutes to solve a problem, but it took you 10 years to learn how to solve that problem. That deserves to be considered. At the same time, some of us consider the ability to learn "on the job" compensation. I often learn things, that really are on the client's dime I consider that a form of non-monetary compensation.

You can also add it to the bill, then mark it as a "preferred customer discount" on the invoice, don't charge and build some good will. I do that every now and then, which makes the client feel good.

Also, your question of if there are developers that are making thousands of dollars a day, the answer is yes. You should be one of them, too with your skills. I'm practically there, and I'm nowhere close to being in the same league with you in CSS.

ContentLicense: CC BY-SA 2.5


问:
Strategy Pattern Implementation
I have to generate a code that will send through SMS or Email to implement the One Time Password (OTP) requirement of our client.

I just finished creating the design using strategy pattern, .
.

This it the first time I've used strategy pattern in real life projects so I would like to ask if I'm doing it right.

Below is just a sample code that will be used by client.

```<code> //OTPGeneratorStrategy generatorStrategy = new EmailGeneratorStrategy("test@gmail.com"); for sending to Email for example
OTPGeneratorStrategy generatorStrategy = new SmsGeneratorStrategy(993454454545);
OTPGeneratorContextgeneratorContext = new OTPGeneratorContext(generatorStrategy);
context.generate("1-12345-0");

OTPValidatorStrategy validatorStrategy = new SmsValidatorStrategy();
OTPValidatorContext validatorContext = new OTPValidatorContext (validatorStrategy );
try {
validatorContext.validate("1-12345-0","e7241f");
} catch (InvalidVerificationKeyException ivk) {
System.out.println("Verification key is invalid!");
} catch(VerificationKeyExpiredException vke) {
System.out.println("Verification key is already expired, Please regenerate");
}
</code>```

Updated:

Thank you for the feedback, actually I was not able to update my latest UML design and already separated the generation and validation.

And the reason why I've used Exception rather than enums because the project was built in java 1.4.

答:
As a former, but now somewhat reformed object-oriented programming enthusiast I have to say - be careful with design patterns. This feels like classic "kingdom of nouns" OOP overdesign (check out Steve Yegge's classic blog post on the subject: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html ).

I'd highly recommend trying a simple, procedural implementation of this, in addition to what you're considering - e.g. a simple static method that takes boolean or enum flag for SMS/email, in addition to the other inputs, and follows a simple linear flow of logic, using plain ol' if statements for steps that differ between SMS/email etc.

You may find that the strategy pattern leads to the simplest, most compact, easiest to maintain code in the end, but it definitely pays to try a few design approaches. The more code I've written and read over the years the more I've seen how OOP "best practices" can needlessly overcomplicate things.

Title: Strategy Pattern Implementation


问:
Is declarative programming overrated?
I've been programming for years with primarily-imperative languages (C++, C#, javascript, python), but have recently experimented with some functional langauges (Lisp, Haskell) and was excited to try applying some of the declarative-style programming ideas in C++. I have a custom range-based STL replacement library I wrote a while back that made a lot of that possible in a fairly clean way.

Here's an example - a function to see if a target substring exists inside of a source string, ignoring case. First the plain-ol' imperative way:

```<code>bool StringContains(const string& source, const string& target) {

    // Figure out search area, exit if target is too big to exist in source
    if (target.size() > source.size()) {
        return false;
    }
    size_t endIndex = source.size() - target.size();

    // For each potential position...
    for (size_t i = 0; i <= endIndex; i++) {

        // Check if target is here
        size_t strPos = i;
        bool foundHere = true;
        for (char targetChar : target) {
            char strChar = tolower(source[strPos]);
            targetChar = tolower(targetChar);
            if (strChar != targetChar) {
                foundHere = false;
                break;
            }
            strPos++;
        }

        // If found here, return true
        if (foundHere) {
            return true;
        }
    }

    // If not found by now, return false
    return false;
}
</code>```

And here it is using my declarative library (which use some C++11 magic):

```<code>bool StringContainsDec(const string& source, const string& target) {

    // Figure out search area, exit if target is too big to exist in source
    if (target.size() > source.size()) {
        return false;
    }
    size_t endIndex = source.size() - target.size();

    // For each potential position...
    auto targetRange = All(target) | Transformed(tolower);
    for (size_t i = 0; i <= endIndex; i++) {

        // If found here, return true
        auto sourceRange = All(source) | Sliced(i, i + target.size()) |
            Transformed(tolower);
        if (RangesMatch(sourceRange, targetRange)) {
            return true;
        }
    }

    // If not found by now, return false
    return false;
}
</code>```

A little more compact and perhaps English-like and readable, which is nice. The "|" is analogous to a shell script pipe, routing values thru to the next operation. So:

```<code>All(source) | Sliced(i, i + target.size()) | Transformed(tolower)
</code>```

means, set up a range that, when iterated, will take each character of 'source', sliced between index i and i + target.size(), and pass each character through tolower().

RangesMatch() iterates each of the two ranges and returns true if each element matches.

So, that's all fine and good, and it works correctly. But over time I've found, experimenting with this approach in practical situations:

The declarative code is harder to debug. With the imperative, you can just step through in the debugger, line by line, and see what's going on. With the declarative, it's not that much more complex, but you need to jump through some different library functions of constructing the range, calling the internal iterator functions (Front(), PopFront(), etc.) etc. So it jumps you around from place to place, making it more confusing to track the logic. I imagine this is easier in e.g. a Lisp debugger.

The declarative code is a bit slower. On my system it's about half the speed of the imperative code. The ranges are lazily constructed and very efficient, and only allocate locals on the stack, but it still involves a little more under the hood, like tracking start/end pointers, which adds up in nested loops etc. With declarative it seems like you can easily lose touch with what your code is actually doing. If you have a huge chain of operations you'll miss opportunities to simplify, save useful intermediate values so they don't need to be recalculated later, etc.

The declarative code is harder to modify over time, I find. If I want to do some extra operation on each character, I need to add another transform function, or lambda etc. In imperative programming I just add a line of plain ol' code inside the loop, or 100 lines if needed, and it's fairly easy to follow.

I find the imperative style more intuitive as I'm writing. It better reflects the order that things happen, let's me proceed step by step without having to juggle the whole thing in my head up front, etc.

Now all this stuff might be particular to my implementation or my preferences, but I imagine some of it is inherent to the style too? This string function is just one example but I've found it with all kinds of things when I implement both side by side - that 80% of the time imperative style wins for me, just do it with plain old loops and if statements rather than messing around with higher-order functions, map/reduce, etc. They may add some code brevity and a little less typing if your text editor sucks, but in complicated real-world situations they become confusing and harder to maintain.

So is declarative overrated? Has anyone had broad experience with both approaches, especially with complex real-world projects in functional languages? Curious to hear what other people think.

答:
IMHO declarative programming is very ambiguous.

In particular, it had different meaning in different countries (in France it is not the same as in the US) and in different times (before or after AI winters).

My understanding of it is that of Jacques Pitrat who speaks more wisely of declarative knowledge:

we give knowledge in a declarative form, which does not include how to use it.

In a certain way, declarative programming is a contradiction in terms; programming could be viewed as configuring computers on how to do things, but declarative means that the system should find itself on how to do things, and we declare only what we want it to do, not how to do it.

Once we have a system understanding declarative knowledge, "programming" it should be quite easy: we give separately a lot of declarative knowledge (including declarative metaknowledge about how to compile and use declarative knowledge) and some objectives and goals. This is also a dream of some AGI system, and J.Pitrat has written a lot on theses.

And programming might be extended to the notion of writing source code: the developer writes some formalization understood by some system. That source code is the preferred formalization for the developer (this is the definition of source code for free software enthusiasts).

Actually, there is a continuous spectrum between declarative and procedural knowledge....

So IMHO functional programming is not exactly declarative programming, but indeed functional languages are more declarative than procedural ones. Also, declarative systems are not overrated, but you need some dozen of years to develop them (read the mythical man month)

For a practical short term view, declarative programming may simply mean to favor data (including "declarative" configuration data giving some "goals") over code.

Read also about expert systems.

PS. I strongly recommend reading J.Pitrat's blog and books. He devoted his entire life to declarative knowledge. See also RefPerSys.

Title: Is declarative programming overrated?