Why strange naming convention of “AlertDialog.Builder” instead of “AlertDialogBuilder” in Android

Question

Why not

AlertDialogBuilder builder = new  AlertDialogBuilder(this);
builder.setTitle(\"foo\");

instead of

AlertDialog.Builder          


        

Answer 1

According to the Javadocs, nested classes (and in this case, static nested classes) are generally used for three things:

1. Logically grouping classes which will only ever be used together.
2. Increasing encapsulation.
3. Increasing readability and maintainability of code.

Point #3 is one reason a lot of developers use static nested classes. Let's take, for example, the ViewHolder pattern in Android development. In a ListAdapter, we can make caching of lists easy by managing the contents of each list element in a ViewHolder (or similarly named inner class). In this situation, it is easy to notice that this specific ViewHolder is only for this class, and when we change this one, we don't change every single one. This means we don't need a List1ViewHolder, List2ViewHolder, ..., ListNViewHolder. Each List-type element can have its own ViewHolder.

Point #2 is a bit less relevant to this point, because we're dealing with static inner classes (that's what Builder is). But in this case, it prevents elements of the inner class from being accessed by the outer class.

Point #1 is the big one here, which is why I've saved it for last. Think of the situations in which you will use AlertDialog.Builder. I can guarantee, with 100% certainty, that every single time you use AlertDialog.Builder, it will be in the building/creation/handling of an AlertDialog. Consequently, this means that every use of AlertDialog.Builder is tied to how AlertDialog works. (This ties in somewhat with point #3; it's easier to maintain two classes in one file than to have them separated.)

Similar to points #1 and #3, but also of its own rite, is the fact that by keeping Builder within AlertDialog, we are not polluting the android.app package namespace. We still keep just AlertDialog within it; but Builder hides within that.

Android is not the only system that does this; the MotiveWave SDK does this also, as do the Adobe Access and eBay SDKs (which I lack links for). I also believe Java EE uses this methodology as well. You will also see it often in Enum types, which in turn is because of the reasons covered in point #1.

Now, you asked why we use AlertDialog.Builder instead of new AlertDialog(), and build it from the object instead of from the builder. The answer here is the same as the factory method pattern seen commonly in Java and other object-oriented programming languages. Notably (from Wikipedia), there are three reasons for this:

1. The creation of an object precludes its reuse without significant duplication of code.
2. The creation of an object requires access to information or resources that should not be contained within the composing class.
3. The lifetime management of the generated objects must be centralized to ensure a consistent behavior within the application.

These explain themselves pretty well; they speak against code duplication (being able to handle all creation functionality within one class), unauthorized access (bad encapsulation practices), and consistent behavior of construction. Also unlisted here is code readability.

I suspect--on a hunch--that AlertDialog is a very resource-intense process. It halts parts of the OS, keeps others running, has to load system resources, and so on. As this answer details, we do not want to provide direct access to the outer class (AlertDialog in this case). This allows the Builder to handle all resource-intensive operations properly. It also keeps us from having to handle esoteric situations which the OS developers considered, but we did not.

So, to conclude, this is actually a decently common design pattern, but not one that has a real explicitly defined meaning. Rather, it is for ease of use, understanding, and maintainability. You mention a concern about design considerations above; I wouldn't worry too much on that. Just keep in mind that static inner classes should always be solely related to their outer class, and you should be fine.