问:
When should something be a class? And are my chosen classes good OO design?
My background:

I am new to programming. Python is my only programming knowledge. I program as a hobby, and I'm teaching myself by reading copious amounts of books.

I understand enough about OOP to write OO software. However, I keep feeling uneasy about the things I write... The design seems messy, etc. And I'm unsure as to what should be a class, method, or function.

I have read OOP books such as, 'Object Oriented Thought'. Such books are useful, however, they always deal with easy topics such as making a 'blackjack' game. The applications that I want to write, however, are not based on easy-to-imagine, real world objects.

The application:

I am currently working on a project. The aim of the software is to download images and video from my favourite blogs. (eg, Google Blogger blogs, or WordPress hosted blogs.)

(Yes, it is easy to make, and I've already made it, but the problem is I want to learn  how to make elegant and properly designed OO software.)

Classes:

I have decided on the following classes:

API Client: This will make it easier to deal with sending and receiving various API requests.

BloggerClient, WordPressClient: I will inherit from a generic API Client class, so that I can specialize with specific APIs, eg. Google's, Tumblr's, and Wordpress' APIs.

Parser: A generic media parser. This will get the media from the blogs.

BloggerParser, WordPressParser: I will inherit from the generic Parser, so I can grab posts and media specific to each website.

Use Case:

I will present an example of getting images from a WordPress.com blog.

WordPressParser asks WordPressClient to get blog-posts from photography.wordpress.com

WordPressClient sends an API request to WordPress.

WordPress Client receives a response and sends the posts to WordPressParser.

WordPressParser parses the media links/urls from each blog-post.

The media links are downloaded to disk.

The problems:

I actually don't know if I have made good choices here.

For example, I need the media (photo and video) downloaded to disk. In this case should I make 'download_media()' methods in the Parser class, or is it better design to create a Downloader class?

'Parse' could easily be a method, instead I have used 'Parser', so it could easily be a class. I really don't know when something should be a class or a method.

Should there be a class for BlogPosts? It seems to me that blog-posts are objects (the equivalent to pages of a book, perhaps).

I seem to be taking verbs, 'download', 'parse', and then converting them to nouns in order to make them appear as valid classes.

I feel very lost and confused. Again, the purpose for me is to learn how to properly make and design OO software. I'm not looking just to get the program to work.

Here is the sourcecode for each of my classes so far:

API Client: http://pastebin.com/QRdPqM5F

Base Parser: http://pastebin.com/kV8gBEe6

Parser: http://pastebin.com/cC0yPYdK

In terms of extensibility, I will be adding more websites in the future, so I need something maintainable.

I hope someone could advise me as to what I'm doing wrong. You can view my source code in the links above to really see what I'm talking about.

Thank you!

答:
I'll offer some general problem-solving advice first then use it on your problem so you can see how someone with more experience might approach this.

Problem Domain

As you may have read elsewhere, your design and your code are a representation of your understanding of the problem you're trying to solve. So, before you start coding and before you start designing, you need to analyze the problem itself; this helps make design of your solution easier to create. Along the way, if you can simplify the problem or your view of the problem, then that'll make the solution simpler as well! And simple is good.

When I'm having trouble designing or coding something, a lot of the time it's because I haven't gotten a full understanding of the part of the problem I'm working on. Other times it's because I'm not familiar with some design/implementation technique that would make things easier, so it's good that you're reading up on things!

When you're analyzing a problem, look at who the entities of the problem domain are and how they interact: who does what to whom, who gets what from whom, what processes there are, where does data flow from/to, etc. If you can enumerate the entities and their interactions, this will help ensure that the solution you come up with is complete.

Design

When you design your program, you take the concepts from your problem space and try to map it into whatever language/paradigm you're working in. In the case of OOP, this is objects and methods.

When designing for OOP, you should look at the nouns and verbs in your problem space: who does what to whom, who gets what from whom, etc. These will map into the objects (the "who(m)") and methods (the "does").

One thing which occurred to me while thinking about this is that it would be beneficial to consider which nouns are the subjects of an action and which are the objects -- i.e. to distinguish the "who" vs "whom". These should naturally lead to what objects perform which action on what. E.g.:

```<code>person.putOn(hat)
</code>```

In this, the person is the one acting on the hat, so the method belongs to the person.

Although, sometimes a design might work out better if you reverse things:

```<code>hat.sitOn(person)
</code>```

It depends on the rest of the design and how things map. These are things to look out for and consider.

Hard-and-fast OOP doesn't always allow for things to be mapped from the problem space in the most succinct way; sometimes actions don't seem like they belong to a particular object. In such cases, you could use just a plain function -- otherwise you'll get the noun-ification of verbs that you've noticed into classes. (Others have noticed this as well.)

Your Project

Let's take the above and apply it to your project.

First we'll look at the problem domain.

The aim of the software is to download images and video from my favourite blogs. (eg, Google Blogger blogs, or WordPress hosted blogs.)

What are the players? The actions? The processes? How are things related (in time, in location, etc.)?

Well, there are blogs, blogs have posts, and posts have media. Blogs are hosted by services. Services have APIs which let you access the blogs/posts/media* -- the APIs allow you to download a blog (feed) in a particular format (JSON, XML etc.) and the blog's content will be arranged in a specific structure in this format; part of this content will be references to media.

*I'm not sure if any of the APIs you will be using will be required to access media items of the service's posts, or whether you can access them via regular web URLs, so we'll err on the side of caution here and assume you need an API to access them.

Now let's consider how data flows in the problem domain: You send a request to the API of the service and get a response with feed content, which includes references to media items. You extract those media references, then use the API to get a copy of the media items, then save them to disk in files. (I find it helpful to draw this sort of interaction out on paper, say with a sequence diagram.)

Next, let's see how the problem domain maps to OOP (+ functions):

I said above that nouns in the problem domain will be mapped to objects in your program. This is true, but not necessarily everything will be mapped; some of the nouns in this problem space are at remote locations (i.e. the servers), so you might not need to model them in your program (but it's handy to know they're there).

Starting with the big items: On the remote side of things, there is the Service. The Service has an API. On our side of things, we have Us (the program), and something to talk to the Service's API. So, the API connection -- or client -- is a concept that we need to implement, which you have done already.

Our client will be connecting to the API to download a blog feed, so the API client class (noun) should have a downloadFeed method (verb/action).

This is where things get a bit tricky design-wise, as you've found, because we have multiple levels of abstraction for essentially the same concept: there's the abstract notion of a blog and its posts & media, but there is also the more concrete representation (JSON, XML) of the blog feed that the API client will receive from the service.

So, what should we do? Well, if the API client is the only thing that is going to deal with the feed, then we can probably just leave it in the concrete representation in each of the different API clients. But if we are going to have anything else in the program deal with the feed data, then we should use some common representation (e.g. a blog feed class, a blog post class, and a media item or media reference class) which all the API clients should return for rest of the program to use.

Should the feed data be used by other parts of the program? My answer is: yes. We can turn to a couple of Best Practices to see why: the Single Responsibility Principle (SRP), and Separation of Concerns (SoC).

SRP states that every class or method should be responsible for doing one thing, and one thing only. The purpose of our API clients is to communicate with the different APIs on behalf of the rest of the program. Let's look at how keeping our data inside the API client class would fit in with this:

We download data from the API with the client and get a specific representation of the feed. This is ok, it's what the client is supposed to do.

Next, we extract media information from the feed; this is something of a sub-responsibility in this case: the feed format is directly related to the API, but the API client is only for communicating with the API. In this case, extraction is an action so we'll want to use a function, but it would be tolerable to have this function be part of the API client class. A helper class might be needed to help do the extraction, if extracting the data is complex enough -- this is what you have constructed as your Parser type, which I'll address in a little bit.

Then, the images have to be downloaded (an action, thus a method), which we decided earlier is in the realm of the API client, since it has to communicate with the API to do this.

Finally, the images have to be cached to disk (another action, though this one might need to be noun-ified). This is in violation of the responsibilities of our API client: the client is for communicating with the service API, not for caching things to disk -- caching is a separate concern! Furthermore, having the clients do the caching would mean that the same logic would have to be repeated in every client, which is a violation of DRY.

So, it will be better to have the caching logic outside of the API client so that it can be used across clients. This means that we will need have to have an external, general representation of the feeds so that they can be consumed by the caching code.

Each API client then has to transform (verb) its specific representation ("whom" noun) of the feed to the general representation (another "whom" noun) for use outside the client. This should be done by a function (maybe with a helper class).

So far, our flow is as follows: The API client downloads an API-specific representation of the blog feed, it transforms this representation into a general representation, it then returns this representation to the outside program. The outside program takes this general representation and gives it to the caching logic, which caches it to disk.

This flow is good, except we're missing one thing: the media! We still have to download the images and videos!

The media has to be downloaded at some point between when the blog feed is downloaded and when things are cached to disk -- this is another design point: you should look at when things can be done and when they should be done.

One obvious point to download the media would be right after the data from the feed has been extracted and put into the general representation, but before it is returned from the API client to the rest of the program. The media could be added to the output of the feed function; so things would go something like this:

```<code>def downloadFeed():
    rawFeed = self.downloadRawFeed()
    commonFeed = self.extractFeedDataFrom(rawFeed)
    self.downloadAndPopulateImagesOf(commonFeed)
    return commonFeed
</code>```

There is an alternative to this, and that is to have the media downloaded right before they're cached -- this way, you won't end up with a feed that contains every single media item from that feed in memory at once!

What you could do is populate the general representation with, say, instances of a MediaReference class that holds the information about the media, along with a reference to the API client so that it can actually download it, then the caching code can tell the MediaReference instances to download their media to give to it, one at a time (so that they're not in memory all at once).

And there you have some input on the design of this thing. (Damn, what a long post!)

I actually don't know if I have made good choices here.

Your start was pretty good, so keep at it! You can do it!

Parser

A quick note on what you're calling a parser.

As some noted in their comments, what you're calling a parser is not an actual parser, though I've seen many people refer to such as a parser, so don't feel bad about that. A real parser (see the computer science defn), along with a lexer, takes an input string (say, some JSON) and turns it into a tree of objects, a hierarchy. That's it. It doesn't do anything with that data after that point.

What you're wanting to do is to scrape the data for information. A parser (either a JSON or XML parser, depending on what your APIs use) could be helpful for this, getting the API data into a form which is easily scrapable by your code so you don't have to do a bunch of string manipulation.

Ok, I'm done now.

Body:
I'll offer some general problem-solving advice first then use it on your problem so you can see how someone with more experience might approach this.

Problem Domain

As you may have read elsewhere, your design and your code are a representation of your understanding of the problem you're trying to solve. So, before you start coding and before you start designing, you need to analyze the problem itself; this helps make design of your solution easier to create. Along the way, if you can simplify the problem or your view of the problem, then that'll make the solution simpler as well! And simple is good.

When I'm having trouble designing or coding something, a lot of the time it's because I haven't gotten a full understanding of the part of the problem I'm working on. Other times it's because I'm not familiar with some design/implementation technique that would make things easier, so it's good that you're reading up on things!

When you're analyzing a problem, look at who the entities of the problem domain are and how they interact: who does what to whom, who gets what from whom, what processes there are, where does data flow from/to, etc. If you can enumerate the entities and their interactions, this will help ensure that the solution you come up with is complete.

Design

When you design your program, you take the concepts from your problem space and try to map it into whatever language/paradigm you're working in. In the case of OOP, this is objects and methods.

When designing for OOP, you should look at the nouns and verbs in your problem space: who does what to whom, who gets what from whom, etc. These will map into the objects (the "who(m)") and methods (the "does").

One thing which occurred to me while thinking about this is that it would be beneficial to consider which nouns are the subjects of an action and which are the objects -- i.e. to distinguish the "who" vs "whom". These should naturally lead to what objects perform which action on what. E.g.:

person.putOn(hat)

In this, the person is the one acting on the hat, so the method belongs to the person.

Although, sometimes a design might work out better if you reverse things:

hat.sitOn(person)

It depends on the rest of the design and how things map. These are things to look out for and consider.

Hard-and-fast OOP doesn't always allow for things to be mapped from the problem space in the most succinct way; sometimes actions don't seem like they belong to a particular object. In such cases, you could use just a plain function -- otherwise you'll get the noun-ification of verbs that you've noticed into classes. (Others have noticed this as well.)

Your Project

Let's take the above and apply it to your project.

First we'll look at the problem domain.

The aim of the software is to download images and video from my favourite blogs. (eg, Google Blogger blogs, or WordPress hosted blogs.)

What are the players? The actions? The processes? How are things related (in time, in location, etc.)?

Well, there are blogs, blogs have posts, and posts have media. Blogs are hosted by services. Services have APIs which let you access the blogs/posts/media* -- the APIs allow you to download a blog (feed) in a particular format (JSON, XML etc.) and the blog's content will be arranged in a specific structure in this format; part of this content will be references to media.

*I'm not sure if any of the APIs you will be using will be required to access media items of the service's posts, or whether you can access them via regular web URLs, so we'll err on the side of caution here and assume you need an API to access them.

Now let's consider how data flows in the problem domain: You send a request to the API of the service and get a response with feed content, which includes references to media items. You extract those media references, then use the API to get a copy of the media items, then save them to disk in files. (I find it helpful to draw this sort of interaction out on paper, say with a sequence diagram.)

Next, let's see how the problem domain maps to OOP (+ functions):

I said above that nouns in the problem domain will be mapped to objects in your program. This is true, but not necessarily everything will be mapped; some of the nouns in this problem space are at remote locations (i.e. the servers), so you might not need to model them in your program (but it's handy to know they're there).

Starting with the big items: On the remote side of things, there is the Service. The Service has an API. On our side of things, we have Us (the program), and something to talk to the Service's API. So, the API connection -- or client -- is a concept that we need to implement, which you have done already.

Our client will be connecting to the API to download a blog feed, so the API client class (noun) should have a downloadFeed method (verb/action).

This is where things get a bit tricky design-wise, as you've found, because we have multiple levels of abstraction for essentially the same concept: there's the abstract notion of a blog and its posts & media, but there is also the more concrete representation (JSON, XML) of the blog feed that the API client will receive from the service.

So, what should we do? Well, if the API client is the only thing that is going to deal with the feed, then we can probably just leave it in the concrete representation in each of the different API clients. But if we are going to have anything else in the program deal with the feed data, then we should use some common representation (e.g. a blog feed class, a blog post class, and a media item or media reference class) which all the API clients should return for rest of the program to use.

Should the feed data be used by other parts of the program? My answer is: yes. We can turn to a couple of Best Practices to see why: the Single Responsibility Principle (SRP), and Separation of Concerns (SoC).

SRP states that every class or method should be responsible for doing one thing, and one thing only. The purpose of our API clients is to communicate with the different APIs on behalf of the rest of the program. Let's look at how keeping our data inside the API client class would fit in with this:

We download data from the API with the client and get a specific representation of the feed. This is ok, it's what the client is supposed to do.

Next, we extract media information from the feed; this is something of a sub-responsibility in this case: the feed format is directly related to the API, but the API client is only for communicating with the API. In this case, extraction is an action so we'll want to use a function, but it would be tolerable to have this function be part of the API client class. A helper class might be needed to help do the extraction, if extracting the data is complex enough -- this is what you have constructed as your Parser type, which I'll address in a little bit.

Then, the images have to be downloaded (an action, thus a method), which we decided earlier is in the realm of the API client, since it has to communicate with the API to do this.

Finally, the images have to be cached to disk (another action, though this one might need to be noun-ified). This is in violation of the responsibilities of our API client: the client is for communicating with the service API, not for caching things to disk -- caching is a separate concern! Furthermore, having the clients do the caching would mean that the same logic would have to be repeated in every client, which is a violation of DRY.

So, it will be better to have the caching logic outside of the API client so that it can be used across clients. This means that we will need have to have an external, general representation of the feeds so that they can be consumed by the caching code.

Each API client then has to transform (verb) its specific representation ("whom" noun) of the feed to the general representation (another "whom" noun) for use outside the client. This should be done by a function (maybe with a helper class).

So far, our flow is as follows: The API client downloads an API-specific representation of the blog feed, it transforms this representation into a general representation, it then returns this representation to the outside program. The outside program takes this general representation and gives it to the caching logic, which caches it to disk.

This flow is good, except we're missing one thing: the media! We still have to download the images and videos!

The media has to be downloaded at some point between when the blog feed is downloaded and when things are cached to disk -- this is another design point: you should look at when things can be done and when they should be done.

One obvious point to download the media would be right after the data from the feed has been extracted and put into the general representation, but before it is returned from the API client to the rest of the program. The media could be added to the output of the feed function; so things would go something like this:

def downloadFeed():
    rawFeed = self.downloadRawFeed()
    commonFeed = self.extractFeedDataFrom(rawFeed)
    self.downloadAndPopulateImagesOf(commonFeed)
    return commonFeed

There is an alternative to this, and that is to have the media downloaded right before they're cached -- this way, you won't end up with a feed that contains every single media item from that feed in memory at once!

What you could do is populate the general representation with, say, instances of a MediaReference class that holds the information about the media, along with a reference to the API client so that it can actually download it, then the caching code can tell the MediaReference instances to download their media to give to it, one at a time (so that they're not in memory all at once).

And there you have some input on the design of this thing. (Damn, what a long post!)

I actually don't know if I have made good choices here.

Your start was pretty good, so keep at it! You can do it!

Parser

A quick note on what you're calling a parser.

As some noted in their comments, what you're calling a parser is not an actual parser, though I've seen many people refer to such as a parser, so don't feel bad about that. A real parser (see the computer science defn), along with a lexer, takes an input string (say, some JSON) and turns it into a tree of objects, a hierarchy. That's it. It doesn't do anything with that data after that point.

What you're wanting to do is to scrape the data for information. A parser (either a JSON or XML parser, depending on what your APIs use) could be helpful for this, getting the API data into a form which is easily scrapable by your code so you don't have to do a bunch of string manipulation.

Ok, I'm done now.


问:
Why were Java collections implemented with "optional methods" in the interface?
During my first implementation extending the Java collection framework, I was quite surprised to see that the collection interface contains methods declared as optional.  The implementer is expected to throw UnsupportedOperationExceptions if unsupported.  This immediately struck me as a poor API design choice.

After reading much of Joshua Bloch's excellent "Effective Java" book, and later learning he may be responsible for these decisions, it didn't seem to gel with the principles espoused in the book.  I would think declaring two interfaces: Collection, and MutableCollection which extends Collection with the "optional" methods would have led to much more maintainable client code.

There's an excellent summary of the issues here.

Was there a good reason why optional methods were chosen instead of the two interfaces implementation?

答:
While some people might loathe "optional methods", they may in many cases offer better semantics than highly-segregated interfaces.  Among other things, they allow for the possibilities that an object might gain abilities or characteristics in its lifetime, or that an object (especially a wrapper object) might not know when it is constructed what exact abilities it should report.

While I will hardly call the Java collection classes paragons of good design, I would suggest that a good collections framework should include at its foundation a large number of optional methods along with ways of asking a collection about its characteristics and abilities.  Such a design will allow a single wrapper class to be used with a large variety of collections without accidentally obscuring abilities the underlying collection might possess.  If methods weren't optional, then it would be necessary to have a different wrapper class for every combination of features that collections might support, or else have some wrappers be unusable in some situations.

For example, if a collection supports writing an item by index, or appending items at the end, but does not support inserting items in the middle, then code wanting to encapsulate it in wrapper which would log all actions performed on it would need a version of the logging wrapper which provided for the exact combination of supported abilities, or if none was available would have to use a wrapper which supported either append or write-by-index but not both.  If, however, a unified collection interface provided all three methods as "optional", but then included methods to indicate which of the optional methods would be usable, then a single wrapper class could handle collections which implement any combination of features.  When asked what features it supports, a wrapper could simply report whatever the encapsulated collection supports.

Note that the existence of "optional abilities" may in some cases allow aggregated collections to implement certain functions in ways that were much more efficient than would be possible if abilities were defined by the existence of implementations.  For example, suppose a concatenate method was used to form a composite collection out of two others, the first of which happened to be an ArrayList with 1,000,000 elements and the last of which was a twenty-element collection which could only be iterated from the start.  If the composite collection were asked for the 1,000,013th element (index 1,000,012), it could ask the ArrayList how many items it contained (i.e. 1,000,000), subtract that from the requested index (yielding 12), read and skip twelve elements from the second collection, and then return the next element.

In such a situation, even though the composite collection would not have an instantaneous way of returning an item by index, asking the composite collection for the 1,000,013th item would still be much faster than reading 1,000,013 items from it individually and ignoring all but the last one.

OwnerDisplayName: glenviewjeff

ContentLicense: CC BY-SA 3.0


问:
Social networking sites static caching
In sites like facebook or orkut or friendster what's displayed at the bottom instead of main web address like static.ak.fbcdn.net or profile.ak.fbcdn.net? Are these  different servers or they are just used to misguide the hackers?</p>

答:
They're different servers that are optimized to deliver particular types of content. For example, if you can segregate all the static content from the dynamic content, you can use a very fast specialized webserver to deliver the static content which can assume that all it does is just serve up data from files, but which can't write to any of them (in fact, you can configure the server so that it can't open any file at all for writing or overwrite any part of the program, making the server extremely hardened against attacks). Looking at the URL, I'd guess that the data is actually being served from a Content Delivery Network as well (i.e., a geographically distributed collection of identical servers).

However, it should be noted that none of that will fool hackers. Or anyone else with web development tools. The purpose is to optimize servers for delivering particular types of content, with particular risk profiles, load patterns, etc.

OwnerDisplayName: Sanket Raut

ContentLicense: CC BY-SA 2.5

Title: Social networking sites static caching


问:
How to force "program to an interface" without using a java Interface in java 1.6
In java 1.8 they have wonderful new "default interface methods".  In 1.6 how close can we come?  The goal: use code to keep clients from being able to tell that a class is not a java interface.  If we preserve the right to refactor the class name into a Java Interface we don't need to create a Java interface now.  We just provide the class.  Later, refactoring so the class name becomes an interface wont even touch client code.

From Telastyn's answer in Understanding "programming to an interface":

The "Dependency Inversion Principle" says that an object shouldn't control the creation  of its dependencies, it should just advertise what dependency it needs and let the caller provide it. But it doesn't specify whether the dependency should be a concrete type or an interface.

I want to take advantage of this lack of distinction. I also want to interpret the principle "program to an interface" to mean, "I shouldn't be able to tell if any client code is working with a java Interface or a java Class".  So much so, that later someone could swap out the class for a java interface with the same name and no client code would need to be touched.  That may seem overly strict and not exactly what was meant by these design principles (which try to be ignorant of java's particular quirks) but I'd love to pull it off.

Here's why:  Our development environment doesn't use continuous integration.  Releases that force everyone to integrate their code happen once every... well it hasn't happened in all the years I've been working there.  Worse than that, testing is hugely manual for reasons I wont even attempt to justify.  This means: writing a class that will get used by other people is essentially published because changing it will break someones stream or tested code that is closed and closed hard.  This means: no refactoring the signature of anything public on a shared class.  It feels the same as I expect writing an API for a library must feel.

I believe in YAGNI.  I don't want to do a BDUF.  But this situation tempts me to do silly things like put a Java Interface (big I) on every shared class even though, for now, they only have one implementation.  This is against YAGNI, it annoys developers who consider an unneeded interface to be clutter.

What I really want is the freedom to add that Interface, and maybe alternate implementations, later if needed.  I want to be 100% sure I can do this even when I can't even see all the code that might be written against my widely shared class.  I can only be that sure if I use the compiler to FORCE users to program to my interface (little i).

The question: Can you break this protection w/o using reflection from outside the trusted package?  Is the following the right way to achieve this?  In this environment you only get one shot at getting this right.  I want to know if there is anyway to lock me down to the old implementation from outside the trusted package.  All the commented code is "future" code. Except for the errors in main, which should always be errors.

Here we see someone trying their best to lock us down to an implementation:

```<code>package untrusted;

import trusted.AmIAnInterfaceWithDefaultImplementation;
import trusted.WhoKnowsWhatImplementation;

public class Activate {

    public static void main(String[] args) {
        System.out.println( WhoKnowsWhatImplementation.thisProvides().letsFindOut() );

        AmIAnInterfaceWithDefaultImplementation i =
            WhoKnowsWhatImplementation.thisProvides();

        System.out.println( i.letsFindOut() );

        //Error: AmIAnInterfaceWithDefaultImplementation i = new AmIAnInterfaceWithDefaultImplementation();
        //Error: The constructor AmIAnInterfaceWithDefaultImplementation() is not visible
    }
    //Error: public class ImGonnaForceYouToBeAClass extends AmIAnInterfaceWithDefaultImplementation {}
    //Error: The type ImGonnaForceYouToBeAClass cannot subclass the final class AmIAnInterfaceWithDefaultImplementation
}
</code>```

Prints: Default implementation twice.

Here we choose the implementation to provide in a static factory method.  It's only because we're in the same package that the constructor works.

```<code>package trusted;

public class WhoKnowsWhatImplementation {
     public static AmIAnInterfaceWithDefaultImplementation thisProvides() {
        return new AmIAnInterfaceWithDefaultImplementation();
        //return new IAintNoInterfaceNoMore();
    }
}
</code>```

The class below provides both the interface (small i) and the implementation but because the only constructor is protected and the class is final nothing outside the trusted package can force the interface and implementation to stay together.

```<code>package trusted;

/**
 *  Please don't instantiate directly as this may become an Interface.
 *  Use WhoKnowsWhatImplementation
 */
public final class AmIAnInterfaceWithDefaultImplementation {

    protected AmIAnInterfaceWithDefaultImplementation(){}

    public String letsFindOut() {
        return "Default implementation";
    }
}

//public interface AmIAnInterfaceWithDefaultImplementation{
//  public String letsFindOut();
//}
</code>```

We're free to switch to being an interface and push the implementation out to a new class

```<code>package trusted;

//public class IAintNoInterfaceNoMore implements AmIAnInterfaceWithDefaultImplementation {
//
//  @Override
//  public String letsFindOut() {
//      return "Shiny new implementation";
//  }
//}
</code>```

The need for the 'trusted' package comes from a desire not to have the static factory method live on the same class it's instantiating.  It would have to move when we switched to a Java Interface which would impact client code.  That is why the constructor had to be package accessible.

Can you lock this down as a class from outside the trusted package without using reflection?  Is your way of locking it down something that is reasonable to protect against?  What else would you do to protect against getting locked down?  Is there a better approach in java 1.6?

I'd also be interested to know if there is anyway to protect against reflection beyond the java doc begging you not to instantiate it directly but I suspect there isn't.

Many designs fail to adhere to all the design principles. This one violates the open closed principle: classes should be open to extension but closed to modification.  However, this is an attempt to ensure that the classes clients can stay closed even if it changes into a Java Interface.

The example refactoring shown here switches to an interface and implementation class.  It's worth noting that instead it might be decided that the class should actually be abstract.  When we switch to java 1.8, it might even end up as an interface with default methods on it.  The whole point is to preserve the right to make this decision later so we don't have to make it now when we don't know which to do and don't really care.

EDIT: I appreciate all these answers.  Before I accept one, what I'm waiting for is analysis of how vulnerable this approach is to getting locked down to being a class.  I'm willing to accept one that shoots down this whole idea by showing me code that dooms it to forever be a class.  Accepting one that claims it's a sound idea is a nice ego boost but I'd really rather fail here than in the code base.  So convincing me that it's a sound idea is the harder job.

What I've learned from these responses:

Converting from the class to the java interface requires that clients recompile

The class must not expose any more than the java interface could (e.g., no static methods)

Some will insist classes implement Java Interfaces upfront regardless of when they are needed, sigh

The need to recompile the client code strikes me as the most significant issue to be aware of so I'm accepting Maarten Winkels answer.  Thank you all and happy coding.

答:
I don't see any way to "lock down the interface to a class" in your code,  but I do think you need to consider two things:

Your clients would still need to re-compile their code, even though the client source code doesn't have to change: invoking a method on an interface uses a different bytecode operation then invoking a method on an instance.

What would prevent your coworkers from creating a class in the trusted package and invoking the constructor there?


问:
String sentence consistency when sent over sockets
I am learning socket programming. I have a Java application as my server, and C# for the client. Just sending string lines from one to another. Below I have code snippets showing how I am currently doing it.

Anyway, being new to this, there are two points that are still bugging me:

If you send a very large string, it is possible that one fragment arrives, and then the other fragment. Of course this makes sense, specially in slow connections like mine. My doubts are:

Suppose that my very large string is sent, and it will arrive in two halves. I suppose it is plausible for the second half to arrive before the first one - for whatever network reason. If this is the case, how is one supposed to handle this?

So my very large string is sent and chunks of varying sizes arrive one after the other - what is the right way to determine that all these chunks belong to the same string line? In other words, if I send "I like cats" and the target receives "I like" and "cats", how can it deduce that those two things are meant to be part of the same sentence, rather than two different sentences? I guess that this is entirely up to my own protocols: perhaps I can send over tags like <start> and <finish> as part of my sentence - this way the receiver knows that whatever lies between thew two tags is one sentence... assuming that the chunks arrive in the intended order (which depends on my question above).

Receiving a string

JAVA

```<code>    while (true) {
        if (socket.getInputStream().available() != 0) {
            BufferedReader input = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            System.out.println("Got message: " + input.readLine());
        }
    }
</code>```

C#

```<code>    byte[] myReadBuffer = new byte[1024];
    System.Text.StringBuilder message = new System.Text.StringBuilder();
    int numberOfBytesRead = 0;
    do{
        numberOfBytesRead = stream.Read(myReadBuffer, 0, myReadBuffer.Length);
        message.AppendFormat("{0}", System.Text.Encoding.ASCII.GetString(myReadBuffer, 0, numberOfBytesRead));
    }
    while(stream.DataAvailable);
</code>```

Sending a string

JAVA

```<code>    BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
    writer.write("HELLO");
</code>```

C#

```<code>    string msg = "HELLO";
    byte[] messageBytes = System.Text.Encoding.ASCII.GetBytes(msg);
    stream.Write(messageBytes,0,messageBytes.Length);
</code>```

答:
Given that you use streams then the underlying implementation will be using TCP which guarantees that packets arrive in order aka out of order delivery is not your problem™. If you use UDP (datagrams) you will have to deal with out of order and missing packets yourself though they won't be split up.

And most protocols should have a way of differentiating subsequent (logical) packets; for example by prefixing the length of the packet or by delimiting (post fix a special sequence).


问:
Why would HTML and CSS be required for .NET development?
On a job application, part of the job description is "...needs to know HTML and CSS as some .NET is required...".  What does this mean?

I thought HTML is a programming language, CSS is a way to format HTML, and .NET is just a runtime framework that is not something you really "know".  Can someone please explain what this means to me?

答:
HTML is a design and layout language, not a programming language.  Is't almost always paired with JavaScript, which is a programming language.

.NET is a catchall name for a number of Microsoft technologies, among them C#, Visual Basic, CLR, and a number of frameworks.  It is a development mindset and languages that you have to know in order to be "a .NET developer".

Although it can be used for desktop applications, .NET is heavily used for web development; in that case you do need to know HTML, CSS and a few other things to complete any project.


问:
Handling interface segregation in C++
I'm designing a "view" handling system for a game. The goal is to be able to have different "views" that can be shown in sequence or stacked on-top of each other. For example, the initial splash screen is one View and the main menu that follows the splash screen is also a View which is rendered when the splash screen terminates. The camera view of the game world is also a View and the HUD is a View that is rendered on top of the game View.

While defining the interface for View I realize that the stacked nature of Views corresponds to the input focus priority. I.e. the View that's at the top of the stack should be offered to act on any user input before any other Views because in essence it is in the "foreground" for focus.

So the design of the interface for View looks like this at the moment:

```<code>/**
 * Interface for a "view". A view is a renderable target that can accept user input.
 *
 * One can think of it as a "layer", many layers can be drawn over each other in a
 * stack like fashion where the input focus travels from the top to the bottom of
 * the stack.
 */
class IView{
public:
    virtual ~IView() {}

    IView(const IView&) = delete; // Not allowed
    void operator = (const IView&) = delete; // Not allowed

    /**
     * Called to handle user keyboard input. May be called multiple times per update.
     * @param aKeyEvent The type of input event.
     * @param aKeyCode The key code of the event key.
     * @param aKeyboardState The current state of they keyboard.
     * @return True if the event was handled. False if the event should continue to lower views.
     */
    virtual bool handleInput(KeyEvent aKeyEvent, KeyCode aKeyCode, const KeyboardState& aKeyboardState) = 0;

    /**
     * Called to handle user mouse clicks. May be called multiple times per update.
     * @param aMouseButtonEvent The event to handle.
     * @param aMouseButton Which button it was.
     * @param aMouseState The current mouse state.
     * @return True if the event was handled. False if the event should continue to lower views.
     */
    virtual bool handleInput(MouseButtonEvent aMouseButtonEvent, MouseButton aMouseButton,
                             const MouseState& aMouseState) = 0;

    /**
     * Called to handle user mouse movement. Only called once per update.
     * @param aMouseEvent The event to handle.
     * @param aMouseState
     * @return True if the event was handled. False if the event should continue to lower views.
     */
    virtual bool handleInput(MouseMoveEvent aMouseMoveEvent, const MouseState& aMouseState) = 0;

    /**
     * Called when this view becomes the foreground view.
     */
    virtual void foreground() = 0;

    /**
     * Called when this view loses its foreground status and
     * has another view drawn over it.
     */
    virtual void background() = 0;

    /**
     * Called once every frame to perform periodic processing and rendering.
     */
    virtual void update() = 0;
};
</code>```

This isn't the final interface, I'm just prototyping at the moment. But it gives you an idea.

Consider a game View, with a HUD on top, and then the game is paused so a pause View is rendered on top of the HUD. The pause View is offered first chance to act on user input to continue the game and it swallows all other input. To me this makes perfect sense.

Now, not all Views are necessarily interested in receiving input. Some might only be interested in mouse events and some might only be interested in keyboard events. My initial approach was to just let them have pass-through input handlers. But then I remembered the Interface Segregation Principle so it would make sense to define two more interfaces IKeyboardHandler and IMouseHandler and let the relevant View classes implement those when needed. But then I need to use dynamic_cast when passing input to the View objects to see if a particular View implements for example IKeyboardHandler.

I'm not sure if this approach is any more elegant than having empty input handlers and I'm looking for input and ideas on the design.

答:
Don't use a pattern just because someone says it's a good idea. Following design patterns is an antipattern.

It looks to me like keyboard and mouse handling absolutely should be part of View, not something else.

There should probably be a ChainedView base class that implements View, which offer a default implementation of the virtual methods for keyboard and mouse handling. Some Views, like pause, will override that to only accept input they understand and ignore the rest - or maybe they won't even be a ChainedView. Most Views will override it to handle what they can and pass the rest onto the next chained view. Any View that doesn't need to handle input itself will automatically pass it on, so there is already separation there.

Title: Handling interface segregation in C++


问:
What is the benefit of a function without parameters which only calls another function
A tutorial (for Javascript) I'm doing suggests we write a function like this one:

```<code>function sayHello() {
   //Some comments explaining the next line
   window.alert("Hello");
}
</code>```

Other than obfuscation are there benefits to writing something like this in real life? If so, what are the benefits?

答:
The thinking behind your question seems to be: "Why not just write alert("Hello"); directly? It's pretty simple."

The answer is, in part, because you don't really want to call alert("Hello") - you just want to say hello.

Or: Why store contacts on your phone, when you can just dial phone numbers? Because you don't want to remember all those numbers; because dialing numbers is tedious and error-prone; because the number might change, but it's still the same person at the other end. Because you want to call people, not numbers.

This is what's understood by terms like abstraction, indirection, "hiding implementation details", and even "expressive code."

The same reasoning applies to using constants instead of writing raw values everywhere. You could just write 3.141592... every time you need π, but thankfully there's Math.PI.

We might also look at alert() itself. Who cares how it constructs and displays that alert dialog? You just want to alert the user. Between you writing alert("Hello") and the pixels on your screen changing, there's a deep, deep stack of code and hardware, with each layer telling the next what it wants, and that next layer taking care of details until the deepest possible layer flips some bits in the video memory.

You really don't want to have to do all that yourself just to say hello.

Programming - well, any task, really - is all about breaking complex problems into manageable chunks. Solving each chunk gives you a building block, and with enough simple building blocks, you can build large things.

It's algebra.


问:
Why return back or assign to a supertype rather than the implementation type?
I have been doing a lot of reading about polymorphism, inheritance and typing (specifically how it applies to Java).

I have seen some interesting examples, but not much explanation as to why.

I.e.:

```<code>    Person p = new Student();
</code>```

I am assuming we have a Person class and a Student class which extends the Person class.

My question is: Why would you want to do this kind of assignment at all?

答:
The contrived examples traditionally given in such problems don't properly capture the reasoning of why polymorphism is good and useful.

Lets instead look at real world examples that are found in the Collections framework of Java.  Things that implement List. Of the "All Known Implementing Classes", there are two that are most interesting for this example - the LinkedList and the ArrayList.

The LinkedList is backed by a linked list, and the ArrayList is backed by an array.  These structures have different advantages and disadvantages for doing certain operations.  An ArrayList is very fast for finding the arbitrary nth element, while the LinkedList is slow for this.  On the other hand, sticking an element at the front or end of a LinkedList is always quite fast, while the ArrayList putting an element at the front is painfuly slow and the end can be quite bad too if it needs to grow the array.

So, there's a reason why I would chose one implementation or the other.  Now, if I am returning a value from a function... ArrayList<Integer> foo() it would mean that I could never change the implementation behind it.  If I later decide that I want a LinkedList - I couldn't do that because it would cause all the code that uses it to break and have to be changed to a LinkedList<Integer> instead.

Instead, I can say "it doesn't matter what list I give you - you don't need to know how I'm implementing it." And instead just give you a List<Integer> foo() method instead.  Do you need to know if its a LinkedList? or ArrayList?  Nope. If all I care about is giving you back a List (a collection of elements in some order that may contain duplicates), thats what you're getting.  It makes it easier for me and you to know less about the implementation.

This is part of the Principle of Least Knowledge that is a component of the Law of Demeter. If I you don't need to know about it, I shouldn't tell you about it. It prevents you from reaching through the interface to the underlying implementation and assuming things about how it works.

In your example, you've got a Person and that interface (or abstract class) is all that you need to work with to do what you need to do.  It allows looser coupling and more flexibility in the design later, and that is a good thing.

There are static analysis tools that can help you write code that is more in line with these guidelines.  One such example is that of pmd.  In its type rules, there is the loose coping rule which will give warnings like: "Avoid using implementation types (i.e., HashSet); use the interface (i.e, Set) instead" - and that is good advice.  (Related SO question on the warning: Why should the interface for a Java class be prefered?)


答:
Using something like that, we can have many different types that all support the interface of Person, which means we can write code that takes a Person and doesn't care which specific type it is, as long as it supports whatever a Person supports.

You might not anticipate an AncientZombieLord class when first writing some generic code that takes a Person, but if AncientZombieLord is a subtype of Person, all the code written for a Person will work for AncientZombieLord too.

If you take a look at Java's collections, there are ArrayList and LinkedList types, which are both subtypes of List.  They have different performance characteristics, but both support a common interface, so I can write code that uses a List that will work with either kind of list.

You can use this sort of thing to write a generic algorithm that uses one type now, and then switch it to something else without needing to fiddle with a lot of code -- just change one type.

In general, being able to abstract away from details that don't matter is a big win.

Title: Why return back or assign to a supertype rather than the implementation type?

Body:
I have been doing a lot of reading about polymorphism, inheritance and typing (specifically how it applies to Java).

I have seen some interesting examples, but not much explanation as to why.

I.e.:

```<code>    Person p = new Student();
</code>```

I am assuming we have a Person class and a Student class which extends the Person class.

My question is: Why would you want to do this kind of assignment at all?


问:
How do I handle a spam server invalidating my tokens?
Our web application sends a one-time use generated token, in the form of an URL, to clients who forget their passwords. This works except for the case where the client is sitting behind another server (i.e. the spam server) that scans their email for URLS and does a GET on the URL. I'm assuming the server is checking for a malicious payload.

The client opens the email and clicks on the link, but obviously nothing happens because the token is invalid at that point.

I can think of some ways of handling this:

• Instead of expiring immediately, allow the token to be valid for a certain time period. Disadvantage: This circumvents the whole point of a one-time use token since the token can be used multiple times. Plus it may not solve the problem if the user decides to open their email PAST the expiration time.

• Make the token good for two uses. Disadvantage: similar to the above. What if the spam checker "checks" the URL again... Sigh.

Anyways, I'm looking for some wisdom here on how to handle this. If there are better ideas than what I've proposed I'd love to hear them.

答:
Instead of sending a url, send a url and a confirmation code that's not part of the URL
You can still make the combo good for just one use, and for a limited amount of time.</p>


答:
@MichaelT's answer is excellent from the theory side, but here's a more concrete explanation:

In this use case, which is only one example of dynamic typing, the benefit isn't obvious just looking at the single line of code in your example. Suppose Person is an interface, abstract class or even concrete base class in which a talk() method is exposed. By declaring a Student instance as a Person, functions can accept a generic type (i.e. Person), knowing that when the code runs, it will be the Student's talk() method that is executed, not whatever might be in Person (if it even defines a method body).

```<code>abstract class Person {
  void talk() {
    System.out.println("I am a person."); // default behavior
  }
}

class Student extends Person {
  @Override
  void talk() {
    System.out.println("I am a student.");
  }
}

// Elsewhere...
public static void main(String[] args) {
    Person p = new Student();
    p.talk();
}

// Output:
I am a student.
</code>```

In this manner, it is possible to have multiple implementations of the same conceptual method, without having to resort to instanceof-based switches or if/else logic.

For a more complete understanding of dynamic typing, investigate how a fully dynamically-typed language such as JavaScript works, or look at C#'s dynamic keyword and usage.

Body:
@MichaelT's answer is excellent from the theory side, but here's a more concrete explanation:

In this use case, which is only one example of dynamic typing, the benefit isn't obvious just looking at the single line of code in your example. Suppose Person is an interface, abstract class or even concrete base class in which a talk() method is exposed. By declaring a Student instance as a Person, functions can accept a generic type (i.e. Person), knowing that when the code runs, it will be the Student's talk() method that is executed, not whatever might be in Person (if it even defines a method body).

abstract class Person {
  void talk() {
    System.out.println("I am a person."); // default behavior
  }
}

class Student extends Person {
  @Override
  void talk() {
    System.out.println("I am a student.");
  }
}

// Elsewhere...
public static void main(String[] args) {
    Person p = new Student();
    p.talk();
}

// Output:
I am a student.

In this manner, it is possible to have multiple implementations of the same conceptual method, without having to resort to instanceof-based switches or if/else logic.

For a more complete understanding of dynamic typing, investigate how a fully dynamically-typed language such as JavaScript works, or look at C#'s dynamic keyword and usage.


问:
Help me to understand 'stateless' software in functional programming
I'm an experienced software engineer, and have experience in a range of languages from PHP, Ruby, C#, Java - the last few years I've primarily worked in Java.

I'm now learning Scala, and it's my first real foray into functional programming.

I understand that my methods should not have side affects, and that I should favour immutability.

I am trying to build a small project which I've previously built in Java and Python, as an exercise. The application does the following:

Talk to a REST service to retrieve a set of configurations.

Maintain a copy/cache of those configurations, so they can be references in other areas of the software.

Listen for user input, and make calls to RESTful services again using the user's input as the command and the configurations we retrieved at startup.

It seems to me that since my class which deals with the RESTful API won't be referentially transparent (the output could differ for any number of reasons, it's an external API over which I have no control), I have to have some kind of state (the configurations), that maybe this software isn't as suited to a FP paradigm.

Am I thinking about this the wrong way?

Thankyou

答:
Consider the sentence

I understand that my methods should not have side affects, and that I
  should favour immutability.

Favour immutability means you should not use mutability when you don't need it, and that you should deal with it in a special way when you do need it.

There are many cases in which you can use mutation to compute something, whereas you can also use a mutation-free solution using recursion or high-order functions like map, fold, filter, and so on.
For example, if you want to compute the sum of numbers from 1 to n, you can write

```<code>def sumMut(n: Int): Int = {
    var s = 0
    var i = 1
    while (i < n) {
        s = s + i
        i = i + 1
    }

    return s
}
</code>```

using mutation, but you can also write

```<code>def sumImmut(n: Int): Int = {
    def loop(i: Int, acc: Int): Int = if (i < n) loop(i + 1, acc + i) else acc

    loop(1, 0)
}
</code>```

without mutation. The former is an imperative / statefull solution, the latter is a functional / stateless solution.

In case where mutation is needed to store state (e.g. between intermediate calls to an object), the functional approach is to

Keep the code that uses mutation to a minimum, and

Clearly isolate that code from the rest of the code, which should be mutation-free.

Some functional languages offer explicit constructs to address point 2 (see e.g. monads in Haskell).

Body:
Consider the sentence

I understand that my methods should not have side affects, and that I
  should favour immutability.

Favour immutability means you should not use mutability when you don't need it, and that you should deal with it in a special way when you do need it.

There are many cases in which you can use mutation to compute something, whereas you can also use a mutation-free solution using recursion or high-order functions like map, fold, filter, and so on.
For example, if you want to compute the sum of numbers from 1 to n, you can write

def sumMut(n: Int): Int = {
    var s = 0
    var i = 1
    while (i < n) {
        s = s + i
        i = i + 1
    }

    return s
}

using mutation, but you can also write

def sumImmut(n: Int): Int = {
    def loop(i: Int, acc: Int): Int = if (i < n) loop(i + 1, acc + i) else acc

    loop(1, 0)
}

without mutation. The former is an imperative / statefull solution, the latter is a functional / stateless solution.

In case where mutation is needed to store state (e.g. between intermediate calls to an object), the functional approach is to

Keep the code that uses mutation to a minimum, and

Clearly isolate that code from the rest of the code, which should be mutation-free.

Some functional languages offer explicit constructs to address point 2 (see e.g. monads in Haskell).


答:
Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this:

```<code>xs = [1, 2, 3, 4, 5]
sum = 0
for x in xs:
  sum += x
</code>```

(Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, because we mutate the sum variable at each iteration. The sum variable is not referentially transparent, because it points to different values at different points of time. The state is encoded in the control flow. Scala is not dogmatic about functional programming, and allows you to write code in a stateful way. However, you are encouraged to limit implicit state.

How could we make state explicit, or get rid of it when summing numbers? We can define the sum of a list as zero if the list is empty, and the first element plus the sum if the remaining elements otherwise. Note that this is a recursive definition. In Scala, we'd write it as

```<code>val xs = Seq(1, 2, 3, 4, 5)

def summer(xs: Seq[Int]): Int = xs match {
  case Seq() => 0
  case x :: rest => x + summer(rest)
}

val sum = summer(xs)
</code>```

Note that while we have made the for … in … loop recursive, there still is no obvious state. This is because the recursive function uses the call stack to store intermediate values. The state of the loop becomes explicit if we write it as a tail-recursive function:

```<code>import scala.annotation.tailrec

@tailrec
def summer(xs: Seq[Int], acc: Int = 0): Int = xs match {
    case Seq() => acc
    case x :: rest => summer(rest, x + acc)
}
</code>```

The acc (accumulator) argument represents the state here. It is not mutated, instead we create a new state for each iteration.

In fact, performing such an operation is so common that it's usually done via fold (or foldLeft, which allows the result to be of a different type):

```<code>def summer (xs: Seq[Int]): Int = (xs fold 0) (_ + _)
</code>```

How does explicit state mesh with object-oriented programming? Quite well, actually: the object is the state. Think of the current object as a parameter that is invisibly being passed along in any method call. However, you never mutate the state, and instead create a new one. Careful though: this can make some data structures horribly inefficient if not designed with immutability in mind.

What does this mean for implementing a REST API? Nothing. It is your job as a programmer to decide which paradigms and patterns are suitable in any given situation. Using explicit state can have benefits, but it might also be obfuscation of what's really happening. In any case, different parts of the program can use different amounts of Functional Programming. Using FP patterns is possible even at a fairly small scale, and does not require your whole program to be written in absolute “purity”.

Title: Help me to understand 'stateless' software in functional programming

Body:
I'm an experienced software engineer, and have experience in a range of languages from PHP, Ruby, C#, Java - the last few years I've primarily worked in Java.

I'm now learning Scala, and it's my first real foray into functional programming.

I understand that my methods should not have side affects, and that I should favour immutability.

I am trying to build a small project which I've previously built in Java and Python, as an exercise. The application does the following:

Talk to a REST service to retrieve a set of configurations.

Maintain a copy/cache of those configurations, so they can be references in other areas of the software.

Listen for user input, and make calls to RESTful services again using the user's input as the command and the configurations we retrieved at startup.

It seems to me that since my class which deals with the RESTful API won't be referentially transparent (the output could differ for any number of reasons, it's an external API over which I have no control), I have to have some kind of state (the configurations), that maybe this software isn't as suited to a FP paradigm.

Am I thinking about this the wrong way?

Thankyou

Body:
Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this:

xs = [1, 2, 3, 4, 5]
sum = 0
for x in xs:
  sum += x

(Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, because we mutate the sum variable at each iteration. The sum variable is not referentially transparent, because it points to different values at different points of time. The state is encoded in the control flow. Scala is not dogmatic about functional programming, and allows you to write code in a stateful way. However, you are encouraged to limit implicit state.

How could we make state explicit, or get rid of it when summing numbers? We can define the sum of a list as zero if the list is empty, and the first element plus the sum if the remaining elements otherwise. Note that this is a recursive definition. In Scala, we'd write it as

val xs = Seq(1, 2, 3, 4, 5)

def summer(xs: Seq[Int]): Int = xs match {
  case Seq() => 0
  case x :: rest => x + summer(rest)
}

val sum = summer(xs)

Note that while we have made the for … in … loop recursive, there still is no obvious state. This is because the recursive function uses the call stack to store intermediate values. The state of the loop becomes explicit if we write it as a tail-recursive function:

import scala.annotation.tailrec

@tailrec
def summer(xs: Seq[Int], acc: Int = 0): Int = xs match {
    case Seq() => acc
    case x :: rest => summer(rest, x + acc)
}

The acc (accumulator) argument represents the state here. It is not mutated, instead we create a new state for each iteration.

In fact, performing such an operation is so common that it's usually done via fold (or foldLeft, which allows the result to be of a different type):

def summer (xs: Seq[Int]): Int = (xs fold 0) (_ + _)

How does explicit state mesh with object-oriented programming? Quite well, actually: the object is the state. Think of the current object as a parameter that is invisibly being passed along in any method call. However, you never mutate the state, and instead create a new one. Careful though: this can make some data structures horribly inefficient if not designed with immutability in mind.

What does this mean for implementing a REST API? Nothing. It is your job as a programmer to decide which paradigms and patterns are suitable in any given situation. Using explicit state can have benefits, but it might also be obfuscation of what's really happening. In any case, different parts of the program can use different amounts of Functional Programming. Using FP patterns is possible even at a fairly small scale, and does not require your whole program to be written in absolute “purity”.


问:
When to use identity comparison instead of equals?
I wonder why would anybody want to use identity comparison for fields in equals, like here (Java syntax):

```<code>class C {
    private A a;

    public boolean equals(Object other) {
        // standard boring prelude
        if (other==this) return true;
        if (other==null) return false;
        if (other.getClass() != this.getClass()) return false;
        C c = (C) other;

        // the relevant part
        if (c.a != this.a) return false;

        // more tests... and then
        return true;
    }

    // getter, setters, hashCode, ...
}
</code>```

Using == is a bit faster than equals and a bit shorter (due to no need for null tests), too, but in what cases (if any) you'd say it's really better to use == for fields inside equals?

答:
It is true that very often we use == instead of equals() only for performance, where calling equals() would do just as well, but there exist cases where using == is necessary.

For example, if you have a list which allows duplicate values, (multiple different instances that appear equal according to their equals() methods,) and you want to remove a particular instance from that list, you cannot use equals() to find the instance to remove, because equals() would find you the first duplicate, not the exact instance that you are looking for.  To find the exact instance, you must use ==.

Of course, this is just a simplistic example. In order to find out more about why both == and equals() are absolutely necessary, you need to read up on the concept of value semantics vs. reference semantics.  (I searched for some good source of information on the subject but could not find anything well written; if someone finds something good, please post!)


答:
It's indeed rare when you want to do reference (==) equality instead of logical (equals()) equality. Often when you find yourself checking for reference equality, there might be something wrong with your design, or you might want to implement the equals() method.

Nevertheless, there is one case where I often check for reference equality (not sure if that's good practice):

```<code>public void actionPerformed(ActionEvent e){
    AbstractButton source = (AbstractButton) e.getSource();

    if (source == someButton)
        doStuff();
    else if (source == someOtherButton)
        doSomethingElse();
    // ...
}
</code>```

Title: When to use identity comparison instead of equals?

Body:
I wonder why would anybody want to use identity comparison for fields in equals, like here (Java syntax):

```<code>class C {
    private A a;

    public boolean equals(Object other) {
        // standard boring prelude
        if (other==this) return true;
        if (other==null) return false;
        if (other.getClass() != this.getClass()) return false;
        C c = (C) other;

        // the relevant part
        if (c.a != this.a) return false;

        // more tests... and then
        return true;
    }

    // getter, setters, hashCode, ...
}
</code>```

Using == is a bit faster than equals and a bit shorter (due to no need for null tests), too, but in what cases (if any) you'd say it's really better to use == for fields inside equals?

Body:
It's indeed rare when you want to do reference (==) equality instead of logical (equals()) equality. Often when you find yourself checking for reference equality, there might be something wrong with your design, or you might want to implement the equals() method.

Nevertheless, there is one case where I often check for reference equality (not sure if that's good practice):

public void actionPerformed(ActionEvent e){
    AbstractButton source = (AbstractButton) e.getSource();

    if (source == someButton)
        doStuff();
    else if (source == someOtherButton)
        doSomethingElse();
    // ...
}


问:
Design pattern name for an API wrapper class
I am writing a class that wraps (the parts of) an external API I am using. Let's take the GitHub API as an example.

My imaginary GitHub class now has a fetchUser() and fetchRepository() method. When GitHub decides to host their API at github-api.com I only have to change it once. Nice. But what's the name of this - very common - approach?

Could it be a facade as it's a simpler interface to a more complicated one? An adapter as it links two incompatible APIs, or should I simply call it a wrapper class?

答:
Adapter pattern will have the same method name.
X.DoSomething() will do different thing when it applies to different object.

Façade pattern accesses different functions in separate different classes.
Example of façade class should be when you want to create a validator class.

My guess is that it may be Observer pattern, since when the object changes, another dependent object changes automatically.
You are aware that MVC is an Observer pattern, aren't you?

Otherwise, it can also be Mediator pattern. So when your object in internal system wants to talk to GitHub API object, it will have to go to your class to access.

Thanks,

ContentLicense: CC BY-SA 4.0


答:
Functional programming is not about not having state. It about keeping the functions referential transparency and without side effects. Usually this mean having no state, but that not has to be the case.

Referential transparency mean that for a given input parameters the function will always return the same output.

No having side effect mean that the function does not change the outer world, for example not changing some global parameter. This also mean that not calling the function wont effect other functions.

One example when there is a state but it still keep referential transparency and no side effects are caching.

```<code>class StatefullCache {
  val remoteRepository = ???
  var map: Map[String,Data] = Map()
  private def fetchFromRemote(id: String) = {
    val data = remoteRepository.get(id)
    map = map + (id -> data)
    data
  }
  def get(id: String) = map.getOrElse(id, fetchFromRemote(id))
}
</code>```

This class have state but it referential transparency, since it always return the same result for any given id. It also does not has side effects (well... it has the memory growing, but that a limitation which does not effect the application flow).

In practice no application is a "pure functional".  printing to the screen, file & network I/O have all size effects (and get to to the extreme, even the CPU heat is a side effect).
The idea in functional programming is to keep the side effect to the minimum and isolated. Some languages force you do that. Scala does not force it, but encourage you do so.

Depending on your use case calling 3rd party API/REST/whatever which isn't immutable or has side effect, may be count for practical uses by your application as functional or not. For example if any running of the application is "new world" where the data may be change the class above will work well (Since it will only access the external service once per id).

To summarize it, if you minimize the mutability and the side effect and keep it all in control then you can have the benefits for functional programming in the rest of the app.

Body:
Functional programming is not about not having state. It about keeping the functions referential transparency and without side effects. Usually this mean having no state, but that not has to be the case.

Referential transparency mean that for a given input parameters the function will always return the same output.

No having side effect mean that the function does not change the outer world, for example not changing some global parameter. This also mean that not calling the function wont effect other functions.

One example when there is a state but it still keep referential transparency and no side effects are caching.

class StatefullCache {
  val remoteRepository = ???
  var map: Map[String,Data] = Map()
  private def fetchFromRemote(id: String) = {
    val data = remoteRepository.get(id)
    map = map + (id -> data)
    data
  }
  def get(id: String) = map.getOrElse(id, fetchFromRemote(id))
}

This class have state but it referential transparency, since it always return the same result for any given id. It also does not has side effects (well... it has the memory growing, but that a limitation which does not effect the application flow).

In practice no application is a "pure functional".  printing to the screen, file & network I/O have all size effects (and get to to the extreme, even the CPU heat is a side effect).
The idea in functional programming is to keep the side effect to the minimum and isolated. Some languages force you do that. Scala does not force it, but encourage you do so.

Depending on your use case calling 3rd party API/REST/whatever which isn't immutable or has side effect, may be count for practical uses by your application as functional or not. For example if any running of the application is "new world" where the data may be change the class above will work well (Since it will only access the external service once per id).

To summarize it, if you minimize the mutability and the side effect and keep it all in control then you can have the benefits for functional programming in the rest of the app.


问:
How would you draw this UML class diagram?
I'm currently trying to learn UML but I have trouble with this one. Lets say you have a container with cards, a container with players, and that player has also cards. How would you draw this in a class diagram (application model). How would you set the composition and multiplicity?
Thanks in advance.

I was thinking about this:

But The problem is that I now have 2 lists of cards.

答:
In principle, there is nothing wrong with your UML diagram.

However, it does suggest to me that the Cards referenced by the Player class are different instances than those held in the Deck. This might be an artefact of how I interpret an aggregation relation, for which there is no consensus.

With regard to the members shown in the classes,I am assuming that the semantics are based upon languages like Java and C#: Objects live all on the heap and are only accessible through references.

Depending on what you want to model, you can improve the diagram in two ways:

If a Card that gets dealt out is removed from the Deck and moved to the Player that receives the Card, I would make the link between Deck and Card an aggregation instead of a composition.

If the Player class refers to Card classes that are part of the Deck, then I would make the link between Player and Card a simple association, to signify that the Player doesn't affect the lifetime of the Card.

With respect to the multiplicity, you can leave it out on the diamond-side of a composition relation, because it should always be 1.

If you compare your diagram to others, you may find that often the class members corresponding to associations/aggregations/compositions are left out, because they don't add any information. Also, multiplicities are often left out of the diagram, especially if they can be inferred from the context.


问:
Why is software OS specific?
I'm trying to determine the technical details of why software produced using programming languages for certain operating systems only work with them.

It is my understanding that binaries are specific to certain processors due to the processor specific machine language they understand and the differing instruction sets between different processors. But where does the operating system specificity come from?
I used to assume it was APIs provided by the OS but then I saw this diagram in a book:

Operating Systems - Internals and Design Principles 7th ed - W. Stallings (Pearson, 2012)

As you can see, APIs are not indicated as a part of the operating system.

If for example I build a simple program in C using the following code:

```<code>#include<stdio.h>

main()
{
    printf("Hello World");

}
</code>```

Is the compiler doing anything OS specific when compiling this?

答:
Other people have covered the technical details well, I'd like to mention a less technical reason, the UX/UI side of things:

Write Once, Feel Awkward Everywhere

Every operating system has it's own user interface APIs and design standards.  It is possible to write one user interface for a program and have it run on multiple operating systems, however doing so all but guarantees that the program will feel out of place everywhere.  Making a good user interface requires tweaking the details for each supported platform.

A lot of these are little details, but get them wrong and you'll frustrate your users:

Confirm dialogs have their buttons in different order in Windows and OSX; get this wrong and users will click on the wrong button by muscle memory.  Windows has "Ok", "Cancel" in that order.  OSX has the order swapped and the do-it button's text is a short description of the action to be performed:  "Cancel", "Move to Trash".

"Go back" behavior is different for iOS and Android.  iOS applications draw their own back button as needed, typically in the top-left.  Android has a dedicated button in the lower-left or lower-right depending on screen rotation.  Quick ports to Android will behave incorrectly if the OS back button is ignored.

Momentum scrolling is different between iOS, OSX, and Android.  Sadly, if you're not writing native UI code, you likely have to write your own scrolling behavior.

Even when it's technically possible to write one UI codebase that runs everywhere, it's best to made adjustments for each supported operating system.

Title: Why is software OS specific?


问:
Alternate string formatting options in C++?
I'm looking at optimizing some string formatting code that's hit a lot in our code. We had been using ostringstream, and I converted the code to use sprintf (actually Microsoft's more secure sprintf_s). I've traded type safety for run-time performance. But I've debugged enough sprintf related weird crashes to know that sprintf has its own serious flaws that the compile time checking of ostringstream catch. But ostringstream is more than an order-of-magnitude slower then sprintf by my measure, and that's not tolerable in this code. I'm also not thrilled with the readability of C++ stream string formatting, but this may be entirely subjective.

So unfortunately when formatting strings in C++ I've got several "standard" options that are suboptimal:

sprintf -- fast, but not type safe. Can have insidious bugs when the wrong format string is not used.

ostringstream -- slow, but type safe. IMO Ugly, too verbose, and difficult to read.

boost::format -- a little more readable then ostringstream IMO, but in my performance benchmarks appears to be even slower then ostringstream, so this is out.

To summarize, I'm not really satisfied with the "standard" options. I'd like something that takes both performance and type safety seriously. What other string formatting options are out there for C++?

答:
I was pulled here after writing my own printf-like type-safe format helper currently for revision on CR [link]. I was wondering about better alternatives and found myself thinking in too much conceptual way that seems to be more suitable here than in CR.

Type-Safety Problem of snprintf

The n or Microsoft's _s suffix may protect against buffer overflow and many-compiler-built-in-args-check may protect against other errors (like not enough arguments), but still, there are some corner-cases. The problem is in va_list, where all the types are erased and casting is performend based on type-specifiers inside format string. Other problem is that you cannot pass objects (non-trivially-copyable classes and even struct/POD wrappers are a problem). It is not about type-safety but about ease of usage.

Alternatives to va_list

Variadic templates are the solution and can be used to produce really fast formatters. One other thing I currently have in my mind is to use new C++11 literals, e.g. operator "" _fmt(const char *str, size_t len) which could check for specific formatting options and select the fastest implementation (especially when positional arguments are not used). C++14 further removed the need for one-return-statement constexpr functions, that this can be done in more elegant way.

This buf << "hello %s! pi = %g :)"_fmt("world", 3.14159265) could be the final form for fast and type-safe alternative I have in mind. It could be made really-really fast with few template specializations.

Boost::format and ostream

Both are monstrous inside, boost::format even more, but are type-safe, extensible and with few more tricks involving variadic templates and specializations, it could be made faster. How did you benchmarked them? snprintf is for buffers, ostream is for streams, ostringstream for strings, which is more complex. The idea behind is probably to make something universal and working, that would serve the purpose. The speed is usually not that critical these days, algorithm selection (e.g. O(n^2) vs. O(n log n)) is often more important than how long O(1) will really take.

Fast vs. universal

The fastest solution would always be to write your own specialized version for each (kind of) format string. Nothing can beat that. So, the question is, how close/far you want to go?

I am a firmware programmer and IAR EWARM is offering options about prinf and scanf implementation - usually some basic (e.g. no hex-floats) vs. full. This clearly is about choosing the power vs. speed (and size).


问:
When writing object-oriented code, should I always be following a design pattern?
Is there a conceivable design pattern for any object-oriented program? I ask this because recently I saw an implementation of a Door class with a Lock. It was part of a test and the answer said that the code is following the Null Object pattern:

class Lock
{
public:
    virtual void close() = 0;
    virtual void open() = 0;
    virtual bool is_open() const = 0;
    virtual ~Lock() { }
};

class DummyLock
    : public Lock
{
private:
    DummyLock();
    DummyLock(const DummyLock&) = delete;
    DummyLock& operator=(const DummyLock&) = delete;

private:
    void close() { }
    void open() { }
    bool is_open() const { return true; }

public:
    static DummyLock m_instance;
};

class Door
{
public:
    Door() : m_lock(DummyLock::m_instance) { }
    Door(Lock &lock) : m_lock(lock) { }

public:
    Lock& get_lock() const { return m_lock; }

private:
    Lock &m_lock;
};
```

This made me think: This code follows a good design pattern even though the description is so simple (this class is designing a door class with a lock), so if I am writing more complex code, should there always be some design pattern that I am following?

答:
You should always follow OO design principles (e.g., modularity, information hiding, high cohesion, etc.). Design patterns are a relatively refined niche of OO design principles, especially if you consider the KISS principle.

Patterns are solutions to common design problems. These problems come from one of two places (or a mix of both): the problem space (e.g., software to manage Human Resources in a company) and the solution space. An OO programs is an instance within the solution space (e.g., one of many ways you could design an OO program to facilitate the management of HR).

It's not so easy to know when to use a pattern. Some patterns are low-level, closer to coding and the solution space (e.g., Singleton, Null object, Iterator). Others are motivated by requirements in the problem space (e.g., Command pattern to support undo/redo, Strategy to support multiple input/output file types).

Many patterns come from the need to support variations of the software in the future. If you never need to make those variations, a pattern could be over-design. An example would be using the Adapter pattern for working with the existing external HR database. You decide to apply Adapter because the current database works with Oracle and you might want to support NoSQL in the future. If NoSQL never comes to your organization, that Adapter code could very well be useless. See YAGNI. Support for variations that never come is misusing a design pattern.


问:
What is considered a suitable notice period for a software developer?
I'm being asked by the company I work for to extend my notice period. I'm not outright against it (in fact it's somewhat flattering in a way) but it has made me wonder what a typical notice period might be for a C# software developer?</p>

答:
As an employer I see it differently. If the employee is integral to the core product, no matter their job title, and if it is difficult to recruit replacements (perhaps due to location) and if the company feels there has been a historical lack or insufficient documentation then 3 months would be standard and appropriate length of notice.

It protects the employee to give time to find another job if the company gets into difficulties and it protects the company to give it confidence to offer good development programmes and investment is staff and working environment.

It should be remembered employment should be a two way relationship. And many many more people leave their employ by their own decision than the companies decision.

The company has to think of what is left after you leave and the protection of all the other employees you leave behind. It's not a service.


问:
What's a good way to explain that system configuration at run time should not be changed by code at compile time?
I am programming for a embedded system. When this system boots up it reads from a configuration file some data and execute rules to put the system state according to the configuration read. This configuration is dependent on the environment/requeriments of each customer and can be managed via management interfaces (as a Web interface).

Let me explain myself better: this embedded system is a home router (CPE) for ISPs. The configuration for the router is stored in a flash partition, and there is a default configuration file stored in the file system that is included in the firmware image. One of this ISPs has requested us to release a new firmware which should include a different configuration for one of the network interfaces used by the router.

The problem is this ISP does not want to perform a reset to default configuration file in his customers CPEs to not loose the configuration that each customer has saved on it (as the ESSID for the WLAN interface). The ISP wants the firmware to be able to connect using the new requirement for the network interface once the CPE has been upgraded.

One of my co-workers has proposed this: when the new firmware boots up, it checks if the interface exist in the CPE configuration and if not it adds it during boot time to the configuration file.

I would like to explain them (ISP and co-worker) using good reasons why the configuration file should not be modified at run time except by the management interfaces.

答:
As this is basically the "Magic Number"-s '++' variant, a lot of the same arguments hold (or should, at least). To make a few of my immediate considerations fully verbal:

Adding magic code for the purpose of changing a value is a high-maintenance procedure. Any change to the operation requires code-searches, verifications, re-compiles and re-flashing, whereas changing that value directly does not.

Adding magic code can increase vulnerability. If done as a quick addition it can (read: will) either cause untested and/or unpredicted paths of execution, if it has to bind the interface this may even cause a short period of unprotected access with the addition of one single oversight, depending on the entire code of course.

It's not good value for money. If you manage to eliminate the first two as arguments, you are spending a lot of time of a dedicated high-level developer on adding and changing features for problems that can be solved easier and cheaper.

There are better alternatives to the problem posed.

My alternative, as per point 4: Design, add and test a module that can make a single incremental change to the configuration, using the same authentication and encryption you are using for other safe interfacing to the devices. Allowing the internals to copy-over the current configuration, but only changing that one configuration in the process, all locally, possibly in a non-responsive mode. This is an actual new feature, which if you design it well can remain safe, execution proven for all situations and can be used by a much lower-wage worker to reconfigure unrestricted parts of the set-up in years to come.

Of course you need to set some manner of boundaries as to what can be modified if you want the end-customer to remain safe in the knowledge nobody can reset their WiFi or router passwords to something else.

All that said, my personal experience with ISPs and 9 out of 10 of the companies that build their firmware in general is similar to yours: The ideology of "just throw this in there and compile" still reigns. This is in fact a large driving force these days in choosing my ISP, over cost and speed, as I prefer reliability.

Working with others in embedded systems can be a mine-field :-)


问:
What list of database features/elements are necessary for a programmer to understand?
What database features/elements are necessary for a programmer to understand in order to create non-trivial applications?

I was once asked in a job interview (by a DBA) to rate my understanding of database concepts -- I thought it would be interesting to get opinions.

I'm looking for basic and advanced skills, also any opinions on where developers are typically the weakest (what lack of skills or knowledge creates the most problems).  Also, is it better that developers are need-to-know, and pass more advanced work onto a DBA -- where does that "line in the sand" exist?

答:
Developer ought to to know:

SQL

Performance tuning

Keying and Partitioning (as far as what you can control)

Application deployment

As for what's left to the administrator:

Installation; creating the database

Backup / Recovery

You may have to understand components that are specific to your environment, like ORM and LINQ.


答:
There are two common names:

Entreprise Integration Pattern

or

Enterprise Service Bus

Here are some of the examples of EIP/ESB patterns

Title: Design pattern name for an API wrapper class

Body:
I am writing a class that wraps (the parts of) an external API I am using. Let's take the GitHub API as an example.

My imaginary GitHub class now has a fetchUser() and fetchRepository() method. When GitHub decides to host their API at github-api.com I only have to change it once. Nice. But what's the name of this - very common - approach?

Could it be a facade as it's a simpler interface to a more complicated one? An adapter as it links two incompatible APIs, or should I simply call it a wrapper class?


问:
Coordinating a complicated data migration process
A project I'm involved in has suffered a change in scope, and before I set about trying to cook up some homegrown solution, I'm wondering if there is something out there -- some framework, for example -- that will spare me from having to design and debug my own code. Let me try to explain the details as simply as possible.

Original project

This is a data migration project, an ETL. Originally, there were multiple source databases, multiple ETL engines (allowing for failover), and 1 single data warehouse database. The data warehouse was going to keep the data from the individual sources straight, and it was going to be replicated, behind the scenes: meaning, my ETL would only have to worry about writing to the 1 data warehouse. I had a plan for that.

The project's change

Now, the customer is worried about mixing the individual source data into a single data warehouse. They want separate data warehouses. This would be simple enough, but for the fact that they still want the ETL engines working per the original agreement. Let me explain that.

The project's requirements (in a nutshell)

Let's imagine the following:

4 source databases

4 ETL engines

4 data warehouses (which may each be on a separate server)

Given the above, the ETL engines should be able to work round-robin, a single ETL engine pulling from any of the 4 source databases and writing to the appropriate data warehouse. If 1 or more source databases goes down, or 1 or more ETL engines goes down, or 1 or more data warehouses goes down, the ETL process should still continue, merrily along, performing ETL where it can be done.

My problem

If there were 1 data warehouse, I could coordinate this; if the ETL engines had only a single data source and data warehouse pair they were assigned to, I could handle this; but now things have gotten complicated. I'm really not up on the fancier frameworks -- or even, perhaps the concepts -- that handle something like this. Perhaps there is a name to a scenario like this (and it's a well-known problem), but I don't even know the name.

Technologies used

Note: We already have a working prototype, delivered and tested by the customer, that performs the ETL on 1 source and 1 destination. Here is what we are using:

Jython (Python, running on the JVM) for the ETL

Microsoft SQL Server for the source databases

MySQL for the data warehouse databases

My question (again)

Is there some kind of framework that coordinates a process like this, where the ETL engines can service all the source-destination pairs, provide failover, and yet won't be stepping on one another's toes, or is this something I have to code up myself.

In closing, I hope the above is clear. If I can do anything to clarify the above, please ask. Thanks.

答:
It seems as though you want to keep your existing etl logic pretty much the same but need some new process to divert the data in a more dynamic way.

Some type of software agent may act as a bridge between the transformation layer and db load layer, providing the extra functionality you need.

I am sure something like this exists and what I would do is contact a few of the big etl and database vendors and see what they have to offer. Personally, I would code my own bridge (call it a migration agent) and keep the code changes in your existing etl modules to an absolute minimum if possible


答:
You are making use of delegation.
I.e. you are delegating GitHub::fetchUser() to the GitHub API. So I would call it a "Delegator". </p>