答:
From what you describe at a basic level, you are:

Pulling data from some persistent storage

Parsing it into some sort of generic format

Mapping it to objects and properties

The Repository Pattern solves this problem. It involves three main types of classes:

The "Repository" class, which just deals with your object model, e.g. your "entity classes" or "domain model" in your application. It can provide both read and write access for this data

The "Gateway" class, which is responsible for reading and writing data to a persistent storage, be it a database, web service or file. As we will see later, this is where file parsing should exist.

The "Factory" class, which creates instances of your Domain Model and maps data from the generic data the Gateway returns to your Domain Model.

They key to this pattern is implementing interfaces for each type of class. Let's examine how a blog might be modeled and persisted in this manner.

Repository Pattern Domain Model and Interfaces

Let's start out with the Domain Model:

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
}
```

<p>Nothing too fancy. Next, we need to define our interfaces, first by defining the interface for the blog repository.</p>

<pre class="lang-cs prettyprint-override"><code>public interface IBlogRepository
{
    Blog Find(int id);
    void Create(Blog blog);
    void Update(Blog blog);
    void Delete(Blog blog);
}
</code>```

The IBlogRepository interface is focused mainly on your Domain Model with no mention of how persistence is actually achieved. This provides a layer of decoupling for the rest of your application.

Next, the blog gateway interface allows the repository to preform specific CRUD operations (Create, Read, Update, Delete) on your data store.

public interface IBlogGateway
{
    IList<IDictionary<string, object>> Load();
    void Create(int id, string name, string description);
    void Update(int id, string name, string description);
    void Delete(int id);
}
```

<p>It's best to keep the "gateway" devoid of any knowledge about your Domain Model, as this will provide maximum flexibility to change your domain model with limited affect on the "gateway", and to change your "gateway" with limited affect on your domain model.</p>

<p>The <code>Load</code> method just returns a list of dictionary objects, a nice, generic format for the data.</p>

<p>The last interface is the blog factory object responsible for creating instances of your Domain Model and mapping your generic data to the <code>Blog</code> objects.</p>

<pre class="lang-cs prettyprint-override"><code>public interface IBlogFactory
{
    Blog CreateInstance(IDictionary<string, object> data);
    void UpdateInstance(IDictionary<string, object> data, Blog instance);
}
</code>```

Repository Pattern Concrete Classes

Now that we have our interfaces defined, let's start by creating a BlogRepository class that implements the IBlogRepository interface:

public class BlogRepository : IBlogRepository
{
    private IBlogGateway gateway;
    private IBlogFactory factory;
    private IList<Blog> cache;

    private IList<Blog> Cache
    {
        get
        {
            if (cache == null)
            {
                var data = gateway.Load();

                cache = new List<Blog>();

                foreach (var record in data)
                {
                    cache.Add(factory.CreateInstance(record));
                }
            }

            return cache;
        }
    }

    public BlogRepository(IBlogGateway gateway = null, IBlogFactory factory = null)
    {
        this.gateway = gateway ?? new BlogFileGateway(@"C:\Path\To\Blogs.txt");
        this.factory = factory ?? new BlogFactory();
    }

    public Blog Find(int id)
    {
        Cache.SingleOrDefault(b => b.Id == id);
    }

    public void Create(Blog blog)
    {
        Cache.Add(blog);
        gateway.Create(blog.Id, blog.Name, blog.Description);
    }

    public void Update(Blog blog)
    {
        gateway.Update(blog.Id, blog.Name, blog.Description);
    }

    public void Delete(Blog blog)
    {
        Cache.RemoveAll(b => b.Id == blog.Id);
        gateway.Delete(blog.Id);
    }
}
```

<p>Now we can start to see how each piece fits together. The constructor for <code>BlogRepository</code> allows you to pass in your own gateway and factory object, falling back to a default implementation of your choosing.</p>

<p>To find a single <code>Blog</code> the repository first loads all the data from the gateway, and maps it to objects using the factory. The <code>Find</code> method then returns the first Blog that matches the Id. Admittedly you might want to create a method on the "gateway" object to return a single record, but the repository is also a good place to implement caching.</p>

<p>Now we get into the part you are interested in: parsing the file.</p>

<pre class="lang-cs prettyprint-override"><code>public class BlogFileGateway : IBlogGateway
{
    private string filePath;

    public BlogFileGateway(string filePath)
    {
        this.filePath = filePath;
    }

    public IList<IDictionary<string, object>> Load()
    {
        // Read entire file and return the parsed data
    }

    public void Create(int id, string name, string description)
    {
        // Append the new data to the file
    }

    public void Update(int id, string name, string description)
    {
        // Update the correct row within the file
    }

    public void Delete(int id)
    {
        // Delete the correct row within the file
    }
}
</code>```

The BlogFileGateway implements the IBlogGateway interface. This is where you open, read and parse the file. If you have a generic file format, your "gateway" classes could create an instance of another class responsible for parsing each record in the file.

And just for good measure, the blog factory class:

public class BlogFactory : IBlogFactory
{
    public Blog CreateInstance(IDictionary<string, object> data)
    {
        if (data == null)
            return null;

        Blog instance = new Blog();

        UpdateInstance(data, instance);

        return blog;
    }

    public void UpdateInstance(IDictionary<string, object> data, Blog instance)
    {
        instance.Id = int.Parse(data["id"].ToString());
        instance.Name = data["name"].ToString();
        instance.Description = data["description"].ToString();
    }
}
```

<h2>Why the Repository Pattern Works Best</h2>

<p>Since you decouple the data access and mapping from your domain model, you are free to start out with file storage. Moving to database storage would involve writing a new gateway class to access the database, and a new factory class to map the data from the database to your <code>Blog</code> Domain Model. If later on you decide to move to a Service Oriented Architecture, you need only write another gateway to call the web service, and another factory. You can radically change or switch out storage mechanisms without refactoring major parts of your application.</p>

<p>@BartVanIngenSchenau said in his answer:</p>

<blockquote>
  <p>For other kinds of data access (data exchange with third parties, reading/writing files, etc.) <strong>those architectures have the concept of Services to perform the transportation of the data</strong> and to transform it between the external format and something that the business layer can work with.</p>
</blockquote>

<p>(emphasis mine)</p>

<p>The advantage of using the Repository Pattern is that the code calling a web service doesn't have to live in the generic, and often overused layer of your application called "services". Calling the web service happens in the gateway.</p>

<h3>Example Usage</h3>

<p>Let's find a blog, change a value and update it:</p>

<pre class="lang-cs prettyprint-override"><code>IBlogRepository repository = new BlogRepository();

Blog blog = repository.Find(3);

blog.Description = "Black and white, and read all over";

repository.Update(blog);
</code>```

Later on, you need to use a MySQL database so you write the BlogMySqlGateway and BlogMySqlFactory classes, then change one line of code:

IBlogRepository repository = new BlogRepository(new BlogMySqlGateway(), new BlogMySqlFactory());

Blog blog = repository.Find(3);

blog.Description = "Black and white, and read all over";

repository.Update(blog);
```

<p>Nothing else has to change. Later on, you decide this all needs to live in "The Cloud":</p>

<pre class="lang-cs prettyprint-override"><code>IBlogRepository repository = new BlogRepository(new BlogWebServiceGateway(), new BlogWebServiceFactory());

Blog blog = repository.Find(3);

blog.Description = "Black and white, and read all over";

repository.Update(blog);
</code>```

Nothing else has to change.

Body:
From what you describe at a basic level, you are:

Pulling data from some persistent storage

Parsing it into some sort of generic format

Mapping it to objects and properties

The Repository Pattern solves this problem. It involves three main types of classes:

The "Repository" class, which just deals with your object model, e.g. your "entity classes" or "domain model" in your application. It can provide both read and write access for this data

The "Gateway" class, which is responsible for reading and writing data to a persistent storage, be it a database, web service or file. As we will see later, this is where file parsing should exist.

The "Factory" class, which creates instances of your Domain Model and maps data from the generic data the Gateway returns to your Domain Model.

They key to this pattern is implementing interfaces for each type of class. Let's examine how a blog might be modeled and persisted in this manner.

Repository Pattern Domain Model and Interfaces

Let's start out with the Domain Model:

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
}

Nothing too fancy. Next, we need to define our interfaces, first by defining the interface for the blog repository.

public interface IBlogRepository
{
    Blog Find(int id);
    void Create(Blog blog);
    void Update(Blog blog);
    void Delete(Blog blog);
}

The IBlogRepository interface is focused mainly on your Domain Model with no mention of how persistence is actually achieved. This provides a layer of decoupling for the rest of your application.

Next, the blog gateway interface allows the repository to preform specific CRUD operations (Create, Read, Update, Delete) on your data store.

public interface IBlogGateway
{
    IList<IDictionary<string, object>> Load();
    void Create(int id, string name, string description);
    void Update(int id, string name, string description);
    void Delete(int id);
}

It's best to keep the "gateway" devoid of any knowledge about your Domain Model, as this will provide maximum flexibility to change your domain model with limited affect on the "gateway", and to change your "gateway" with limited affect on your domain model.

The Load method just returns a list of dictionary objects, a nice, generic format for the data.

The last interface is the blog factory object responsible for creating instances of your Domain Model and mapping your generic data to the Blog objects.

public interface IBlogFactory
{
    Blog CreateInstance(IDictionary<string, object> data);
    void UpdateInstance(IDictionary<string, object> data, Blog instance);
}

Repository Pattern Concrete Classes

Now that we have our interfaces defined, let's start by creating a BlogRepository class that implements the IBlogRepository interface:

public class BlogRepository : IBlogRepository
{
    private IBlogGateway gateway;
    private IBlogFactory factory;
    private IList<Blog> cache;

    private IList<Blog> Cache
    {
        get
        {
            if (cache == null)
            {
                var data = gateway.Load();

                cache = new List<Blog>();

                foreach (var record in data)
                {
                    cache.Add(factory.CreateInstance(record));
                }
            }

            return cache;
        }
    }

    public BlogRepository(IBlogGateway gateway = null, IBlogFactory factory = null)
    {
        this.gateway = gateway ?? new BlogFileGateway(@"C:\Path\To\Blogs.txt");
        this.factory = factory ?? new BlogFactory();
    }

    public Blog Find(int id)
    {
        Cache.SingleOrDefault(b => b.Id == id);
    }

    public void Create(Blog blog)
    {
        Cache.Add(blog);
        gateway.Create(blog.Id, blog.Name, blog.Description);
    }

    public void Update(Blog blog)
    {
        gateway.Update(blog.Id, blog.Name, blog.Description);
    }

    public void Delete(Blog blog)
    {
        Cache.RemoveAll(b => b.Id == blog.Id);
        gateway.Delete(blog.Id);
    }
}

Now we can start to see how each piece fits together. The constructor for BlogRepository allows you to pass in your own gateway and factory object, falling back to a default implementation of your choosing.

To find a single Blog the repository first loads all the data from the gateway, and maps it to objects using the factory. The Find method then returns the first Blog that matches the Id. Admittedly you might want to create a method on the "gateway" object to return a single record, but the repository is also a good place to implement caching.

Now we get into the part you are interested in: parsing the file.

public class BlogFileGateway : IBlogGateway
{
    private string filePath;

    public BlogFileGateway(string filePath)
    {
        this.filePath = filePath;
    }

    public IList<IDictionary<string, object>> Load()
    {
        // Read entire file and return the parsed data
    }

    public void Create(int id, string name, string description)
    {
        // Append the new data to the file
    }

    public void Update(int id, string name, string description)
    {
        // Update the correct row within the file
    }

    public void Delete(int id)
    {
        // Delete the correct row within the file
    }
}

The BlogFileGateway implements the IBlogGateway interface. This is where you open, read and parse the file. If you have a generic file format, your "gateway" classes could create an instance of another class responsible for parsing each record in the file.

And just for good measure, the blog factory class:

public class BlogFactory : IBlogFactory
{
    public Blog CreateInstance(IDictionary<string, object> data)
    {
        if (data == null)
            return null;

        Blog instance = new Blog();

        UpdateInstance(data, instance);

        return blog;
    }

    public void UpdateInstance(IDictionary<string, object> data, Blog instance)
    {
        instance.Id = int.Parse(data["id"].ToString());
        instance.Name = data["name"].ToString();
        instance.Description = data["description"].ToString();
    }
}

Why the Repository Pattern Works Best

Since you decouple the data access and mapping from your domain model, you are free to start out with file storage. Moving to database storage would involve writing a new gateway class to access the database, and a new factory class to map the data from the database to your Blog Domain Model. If later on you decide to move to a Service Oriented Architecture, you need only write another gateway to call the web service, and another factory. You can radically change or switch out storage mechanisms without refactoring major parts of your application.

@BartVanIngenSchenau said in his answer:

For other kinds of data access (data exchange with third parties, reading/writing files, etc.) those architectures have the concept of Services to perform the transportation of the data and to transform it between the external format and something that the business layer can work with.

(emphasis mine)

The advantage of using the Repository Pattern is that the code calling a web service doesn't have to live in the generic, and often overused layer of your application called "services". Calling the web service happens in the gateway.

Example Usage

Let's find a blog, change a value and update it:

IBlogRepository repository = new BlogRepository();

Blog blog = repository.Find(3);

blog.Description = "Black and white, and read all over";

repository.Update(blog);

Later on, you need to use a MySQL database so you write the BlogMySqlGateway and BlogMySqlFactory classes, then change one line of code:

IBlogRepository repository = new BlogRepository(new BlogMySqlGateway(), new BlogMySqlFactory());

Blog blog = repository.Find(3);

blog.Description = "Black and white, and read all over";

repository.Update(blog);

Nothing else has to change. Later on, you decide this all needs to live in "The Cloud":

IBlogRepository repository = new BlogRepository(new BlogWebServiceGateway(), new BlogWebServiceFactory());

Blog blog = repository.Find(3);

blog.Description = "Black and white, and read all over";

repository.Update(blog);

Nothing else has to change.


问:
In which layer I should implement file parsing?
in a simple multi layer architecture, in which layer do I have to implement something like parsing file.
For example: I have a file and I have to extract specific information into an object.
I think that this stuff is data access, because the business layer need data. How and where the data come from is not the point. do you agree? </p>

答:
Simply put, you would implement your parsing needs as a layer-independent module or library. You'd use this library in the layer that needs it.

The implementation should accept and work with a device-independent stream (abstract/base or interface), or a string (if the input data is not expected to be too large, otherwise you might run into scalability issues later on).

And about the layer, yes in your case it sounds the functionality would be applied in data access. But that doesn't always have to be the case. It also often happens that you'll need such parsing functionality in the UI layer where user inputs or uploads data, before you're able to populate the business objects and store them in the database in the format that it is required.

ContentLicense: CC BY-SA 3.0


问:
Minimal design vs anticipated use
Recently when performing a code review I came across something like this:

Old Code:

```<code> WriteLabour(useNewVersion);
 WritePart();
 WriteNonLabour(useNewVersion);
</code>```

New Code:

```<code>WriteLabour();
WritePart(useNewVersion);
WriteNonLabour();
</code>```

Now let me give you some background. This is very old code, not very object-oriented. There are always two versions of the file, the current version and the previous version. The useNewVersion flag determines if the current or previous version is to be written. The file is for a customer to consume and when they come up with a new version, they send us the new spec, we change the code to output the file as per new spec and this becomes the new version. What used to be the new version now becomes the previous version, ability to write version even previous to that is thrown away forever (that code is deleted).

The programmer was updating the code for the new spec just received. He found after deleting code for the version to be forgotten that WriteLabour() and WriteNonLabour() no longer had any version specific code, while WriteParts() now had to have version specific code. So he changed the method signatures as I have indicated above.

My suggestion in the code review was that it would be nice to keep method signatures consistent and always supply the useNewVersion flag, even if the code within the method did not use the flag. To me this made intuitive sense, because it is very likely that future versions of the file will require the flag to be passed in again and the interface for the caller would remain consistent. His argument against my suggestion was that passing the useNewVersion flag to methods that did not need it was design bloat. Who knows what other parameters the methods might need, should we pass them all in anticipation?

My gut feeling was that his argument was flawed in this particular case, but I could not counter it effectively. My question then is if there are design decisions we know are coming or by past experience, is it wrong to incorporate them into the current design even though they may be presently unused? Specifically in terms of public interfaces, method signatures etc, not private code.

But keeping code lean and not over designing is important too. Don't want to be the architecture astronaut.

Polite note: Please don't derail the topic by suggesting re-factorings for the code. This is not supposed to be a critique of the design of our legacy code. That code isn't up to standards, and I know that.

答:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Antoine de Saint-Exupery

If you clutter code with unused parameters, other people reading it later will waste time trying to work out why they're there. Did you mean to put them there? Forget to remove them? Is there a bug due to missing code? They create noise that hides the real information in the code. This makes that code more difficult to read and makes people more nervous of breaking things when they change it.

Further, many modern compilers will flag unused parameters and variables as warnings. Good practice says that all warnings should be treated as errors. In this context, unused parameters are a compiler error and therefore need removing.

TL;DR: don't put unused parameters into your code "just in case I need them later".

Title: Minimal design vs anticipated use


问:
How can I be quicker at resolving application performance problems
While I subscribe to and usually work in agile workplaces and I believe have reasonable standards, I often find performance problems difficult in the 'heat of battle', and may put off or not get started on as quickly as standard features.

Despite building on general performance knowledge for some time, I'd like to know what I can do to start fixing and arrive at performance related solutions sooner.

答:
Your overall strategy during initial development should be to understand algorithms and data structures well enough to avoid writing code that is going to perform poorly by design.

For example, a triply nested loop with 100 iterations in each level may seem benign, but that's 1 million total iterations, and if anything is happening in that inner loop that takes any significant amount of time, then there's going to be a performance problem.

Choose your data structures wisely.  If you need O(n log n) lookup, then an ordinary linked list isn't going to cut it.

Always measure first.  Software developers are notoriously bad at telling how well code is going to perform just by looking at it.

Only optimize when you're going to get a significant gain in performance.  Where this happens isn't always going to be obvious.

Whenever possible, optimize later.  But don't fail to take advantage of those early design decisions that will insure your code performs adequately.

Further Reading

Back to Basics, where Joel Spolsky describes "Schlemiel the Painter Algorithm."


答:
I think what you're dealing with is a collision of a few principles.

On the one hand, you have the principle of least astonishment which would encourage you to keep your method signatures consistent.

On the other hand, YAGNI (you aren't going to need it) tells you to leave it out as it's not necessary.

And those principles have to be weighed against refactoring costs.

It sounds like this legacy code has beaten you into a particular approach for dealing with it.  You've become used to having to specify useNewVersion and numb to the information leakage from that particular design.  To be a bit unfair, what you suggested to your co-worker was "I'm used to being bludgeoned over the head and having to figure out which version I should be calling.  Let's not change our ways because I'm used to being hit."

And your co-workers response was to the effect of "Look, see, we don't have to get smacked all the time anymore!"  Regrettably, he re-implemented that same bludgeoning approach with a different method so he doesn't get full credit in this case.

What should you do?  I don't believe you should be specifying useNewVersion as a function parameter.  It's a poor design and it forces the developer to be thinking about things he shouldn't have to worry about.  I believe in treating functions like they are contracts.  "If you call this method, it will do XYZ.  You don't have to care about how it does XYZ, it will take care of that for you."

So WriteLabour() and WriteNonLabour() shouldn't have useNewVersion parameters.

Title: Minimal design vs anticipated use

Body:
Recently when performing a code review I came across something like this:

Old Code:

```<code> WriteLabour(useNewVersion);
 WritePart();
 WriteNonLabour(useNewVersion);
</code>```

New Code:

```<code>WriteLabour();
WritePart(useNewVersion);
WriteNonLabour();
</code>```

Now let me give you some background. This is very old code, not very object-oriented. There are always two versions of the file, the current version and the previous version. The useNewVersion flag determines if the current or previous version is to be written. The file is for a customer to consume and when they come up with a new version, they send us the new spec, we change the code to output the file as per new spec and this becomes the new version. What used to be the new version now becomes the previous version, ability to write version even previous to that is thrown away forever (that code is deleted).

The programmer was updating the code for the new spec just received. He found after deleting code for the version to be forgotten that WriteLabour() and WriteNonLabour() no longer had any version specific code, while WriteParts() now had to have version specific code. So he changed the method signatures as I have indicated above.

My suggestion in the code review was that it would be nice to keep method signatures consistent and always supply the useNewVersion flag, even if the code within the method did not use the flag. To me this made intuitive sense, because it is very likely that future versions of the file will require the flag to be passed in again and the interface for the caller would remain consistent. His argument against my suggestion was that passing the useNewVersion flag to methods that did not need it was design bloat. Who knows what other parameters the methods might need, should we pass them all in anticipation?

My gut feeling was that his argument was flawed in this particular case, but I could not counter it effectively. My question then is if there are design decisions we know are coming or by past experience, is it wrong to incorporate them into the current design even though they may be presently unused? Specifically in terms of public interfaces, method signatures etc, not private code.

But keeping code lean and not over designing is important too. Don't want to be the architecture astronaut.

Polite note: Please don't derail the topic by suggesting re-factorings for the code. This is not supposed to be a critique of the design of our legacy code. That code isn't up to standards, and I know that.


问:
Why does "charset" really mean "encoding" in common usage?
Something that has long confused me is that so much software uses the terms "charset" and "encoding" as synonyms.

When people refer to a unicode "encoding", they always mean a ruleset for representing unicode characters as a sequence of bytes - like ASCII, or UTF-8. This seems reasonable and intuitive; the idea is that you are "encoding" those characters as bytes using the specified ruleset.

Since those rulesets sometimes only provide the ability to "encode" some subset of all unicode characters, you might imagine that a "charset" - short for 'set of characters' - would simply mean a set of unicode characters - without any regard for how those characters are encoded. An encoding would thus imply a charset (an encoding like ASCII, which only has rules for encoding 128 characters, would be associated with the charset of those 128 characters) but a charset need not imply an encoding (for example, UTF-8, UTF-16 and UTF-32 are all different encodings but can encode the same set of characters).

Yet - and here is the crux of my question - real-world usage of the word "charset" does not match what the construction of the word would imply. It is almost always used to mean "encoding".

For example:

The charset attribute in HTML is used to specify an encoding

Charsets in Java are encodings

charsets and character sets in MySQL are, once again, encodings

How old is this curious (ab)use of language, and how did this counter-intuitive definition of 'charset' come to exist? Does it perhaps originate from a time when there truly was, in practice, a one-to-one mapping between encodings in use and sets of characters they supported? Or was there some particularly influential standard or specification that dictated this definition of the word?

答:
The concept of character sets is older than Unicode.

Before Unicode, a character set defined a set of characters and how each character was represented as bits. Most character sets mapped a character to a byte (which allowed a set of 256 characters), some mapped to two bytes, and a few (like ASCII) to only 7 bits. Different character sets often assigned different values to the same character, and there was no universal translation key between the various character sets in use.

Unicode was an attempt to solve this problem by unifying all the various character sets in a common "superset". For this purpose Unicode introduced some additional levels of abstraction, for example the concept of character encodings as something separate from the code point values. This allowed Unicode to redefine the pre-unicode character sets as unicode character encodings.

The charset attribute in HTML (which mirrors the charset parameter in the HTTP content-type header) for example, is from before unicode was widely adopted, but when it was decided to accept unicode as the universal character set of the internet, the charset attribute was just redefined to specify the encoding in use, but the name wasn't changed to allows backwards compatibility.


问:
Call by value for classes c++ design decision
I wonder why C++ uses 'call by value' for classes as default? I imagine this could have advantages in the sense of performance (speed). I mean C# and Java pass classes as references as default.

What are the reasons why C++ pass classes as copies as default?

答:
By far the most important reason why it is done this way is for consistency.

This is how everything else is passed, so why not structs and classes too?

One major justification for sticking with this consistency is that in C and C++ you have to always be mindful of indirections, (and how many of them a given variable represents,) so the general approach taken by the language is to avoid hiding indirections from the programmer. This way, everything which is not adorned with a '&' is passed by value, unless the function itself declares the argument to be a reference, in which case you do not need to supply the '&' when you are calling, and instead you have to remember that there is a '&' in the receiving end.  (But you have made this choice, so you have brought this additional mental burden upon yourself.)

Another justification is that if structs and classes were to be an exception to the rule of passing everything by value, then the language would still have to give you a way to specify that you do in fact want an occasional struct/class to be passed by value, and then what ugly modifications would the syntax of the language have to undergo in order to facilitate this?  The language already has syntax for taking a reference of something, but not for passing the value of something.

Please note: my C++ might be a bit rusty, so I may have made some small mistake or used a somewhat wrong word for something. If you know better, that's entirely possible, but instead of downvoting, please modify the answer to fix that minor mistake.


答:
... if there are design decisions we know are coming or by past
  experience, is it wrong to incorporate them into the current design
  even though they may be presently unused?

Let's bypass the level of predictability of whether or not you'll need the feature. That's a risk you'll just be taking. If we assume the features are going to get added,the question is when are they the easiest to add, now or later. If they're much easier to add now, you may want to reconsider the design, but you indicated that's not the issue.

Now all you have to go by is do you have time now or will you have time later? It sounds like you're anticipating a lot of new features at some point and we all know they'll want them sooner rather than later. Choosing to add them now when you have the time, could mitigate the risk of whether or not you need them at all.

I think is is always easier to add things later, compared to trying to identify unused/unneeded code later on and having to figure-out how to get rid of it. Either have good notes and/or memory. I just don't think it is worth it.

Title: Minimal design vs anticipated use


答:
Stop going rogue. You're making more work for yourself, and you're actually putting your job at risk.

Don't work on performance "problems" that aren't recognized problems. And as a corollary, the business will grant you time during the course of your regular work to address recognized performance problems.

If you believe an application's or feature's current performance isn't sufficient, is impacting other systems, or is a huge factor in high hardware or hosting costs, log it as a bug/request and let the stakeholders and product owner decide when/if you should spend time on it.

If there's a serious performance problem in the scope of a currently assigned task/story that would prevent it from being functional, it's not necessarily a "performance" problem at that point; it's a "the feature isn't usable yet" problem. Do what needs to be done to finish the feature using "best practices."

Anything outside those two reasons is extracurricular. It needs to be done on your time, and you ought to be really darn sure your optimizations don't introduce any bugs.

But, it's really just best to avoid doing work the company doesn't explicitly approve ... lest you have to explain how you were "just trying to learn some stuff" Friday after hours and accidentally lost a bunch of customer data or something.

Title: How can I be quicker at resolving application performance problems

Body:
While I subscribe to and usually work in agile workplaces and I believe have reasonable standards, I often find performance problems difficult in the 'heat of battle', and may put off or not get started on as quickly as standard features.

Despite building on general performance knowledge for some time, I'd like to know what I can do to start fixing and arrive at performance related solutions sooner.


问:
Should UDP data payloads include a CRC?
For a company I used to work for, I had to implement a socket receiver that mostly took data in UDP form over a local connection from some specialized sensor hardware. The data in question was a well-formed UDP packet, but interestingly, the data payload always ended with a CRC16 checksum formed using the rest of the data.

I implemented the check on my end, as per the spec, but I always wondered if this was necessary. After all, doesn't the UDP protocol itself carry a 16-bit CRC? Therefore, although UDP packets can be lost or out-of-order, I was under the impression that they can not be corrupted without being discarded by the network hardware before they reach the OS's processes. Or is there some special use-case I'm missing?

It's worth adding that I was working in the defence industry, which as I'm sure you can imagine, likes to be super-explicit about everything like this, so I'm wondering whether it was just a case of "security OCD"...

答:
UDP does provide a checksum, however.

The UDP checksum is only 16 bits. That means a 1 in 65536 chance of a corrupt packet passing the checksum.

in UDP over IPv4 the checksum is  optional, so a sender could theoretically end up sending a packet without a checksum.

The checksum covers the IP/port information as well as the data. While this is useful in dropping packets with corrupt addresses it means that if the packet passes through a NAT the checksum must be recalculated by the NAT.

The checksum only protects the data while it is traveling in the UDP packet. An application level checksum can protect the data end to end as it passes through a more complex system.

The UDP checksum clealy only tells you that the packet was generated by a UDP implementation. It doesn't tell you that it came from your sensor. An application level checksum on the other hand may help reject packets that are valid UDP but came from some other source.

So I can see legitimate reasons for not trusting the UDP checksum but equally not trusting the UDP checksum and then implementing a similarly weak checksum at the application level seems strange.

There is the possibility that the person desinging the protocol simply didn't know that UDP provided checksums or that the protocol is actually a slight variant of one designed to run over a medium that does not provided checksums.

P.S. since this post is tagged security be aware that the checksums in question are designed to protect against inadvertant changes. Protecting against deliberate modification or spoofing requires both the use of cryptographic hash functions that are resistant to deliberate collisions/preimages and the use of some mechanism (e.g. signatures made using a public key) to verify the hashes themselves have not been modified.

Title: Should UDP data payloads include a CRC?


问:
Do I violate the Single Responsibility Principle with my multi-purpose AST Class?
I am writing a compiler, for which I devised a rather classic architecture: it's composed of sequential passes piped together, starting with a lexer and a parser, continuing with a macro processor, then a semantic analysis/type checker pass, and finally an intermediate code generator (and maybe IR optimizer that will come later).

My current approach is the following. The parser is building an AST, where each type of AST node inherits from an "AST" base class. I plan that virtual functions of the AST will implement the functionality of subsequent passes. To provide a simplified example:

macroExpand() finds, evaluates and substitutes all the macros in the AST, recursively;

typeCheck() performs type checking, type inference and general semantic analysis/error checking on the now-desugared tree, completing each node with type annotations (which are implemented as member variables);

codeGen(), finally, generates some kind of IR from the annotated AST.

However, I'm afraid that having all this functionality in one single class violates the single-responsibility principle.

I reckon that macro expansion especially does not fit in: I was thinking about integrating semantic analysis and code generation into just one set of functions instead of separating them, simply because I don't think I need to traverse the entire tree twice, and I would have to look at the types at codegen time anyway, even if I've pre-inferred and pre-checked them previously.

But even with this structural change, there are still at least two completely different sets of methods on my AST classes. I don't yet see any particular reason why this in itself would be bad in my specific case, but I'm pretty sure the single responsibility principle was discovered for a good reason.

One way to remedy (?) this issue would be to use the visitor pattern and write separate visitor class hierarchies for the AST for each purpose (macro expansion, semantic analysis and/or code generation). But I really don't feel like doing so. (In all honesty, I really dislike the idea.) So far it only seems to introduce unnecessary complexity and burden (by means of forcing me to maintain parallel class hierarchies).

Currently, I'm writing this compiler in C++, but I'm pretty sure that if I were using a language that permitted after-the-fact modification and augmentation of classes (e.g. Objective-C categories), I would surely make use of this feature of the language and I would just decorate my base AST classes with the necessary set of methods, independently of the "core" interface and implementation of said classes.

I could sort of simulate that in C++ by putting all the method declarations in one header file, but writing the implementation of each category of functions in different implementation files. This, however, contradicts the usual "one class, one file" practice.

To sum up, my question is: is my current approach of giving two or three different functionality to one class really bad?

If so, are any of my suggested fixes considered to be good practice, or…

If it isn't, can you suggest something better?

答:
Yes, that's a terrible, terrible plan. Those are completely different things. Violating SRP is just the beginning of your problem. Other problems are things like not being able to offer parse-only support for tooling, for example.

A semantic analyser should perform a translation from an AST to a semantic graph. The AST should not be mutated, nor should it ever hold any semantic information. The AST should never hold any code generation information. The AST should never, ever, do anything but hold syntax.

The issue of parallel class hierarchies just doesn't come up in reality because all of these trees and graphs do completely different things with completely different representations and implementations. If your semantic tree closely parallels your syntax tree, you're probably building either a very basic interpreter or doing it very wrong.


答:
I hope this answer doesn't fall into the “derail the topic by suggesting re-factorings for the code” category. Nevertheless, I'd like to suggest that you replace the boolean useNewVersion flag with an integral version parameter that all functions should accept. The implementation of the function can then make decisions like this.

final int newVersion = 424;
final int oldVersion = 423;
if (version == newVersion) {
    // Do what is appropriate for the “new” version
} else if (version == oldVersion) {
    // Do what is appropriate for the “old” version
} else {
    throw new VersionNotSupportedException(version);
}
```

<p>If the action to be taken for the two currently supported versions happens to be identical, the function can still make good use of the parameter.</p>

<pre class="lang-java prettyprint-override"><code>final int newVersion = 424;
final int oldVersion = 423;
if (version != newVersion && version != oldVersion) {
    throw new VersionNotSupportedException(version);
}
// Do what is appropriate for both versions
</code>```

The problem with the useNewVersion flag is that “new” doesn't really have any meaning and therefore, your colleague is not completely wrong saying that there is no way he could act upon it sensibly so the parameter shouldn't be passed in the first place. On the other hand, stable interfaces are a good thing to have. I'd also consider it desirable to have all functions follow a common convention, such as taking the version as their first parameter. It can help reduce confusion when looking at a function call. If you can already anticipate that you'll need the parameter again in a future version, repetitively adding and removing it is time not spent very effectively. Especially if you propagate the version information through several layers of function calls.

You've said that the useNewVersion flag is loaded from some user configuration. That's fine and you don't have to change it. Just alter your internal code to translate that boolean flag into an integer. You can have one central function that does this.

int getCurrentVersion() {
    final int newVersion = 424;
    final int oldVersion = 423;
    final boolean useNewVersion = loadFromDatabase("useNewVersion");
    return useNewVersion ? newVersion : oldVersion;
}
```

Using an enumeration instead of an integer could also be an option.

This seems like a very moderate refactoring effort to me that would help make your code more robust and consistent. If you now receive a new specification from your customer and forget to update some function, you will be told immediately because the new version number is not recognized by them. With the boolean flag, you would instead have silently reversed the meaning of “old” and “new” and a function you forgot to update would have happily done the wrong thing.

Title: Minimal design vs anticipated use

Body:
I hope this answer doesn't fall into the “derail the topic by suggesting re-factorings for the code” category. Nevertheless, I'd like to suggest that you replace the boolean useNewVersion flag with an integral version parameter that all functions should accept. The implementation of the function can then make decisions like this.

final int newVersion = 424;
final int oldVersion = 423;
if (version == newVersion) {
    // Do what is appropriate for the “new” version
} else if (version == oldVersion) {
    // Do what is appropriate for the “old” version
} else {
    throw new VersionNotSupportedException(version);
}

If the action to be taken for the two currently supported versions happens to be identical, the function can still make good use of the parameter.

final int newVersion = 424;
final int oldVersion = 423;
if (version != newVersion && version != oldVersion) {
    throw new VersionNotSupportedException(version);
}
// Do what is appropriate for both versions

The problem with the useNewVersion flag is that “new” doesn't really have any meaning and therefore, your colleague is not completely wrong saying that there is no way he could act upon it sensibly so the parameter shouldn't be passed in the first place. On the other hand, stable interfaces are a good thing to have. I'd also consider it desirable to have all functions follow a common convention, such as taking the version as their first parameter. It can help reduce confusion when looking at a function call. If you can already anticipate that you'll need the parameter again in a future version, repetitively adding and removing it is time not spent very effectively. Especially if you propagate the version information through several layers of function calls.

You've said that the useNewVersion flag is loaded from some user configuration. That's fine and you don't have to change it. Just alter your internal code to translate that boolean flag into an integer. You can have one central function that does this.

int getCurrentVersion() {
    final int newVersion = 424;
    final int oldVersion = 423;
    final boolean useNewVersion = loadFromDatabase("useNewVersion");
    return useNewVersion ? newVersion : oldVersion;
}

Using an enumeration instead of an integer could also be an option.

This seems like a very moderate refactoring effort to me that would help make your code more robust and consistent. If you now receive a new specification from your customer and forget to update some function, you will be told immediately because the new version number is not recognized by them. With the boolean flag, you would instead have silently reversed the meaning of “old” and “new” and a function you forgot to update would have happily done the wrong thing.


问:
How to help programmers use existing shared classes, instead of reinventing them?
My company has a fairly large software project (a couple million lines of code spread across many assemblies.)  One sticking point we've consistently run into during code reviews has been with the use of shared classes.  We have various classes in a shared assembly used for solving common problems that occur throughout our code.  These classes might do things like formatting a name or exporting a file - operations that we need to repeat in various places throughout the program.

We frequently have to fail code reviews because programmers are not aware of the shared classes available to them, leading them to reinvent the existing class.  For example, a programmer might not know that there is a class designed to export a file to our specifications, so they write their own more-specific version.  This becomes even more of an issue if the shared class was created recently, and isn't used in too many places yet.  More junior programmers spend a lot of time reinventing wheels while doing tasks that, with full knowledge of the shared assemblies, would have been relatively simple.

What are some techniques we might try for spreading knowledge of these shared assemblies?  Typical code documentation seems insufficient here, since the issue is with knowing whether a class exists in the first place.  Are there good ways to document shared assemblies that would allow programmers to quickly answer the question of "Does a class already exist in our code that does x"?  What can we do when adding a new shared class to let developers know about the class and encourage its continued use?

答:
Are the existing classes well-organized?  If you look at any well-designed library, it's generally pretty easy to figure out whether a class or method exists to do something because the class either exists more or less where you expected it to be or it doesn't.  On the other hand, lots of poorly-designed libraries aren't organized in a way that makes sense to people trying to use them which makes discovering functionality hard.  If you have an object junk drawer of "miscellaneous utilities", for example, that's going to be very hard for people to find what they're looking for.

Are senior developers helping junior developers learn the code base or just throwing them to the wolves and catching things once the code has already been developed and is ready to review?  If I'm going to assign a task to a junior developer, I would expect that if I know there are pieces of code that can be leveraged that I would mention their existence.  It makes sense in the initial white-boarding of the solution that the senior developer mentions that the junior developer should use the new message-handling framework that just got promoted or that the file generation class already exists and just needs to be wired in.

Are developers and project managers picking up on early indications that wheels are being reinvented?  If a junior developer gets a task that I expect to take a couple of days because 90% of the code is already written and the appropriate classes just need to be called and that developer estimates that it'll take him 2 weeks, that should indicate a strong possibility that the junior developer is planning to build wheels that already exist.  When that sort of disconnect happens, it's useful to walk through why there is a divergence in estimates.  As the code is being developed, status reports stand-up meetings, and general chatter can let you know that a developer is spending more time on something than he "should" which often indicates that they're reinventing the wheel.  A senior developer that overhears a junior developer trying to work through a problem saving files ought to suspect that the junior developer isn't using the well-tested file saving class and offer assistance.

Beyond that, you can certainly generate additional documentation that helps people use your class library more effectively.  A wiki that walks through common tasks and explains the way that you want those tasks handled in new development, for example, can be an excellent resource.  My bias would be to look at the process improvements first simply because one more source of documentation in an environment that has issues with the development process tends to become one more thing that gets out of date once the initial enthusiasm abates.  But if you're doing everything you can from a process standpoint, the additional documentation can be very helpful.


问:
What does the lack of Unicode support in PHP mean?
How can the lack of Unicode support in PHP affect a PHP web app?</p>

答:
There are (at least) three different approaches to text in the modern programming world.

treat text as a sequence of bytes. There is a widespread convention that byte values 0-127 represent ascii but what byte values 128-255 mean depends on the context. They may be characters in a single byte legacy character set, code units of a multibyte legacy character set or code units of UTF-8.

treat text as a sequence of unicode code points.

treat text as a sequence of UTF-16 code units.

In general a language and/or the libraries, APIs and protocols used with it encourage or even force a given approach.

php takes the first approach. A string is just a sequence of bytes, there is no special type for Unicode. Some would characterise this as "not supporting unicode" but I would consider that a mis-characterisation.

What is does mean is that if you are using php with utf-8 it is your responsibility to do so correctly. UTF-8 is a fairly well behaved encoding so you don't have to worry as much as you did with some legacy multibyte encodings but you still need to be careful about some operations. Especially truncation (don't want to cut in the middle of a multibyte sequence) and character counting (is a count of utf-8 code units acceptable for the given application or do you need to count code points or even something else). If you don't take responsibility for these things your users are likely to see glitches.

On the other hand it matches well with how internet protocols work. A system that works with strings as sequences of bytes can deal with internet data without encoding conversions. A system that works in seuences of code points or utf-16 code units must usually perform conversions of text going to/from the internet.

ContentLicense: CC BY-SA 2.5


问:
Beginner need help on learning Qt programming
Thought of learning Qt. Need help from experienced ones out here. How should I begin. Some good books to refer. Some good tutorials to learn...

Edit: Also which is the good IDE available out there for Qt programming. One that gives inline help, auto completion,indentation... I am using Debian Lenny

答: I always found the tutorials on the Qt/Troll/Nokia site very helpful, and I know other people with the same experience.</p>


问:
storing single character value use string or int C#
While storing single character value for the purpose of status, gender, delete_flag etc. which is better data type string or int. Suppose ::

```<code>status = A/I or status = 1/0
gender = M/F or gender = 1/0
delete_flag = Y/N or delete_flag = 1/0
</code>```

In such scenarios where string or int can be used, which is better option as per code optimization.

答:
Many languages support an enumeration type which is backed by an integer but has friendly scoped names in the language proper.

C#, like many others, call theirs enum. Whenever you use it, ensure you're only working with the numeric value at the boundary of your code if at all, and that you are careful about not changing the order or value of enumerands if you have persistent data represented with the enum.

Even if your value is truth:y or yes-no:y, consider a small enum anyway for clarity in function signatures, particularly if it's unclear what meanings map to true and false. The same holds to assigning meaning to numeric values.

No-one likes to see f(true, 0, 0, null, false, false, 3), not even with IDE functionality revealing the signature on hover or button press.

Performance-wise, you're not going to see any difference between a char and an integer. Strings will incur whatever (non-)penalties of references and whatever it costs to produce a known string literal.

Either will likely be negligible, optimize for readability and bug intolerance instead.

If your question actually is about databases, consider a foreign key into a separate table, that way you can ensure that only valid values end up in the column and it's reasonably extensible.

MSDN on enum


问:
Do we need servant pattern? What about implementing in parent class?
From wikipedia:

Servant is used for providing some behavior to a group of classes.
  Instead of defining that behavior in each class - or when we cannot
  factor out this behavior in the common parent class - it is defined
  once in the Servant.

Please take a look at MoveServant and Movable example in the wiki page. What can be the reason so that I will not want to put moveBy and moveTo in the parent class for all shapes? In other words why parent class implementing the functionality is worse compared with servant implementing the functionality.

BTW in this sentence "Servant is used for providing some behavior to a group of classes." group of classes means classes that belong the the same type (class hierarchy)?

答:
"Servant is used for providing some behavior to a group of classes." group of classes means classes that belong the the same type (class hierarchy)?

Group of classes may or may not be in the same inheritance hierarchy.

Notice that in the WikiPedia example Movable  is an interface rather than a class, and there is no parent class for shapes.  In a more complex situation, classes can implement the interface on interest, while residing in different inheritance hierarchies.  In such case, there is no common parent that would hold the common methods.

Of course, it's possible to create a new parent class and unite the hierarchies.  It's better to avoid deep class hierarchies, though.

p.s. If it were C#, I would consider MoverServant to carry extension methods.


答: Apart from the 'design your libraries well and put them in a logical location where people would expect them', reviewing is in fact a way of sharing knowledge. The earlier the review by more senior developers, the better. Have you considered pair programming? It's great for quickly sharing lots of knowledge about coding, design and domain. It is, in fact, a very early review. </p>

Title: How to help programmers use existing shared classes, instead of reinventing them?

Body:
My company has a fairly large software project (a couple million lines of code spread across many assemblies.)  One sticking point we've consistently run into during code reviews has been with the use of shared classes.  We have various classes in a shared assembly used for solving common problems that occur throughout our code.  These classes might do things like formatting a name or exporting a file - operations that we need to repeat in various places throughout the program.

We frequently have to fail code reviews because programmers are not aware of the shared classes available to them, leading them to reinvent the existing class.  For example, a programmer might not know that there is a class designed to export a file to our specifications, so they write their own more-specific version.  This becomes even more of an issue if the shared class was created recently, and isn't used in too many places yet.  More junior programmers spend a lot of time reinventing wheels while doing tasks that, with full knowledge of the shared assemblies, would have been relatively simple.

What are some techniques we might try for spreading knowledge of these shared assemblies?  Typical code documentation seems insufficient here, since the issue is with knowing whether a class exists in the first place.  Are there good ways to document shared assemblies that would allow programmers to quickly answer the question of "Does a class already exist in our code that does x"?  What can we do when adding a new shared class to let developers know about the class and encourage its continued use?


问:
Why doesn't C++ allow you to take the address of a constructor?
Is there a specific reason that this would break the language conceptually or a specific reason that this is technically infeasible in some cases?

The usage would be with new operator.

Edit: I'm going to give up hope on getting my "new operator" and "operator new" straight and be direct.

The point of the question is: why are constructors special? Keep in mind of course that language specifications tell us what is legal, but not necessarily moral. What is legal is typically informed by what is logically consistent with the rest of the language, what is simple and concise, and what is feasible for compilers to implement. The possible rationale of the standards committee in weighing these factors are deliberate and interesting -- hence the question.

答:
This is because their is no return type of constructor and you are not reserving any space for the constructor in memory. Like u do in case of variable during declaration.
For example : if u write simple variable
                          X
Then compiler will generate error because compiler will not understand the meaning of this.
But when you write
                       Int x;
Then compiler come to know that it int type data variable , so it will reserved some space for variable.

Conclusion:- so the conclusion is that due to exclusion of return type it will not get the address in memory.


答:
You're bumping up against a classic problem in programming language theory, the expression problem. It exposes a weakness of both classic object-oriented design (that it's hard to add operations to a data structure with multiple subtypes) and algebraic data types (that it's hard to add new type cases to an adt when there are multiple operations defined on it).

There are various solutions; the visitor pattern is certainly a common one, but in my opinion object-oriented pattern matching is probably the nicest - there's an implementation for c++ here.

Title: Do I violate the Single Responsibility Principle with my multi-purpose AST Class?

Body:
I am writing a compiler, for which I devised a rather classic architecture: it's composed of sequential passes piped together, starting with a lexer and a parser, continuing with a macro processor, then a semantic analysis/type checker pass, and finally an intermediate code generator (and maybe IR optimizer that will come later).

My current approach is the following. The parser is building an AST, where each type of AST node inherits from an "AST" base class. I plan that virtual functions of the AST will implement the functionality of subsequent passes. To provide a simplified example:

macroExpand() finds, evaluates and substitutes all the macros in the AST, recursively;

typeCheck() performs type checking, type inference and general semantic analysis/error checking on the now-desugared tree, completing each node with type annotations (which are implemented as member variables);

codeGen(), finally, generates some kind of IR from the annotated AST.

However, I'm afraid that having all this functionality in one single class violates the single-responsibility principle.

I reckon that macro expansion especially does not fit in: I was thinking about integrating semantic analysis and code generation into just one set of functions instead of separating them, simply because I don't think I need to traverse the entire tree twice, and I would have to look at the types at codegen time anyway, even if I've pre-inferred and pre-checked them previously.

But even with this structural change, there are still at least two completely different sets of methods on my AST classes. I don't yet see any particular reason why this in itself would be bad in my specific case, but I'm pretty sure the single responsibility principle was discovered for a good reason.

One way to remedy (?) this issue would be to use the visitor pattern and write separate visitor class hierarchies for the AST for each purpose (macro expansion, semantic analysis and/or code generation). But I really don't feel like doing so. (In all honesty, I really dislike the idea.) So far it only seems to introduce unnecessary complexity and burden (by means of forcing me to maintain parallel class hierarchies).

Currently, I'm writing this compiler in C++, but I'm pretty sure that if I were using a language that permitted after-the-fact modification and augmentation of classes (e.g. Objective-C categories), I would surely make use of this feature of the language and I would just decorate my base AST classes with the necessary set of methods, independently of the "core" interface and implementation of said classes.

I could sort of simulate that in C++ by putting all the method declarations in one header file, but writing the implementation of each category of functions in different implementation files. This, however, contradicts the usual "one class, one file" practice.

To sum up, my question is: is my current approach of giving two or three different functionality to one class really bad?

If so, are any of my suggested fixes considered to be good practice, or…

If it isn't, can you suggest something better?


问:
Explain ServiceLocator pattern of ZF2
I am looking at this example

Relevant excerpt from above:

```<code>class AlbumController
{
    public function getAlbumTable()
    {
        if (!$this->albumTable) {
            $sm = $this->getServiceLocator();

            //* My Question Lies Here:
            $this->albumTable = $sm->get('Album\Model\AlbumTable');
        }
        return $this->albumTable;
    }
}
</code>```

What is $this->albumTable?  Its type is AlbumTable.  What is AlbumTable?  It's a class that manages a an instance of class TableGateway of ZendDb module of ZF2.

The problem

In a way, AlbumController depends on TableGateway.  ServiceLocator just makes this chain of dependencies slightly more hidden away.

It actually makes $this->albumTable seem like a "variable that contains data" and adds ability to "call that variable from anywhere inside the code on a whim" -- kind of like declaring an int data type, you declare TableGateway that is tied to your own entity, along with ability to add your own custom business data access and retrieval functions.  I concede that it is pretty cool ...

So?  What's my problem with it?

Problem:   class AlbumController contains dependency on TableGateway.

I wanted to seek out more clarification on why this is acceptable in terms of Single Responsibility Principle and other similar OO separation concerns.  Perhaps I am taking it a bit far, but all AlbumController needs is the data that TableGateway can provide -- namely things like data of Album() type.  Why not implement a mechanism that can get AlbumController its data but without the indirect dependency on TableGateway?  There are design patterns that exist that can make that happen.

To Summarize

Why tolerate dependency on TableGateway inside your Controller class?

How did ServiceLocator come about -- it is seemingly used to "put that dependency as far away as possible while still keeping it there". Is that the purpose of SeviceLocator?

Why not use some other OO facilities (Factories, Builders, etc) to provide/populate Controller directly with data it needs (i.e. Album), instead of weighing it down with TableGateway?

Spirit of the Question

What is the purpose of ServiceLocator Pattern?
Why is it there why is it needed what problem does it really solve, when it seems to just push things off dependency-wise

Also, ServiceLocator is a dependency in every ZF2 Controller that extends AbstractController...  Thus making our custom AlbumController depend on both ServiceLocator and anything that ServiceLocator decides to call (i.e a thing like TableGateway).  You can thus call any Service that you care to out of any Controller place you wish.  What happened to dependency injection and inversion of control concepts?

UPDATE:

It seems like Zend has deprecated ServiceManager::getServiceLocator() as of v3.0.0.  Recommends to "use the container passed to the factory instead".

See also this blog post on deprecating ServiceLocatorAware

答:
The Symfony 2 framework documentation share the same issue in that most of the official examples use a service locator.  This is done because a service locator is a bit easier to demonstrate then dependency injection, especially to new comers.

The documentation for both frameworks also show multiple actions within a single controller class.  Again, one class is easier to explain and organize than multiple classes.  Of course if only one action required a specific service then using constructor injection means that the service is constructed for all actions.   Service locators might actually be a better fit for this approach especially if you keep the action methods thin to work around testing issues.

However, both Zend and Symfony fully support dependency injection. http://framework.zend.com/manual/current/en/in-depth-guide/services-and-servicemanager.html.

And while I have not used Zend in production, for Symfony 2 I have adopted the approach defining all controllers as services and of only allowing one action per controller class which eliminates the issue of injecting unneeded dependencies.

In this particular case one needs to look past the introductory documentation to see what the frameworks are really capable of.

Title: Explain ServiceLocator pattern of ZF2


问:
Benefits of using separate API and UI servers for Web application
At work, we have a large internal application which has been under development for close to 2 years now; I've just recently joined the project and some of the architecture has me slightly perplexed, so I'm hoping someone here can provide some advice before I go out to ask the architects these same questions (so I can have an informed discussion with them).

My apologies if the below is a little long, I just want to try to paint a good picture of what the system is before I ask my question :)

The way the system is setup is that we have one main web application (asp.net, AngularJS) which does mostly just aggregates data from various other services. So basically it is a host for an AngularJS application; there is literally one MVC controller that bootstraps the client side, and then every other controller is a WebAPI controller.

Calls from the client-side are handled by these controllers, which is always deployed to boxes that do nothing but host the Web Application. We currently have 4 such boxes.

However, the calls are then ultimately routed through to yet another set of WebAPI applications (typically these are per business area, such as security, customer data, product data, etc). All of these WebAPIs get deployed together to dedicated boxes as well; we also have 4 of these boxes.

With a single exception, these WebAPIs are not used by any other parts of our organisation.

Finally these WebAPIs make yet another set of calls to the "back end" services, which are typically legacy asmx or wcf services slapped on top of various ERP systems and Data stores (over which we have no control).

Most of our application's business logic is in these WebApis, such as transforming legacy data, aggregating it, executing business rules, the usual type of thing.

What has me confused is what possible benefit there is in having such a separation between the WebApplication and the WebAPIs that serve it. Since nobody else is using them, I don't see any scalability benefit (i.e there's no point in putting in another 4 API boxes to handle increased load, since increased load on the API servers must mean there is increased load on the Web servers - therefore there has to be a 1:1 ratio of Web server to Api server)

I also don't see any benefit at all of having to make an extra HTTP call
Browser=>HTTP=>WebApp=>HTTP=>WebAPI=>HTTP=>Backend services. (that HTTP call between WebApp and WebAPI is my problem)

So I am currently looking to push to have the current WebAPIs moved from separate solutions, to just separate projects within the WebApplication solution, with simple project references in between, and a single deployment model. So they would ultimately just become class libraries.

Deployment-wise, this means we would have 8 "full stack" web boxes, as opposed to 4+4.

The benefits I see of the new approach are

Increase in performance because there is one less cycle of serialisation/deserialisation between the Web application and the WebAPI servers

Tons of code that can be deleted (i.e. no need to maintain/test) in terms of DTOs and mappers at the outgoing and incoming boundaries of the Web Application and WebApi servers respectively.

Better ability to create meaningful automatied Integration Tests, because I can simply mock the back-end services and avoid the messiness around the mid-tier HTTP jumps.

So the question is: am I wrong? Have I missed some fundamental "magic" of having separated WebApplication and WebAPI boxes?

I have researched some N-Tier architecture material but can't seem to find anything in them that can give a concrete benefit for our situation (since scalabilty isn't an issue as far as I can tell, and this is an internal app so security in terms of the WebAPI applications isn't an issue.)

And also, what would I be losing in terms of benefits if I were to re-organise the system to my proposed setup?

答:
I think there is no right/wrong answer here. Have you asked your collegues about the purpose of this architecture?

From how I understand your descriptions, the "WebAPI" in your Architecture serves as kind of self-made Middleware. Now you can research what advantages there are in usages of a Middleware. Basically your Webapp would never need to be adopted if you changed your backoffice system (as long as the WebAPI interface keeps the same).

To go further: Imagine you have a customer database (backend service) and you have 5 web apps communicating with that database. If you replace the customer database system with a new system (like from another vendor and you can't influence the webservice interfaces) you would most likely need to change the communication layer of all 5 web applications.
If you communicate via your WebAPI, you'd just have to change the communication layer of the WebAPI.

Basically, Layer Architecture is nowadays considered as both: Pattern and Anti-Pattern. (See: Lasagna-Code) If you have just 1 system without plans to expand this any further in the next few years I would rather consider this as anti-pattern. But this woudl be an unrealistically taff judge since I don't know the exact circumstances/situation :)


问:
Could a view call a function of the model directly?
this is a fundamental question about MVC (in particular using AngularJS) and I've found similar questions here, but not the exact same problem:

Could the view call a function of the model, or should it only call functions of the controller?

Here's the example:

In my Model there's a function to delete items of a collection, like this:

```<code>function deleteItems(searchExpression) { ... }
</code>```

Now my Controller has an instance of my model including that function, like this:

```<code>$scope.data = queryModelFactory.getModel();
</code>```

I now want to call that funciton when the user clicks a certain element in the HTML page:

```<code><div ng-click="data.deleteItems('blabla')">Remove Items</div>
</code>```

Is that legit? Or would it be better to implement a function in the controller that is passing through the delete request to my model like I'd do in a classical layer architecture? Like this:

```<code>function deleteItems(searchExpression) {
    $scope.data.deleteItems(searchExpression);
}
</code>```

答:
The Model-View-Controller pattern divides the application into three interconnected parts namely the model, the view and the controller.

The central component of MVC, the model, captures the behavior of the application in terms of its problem domain, independent of the user interface. The model directly manages the data, logic and rules of the application. A view can be any output representation of information, such as a chart or a diagram. The third part, the controller, accepts input and converts it to commands for the model or view.

The view should not directly interact with the model but rather delegate the events (e.g. user input) to the controller. In your case, the latter option you presented implements the pattern correctly.


答: As Peter said QT tutorials & online documentation are always the places you should start. In addition you can also go to QT forums. Most importantly once you start coding you should download QT source code so that you can debug and explore it.</p>

Title: Beginner need help on learning Qt programming

Body:
Thought of learning Qt. Need help from experienced ones out here. How should I begin. Some good books to refer. Some good tutorials to learn...

Edit: Also which is the good IDE available out there for Qt programming. One that gives inline help, auto completion,indentation... I am using Debian Lenny


答:
One reason is security - if (haha! when) a hacker gains access to your front-end webserver, he gets access to everything it has access to. If you've placed your middle tier in the web server, then he has access to everything it has - ie your DB, and next thing you know, he's just run "select * from users" on your DB and taken it away from offline password cracking.

Another reason is scaling - the web tier where the pages are constructed and mangled and XML processed and all that takes a lot more resource than the middle tier which is often an efficient method of getting data from the DB to the web tier. Not to mention transferring all that static data that resides (or is cached) on the web server. Adding more web servers is a simple task once you've got past 1. There shouldn't be a 1:1 ratio between web and logic tiers - I've seen 8:1 before now (and a 4:1 ratio between logic tier and DB). It depends what your tiers do however and how much caching goes on in them.

Websites don't really care about single-user performance as they're built to scale, it doesn't matter that there is an extra call slowing things down a little if it means you can serve more users.

Another reason it can be good to have these layers is that it forces more discipline in development where an API is developed (and easily tested as it is standalone) and then the UI developed to consume it. I worked at a place that did this - different teams developed different layers and it worked well as they had specialists for each tier who could crank out changes really quickly because they didn't have to worry about the other tiers - ie a UI javscript dev could add a new section to the site by simply consuming a new webservice someone else had developed.

Title: Benefits of using separate API and UI servers for Web application

Body:
At work, we have a large internal application which has been under development for close to 2 years now; I've just recently joined the project and some of the architecture has me slightly perplexed, so I'm hoping someone here can provide some advice before I go out to ask the architects these same questions (so I can have an informed discussion with them).

My apologies if the below is a little long, I just want to try to paint a good picture of what the system is before I ask my question :)

The way the system is setup is that we have one main web application (asp.net, AngularJS) which does mostly just aggregates data from various other services. So basically it is a host for an AngularJS application; there is literally one MVC controller that bootstraps the client side, and then every other controller is a WebAPI controller.

Calls from the client-side are handled by these controllers, which is always deployed to boxes that do nothing but host the Web Application. We currently have 4 such boxes.

However, the calls are then ultimately routed through to yet another set of WebAPI applications (typically these are per business area, such as security, customer data, product data, etc). All of these WebAPIs get deployed together to dedicated boxes as well; we also have 4 of these boxes.

With a single exception, these WebAPIs are not used by any other parts of our organisation.

Finally these WebAPIs make yet another set of calls to the "back end" services, which are typically legacy asmx or wcf services slapped on top of various ERP systems and Data stores (over which we have no control).

Most of our application's business logic is in these WebApis, such as transforming legacy data, aggregating it, executing business rules, the usual type of thing.

What has me confused is what possible benefit there is in having such a separation between the WebApplication and the WebAPIs that serve it. Since nobody else is using them, I don't see any scalability benefit (i.e there's no point in putting in another 4 API boxes to handle increased load, since increased load on the API servers must mean there is increased load on the Web servers - therefore there has to be a 1:1 ratio of Web server to Api server)

I also don't see any benefit at all of having to make an extra HTTP call
Browser=>HTTP=>WebApp=>HTTP=>WebAPI=>HTTP=>Backend services. (that HTTP call between WebApp and WebAPI is my problem)

So I am currently looking to push to have the current WebAPIs moved from separate solutions, to just separate projects within the WebApplication solution, with simple project references in between, and a single deployment model. So they would ultimately just become class libraries.

Deployment-wise, this means we would have 8 "full stack" web boxes, as opposed to 4+4.

The benefits I see of the new approach are

Increase in performance because there is one less cycle of serialisation/deserialisation between the Web application and the WebAPI servers

Tons of code that can be deleted (i.e. no need to maintain/test) in terms of DTOs and mappers at the outgoing and incoming boundaries of the Web Application and WebApi servers respectively.

Better ability to create meaningful automatied Integration Tests, because I can simply mock the back-end services and avoid the messiness around the mid-tier HTTP jumps.

So the question is: am I wrong? Have I missed some fundamental "magic" of having separated WebApplication and WebAPI boxes?

I have researched some N-Tier architecture material but can't seem to find anything in them that can give a concrete benefit for our situation (since scalabilty isn't an issue as far as I can tell, and this is an internal app so security in terms of the WebAPI applications isn't an issue.)

And also, what would I be losing in terms of benefits if I were to re-organise the system to my proposed setup?


问:
Should I use strategy design pattern or something else?
I have recently started reading Heads First Design Pattern Book as well as coding on my final year project. In my project I am having Tanks which extends Entity. A Entity can be anything in the game which is positionable on the game map. Entity is an abstract class.

I have a move() method in my Entity class which will be used to change the position of tank. I will have a lot of different kinds of tank in my game and they will move faster or slower according to the velocity they have. Now my question is, I read about strategy pattern and according to it I should use interface for movement as I don't want to keep overriding or changing move method behaviour every time in different tanks. Maybe if a tank doesn't move I need to keep the move method empty.

So should I rather than hard-coding move() method in every Tank introduce a Movable interface in Tank class? This will be beneficial as I can change tank's movement behaviour during runtime but then I am also not sure how to do it as I may have to then introduce x and y location of tank inside the interface implementations somehow and change them accordingly. This will defeat purpose of Entity class as Entity class is used to hold x and y locations.

Please suggest me the correct way to do it.

Let me know if question is not clear because it is a bit hard to express my question as it's a bit complex.

答:
What I recommend is keeping all of your behavior in the tank, but keep the parameters such as velocity in another object. It would look something like this, in pseudocode:

```<code>interface TankParameters {
  int getVelocity();
  int getArmor();
  int getAttackPower();
}

class Tank : Entity {
  private TankParameters parameters;
  private Point location;

  public Tank(TankParameters p) {
    parameters = p;
  }

  public void move(Direction d) {
    // Use the direction, velocity on the parameters object,
    // something else like time and calculate the new location.
  }
}
</code>```

You can have a single Tank class but alter the behavior of each Tank object by passing in different parameters at construction time.

This is a form of Dependency Injection: while the TankParameters class is not technically a dependency because it is contrived and exists solely to break up the responsibilities of the Tank class, the idea of passing in arbitrary objects to alter behavior is a cornerstone of DI.

This is not quite a strategy, simply because TankParameters does not actually contain any algorithms. It exists to externalize data not behavior.

While not strictly part of your question, I would also change Entity to be an interface and use composition instead of inheritance. The links below go into more detail about the benefits of using this approach.

See Also

Designing a library that is easy to use: composition or inheritance

Composition over inheritance

Body:
What I recommend is keeping all of your behavior in the tank, but keep the parameters such as velocity in another object. It would look something like this, in pseudocode:

interface TankParameters {
  int getVelocity();
  int getArmor();
  int getAttackPower();
}

class Tank : Entity {
  private TankParameters parameters;
  private Point location;

  public Tank(TankParameters p) {
    parameters = p;
  }

  public void move(Direction d) {
    // Use the direction, velocity on the parameters object,
    // something else like time and calculate the new location.
  }
}

You can have a single Tank class but alter the behavior of each Tank object by passing in different parameters at construction time.

This is a form of Dependency Injection: while the TankParameters class is not technically a dependency because it is contrived and exists solely to break up the responsibilities of the Tank class, the idea of passing in arbitrary objects to alter behavior is a cornerstone of DI.

This is not quite a strategy, simply because TankParameters does not actually contain any algorithms. It exists to externalize data not behavior.

While not strictly part of your question, I would also change Entity to be an interface and use composition instead of inheritance. The links below go into more detail about the benefits of using this approach.

See Also

Designing a library that is easy to use: composition or inheritance

Composition over inheritance


问:
Best approach to implement multiple levels of difficulty to a minimax AI
I'm programming a game (turned base, in a grid) for which I implemented an AI using the minimax algorithm (with alpha-beta prunning). It's all fine and working, but the AI is too good and I can't win against it.

So now I want to introduce difficulties to the game (something like easy, normal and hard). The AI as it is right now would be the hard difficulty.

My question : What is the best approach to implement multiple levels of difficulty to a minimax AI .

I'm balancing between two ideas.

going for different heuristics depending on the chosen difficulty

adding some randomness to the choice of the best move. Let's say you choose Normal difficulty, then, x% of the times, I would choose the best move given by the same heuristic used for Hard.

答:
There are many approaches you can try:

weaken the evaluation function

break the eval up into two components: the first component is the standard score, the second component is a random value. Then you can use a skill parameter to weight how each component contributes to the final score

for games with different pieces, change randomly the value of the pieces (the perturbation is somewhat controlled via the skill parameter)

add a bounded random value for each root move (this is the "Club Player" option in Ed Schröder's Rebel Chess engine)

...

weaken the search algorithm

disable quiescence search / search extensions (i.e. check extension in chess)

prune random moves

reduce search depth /search speed

...

The artificial stupidity topic is very well studied in chess (e.g. Artificial stupidity - making a program play badly or Reducing Strength for a lot of other interesting ideas).

For a real example you could take a look at Robert Hyatt's Crafty engine and search for SKILL in the source.

Anyway you should consider that:

there isn't a "best approach". You should try and mix different techiques and... results are very game-specific

reducing playing strength against humans is quite easy, but making an engine to play in a fun, human-like way is very hard.


问:
Connected components of a graph using Prolog
Given a corner x of an undirected Graph G I would like to ask for the connected component of x, but my first try does not work as desired. Here it is:

```<code>edge( a,b ).
edge( b,a ).

edge( b,c ).
edge( c,b ).

edge( c,d ).
edge( d,c ).

connected( X,X ).
connected( X,Y ) :- edge(X,Y).
connected( X,Y ) :- \+ edge(X,Y), edge( X,Z ), connected( Z,Y ).
</code>```

And here are my queries and the results:

```<code>| ?- connected(b,What).

What = b ? ;

What = a ? ;

What = c ? ;

no

| ?- connected(b,b).

true ? ;

true ? ;

true ? ;

no
</code>```

Why is corner b not connected to corner d? Why is corner b connected to itself three times? I am afraid of other problems I will get with more complex graphs. Are there any?

答:
First clause could remain the same if you want to prove a special case, where node X connects to X.

It is my opinion that, the clauses in the third predicate would literally look for EXACTLY ONE mutual edge, making it more hard-coded. You could make it dynamic by making it recursive.

```<code>  connected( X,Z ) :-
     edge(X,Y),
     connected(Y,Z). % This line would fail when the program can no longer find an edge that Y connects to.%
</code>```

When it does fail, (the second predicate in your answer must be here), you are asking the program to succeed with a satisfaction that it has managed to find the last node it could possibly route to.

```<code>      connected ( X,Z ) :-
         edge(X,Z).
</code>```

Body:
First clause could remain the same if you want to prove a special case, where node X connects to X.

It is my opinion that, the clauses in the third predicate would literally look for EXACTLY ONE mutual edge, making it more hard-coded. You could make it dynamic by making it recursive.

  connected( X,Z ) :-
     edge(X,Y),
     connected(Y,Z). % This line would fail when the program can no longer find an edge that Y connects to.%

When it does fail, (the second predicate in your answer must be here), you are asking the program to succeed with a satisfaction that it has managed to find the last node it could possibly route to.

      connected ( X,Z ) :-
         edge(X,Z).


问:
How to implement Cache in web apps?
This is really two questions. Im doing a project for the university for storing baseball players statitics, but from baseball data I have to calculate the score by year for the player who is beign displayed. The background is, lets say 10, 000 users hit the player "Alex Rodriguez", the application have to calculate 10, 000 the A-Rod stats by years intead of just read it from some where is temporal saved. Here I go:

What is the best method for caching this type of data? Do I have to used the same database, and some temporal values on the same database, or create a Web Service for that?

What reading about web caching so you recommend?

答:
First of all it is better to store the calculated (cache) results in memcache,  redis or another in memory key/value storages. In memory caches blazing fast and well suited for as a cache storage.

My (and all over the developers' and Django developers) solution is Python decorators which hooks a method and runs before and/or changes behavior of hooked method.

I developed a hash method takes method name and parameters for calculating the hash for key.  After that this decorator takes the result of this method and stores the calculated result as a value of key.

Since the decorator runs before the method, always checks memcache for the value corresponding the hash of parameters.

Title: How to implement Cache in web apps?