Por qué la convención de denominación extraña de "AlertDialog.Builder" en lugar de "AlertDialogBuilder" en Android

Builder es la clase interna estática dentro de la clase AlertDialog . Por lo tanto, para crear un objeto de clase Builder , debe llamar a AlertDialog.Builder .

Como no hay clase como AlertDialogBuilder por lo que no puede hacer eso.

Si usted quiere usted puede también utilizar como como abajo.

 Builder builder = new Builder(this); builder.setTitle("foo"); 

Pero para usarlo de esta manera, necesitas importar la clase Builder a tu clase como

 import android.app.AlertDialog.Builder; 

En lugar de simplemente

 import android.app.AlertDialog; 

Un ejemplo sencillo

 class A{ static class B{} } 

no puede utilizar

 AB obj = new AB(); 

Tienes que usar

 AB obj = new AB(); 

Espero que esté claro ahora.

De acuerdo con los Javadocs , las clases anidadas (y en este caso, las clases anidadas estáticas) se utilizan generalmente para tres cosas:

1. Agrupar lógicamente clases que sólo se utilizarán juntas.
2. Aumento de la encapsulación.
3. Aumento de la legibilidad y mantenimiento del código.

El punto # 3 es una razón por la cual muchos desarrolladores usan clases anidadas estáticas. Tomemos, por ejemplo, el patrón ViewHolder en el desarrollo de Android. En un ListAdapter , podemos hacer que el almacenamiento en caché de listas sea fácil, administrando el contenido de cada elemento de lista en un ViewHolder (o similarmente denominado clase interna). En esta situación, es fácil notar que este ViewHolder específico es sólo para esta clase, y cuando cambiamos éste, no cambiamos cada uno. Esto significa que no necesitamos un List1ViewHolder , List2ViewHolder , …, ListNViewHolder . Cada elemento List – ViewHolder puede tener su propio ViewHolder .

El punto # 2 es un poco menos relevante para este punto, porque estamos tratando con clases internas estáticas (eso es lo que es Builder ). Pero en este caso, impide que elementos de la clase interna sean accesados ​​por la clase externa.

El punto # 1 es el grande aquí, por lo que lo he guardado para el final. Piense en las situaciones en las que utilizará AlertDialog.Builder . Puedo garantizar, con 100% de certeza, que cada vez que use AlertDialog.Builder , estará en el edificio / creación / manejo de un AlertDialog . En consecuencia, esto significa que cada uso de AlertDialog.Builder está vinculado a cómo funciona AlertDialog . (Esto se relaciona algo con el punto # 3, es más fácil mantener dos clases en un archivo que tenerlas separadas).

Similar a los puntos # 1 y # 3, pero también de su propio rito, es el hecho de que al mantener Builder dentro de AlertDialog , no estamos contaminando el espacio de nombres del paquete android.app . Todavía guardamos AlertDialog dentro de él; Pero Builder esconde dentro de eso.

Android no es el único sistema que hace esto; El SDK MotiveWave hace esto también, al igual que Adobe Access y SDKs de eBay (para los que carezco de enlaces). También creo que Java EE utiliza esta metodología también. También lo verá a menudo en tipos de Enum , que a su vez es debido a las razones cubiertas en el punto # 1.

Ahora, le preguntamos por qué utilizamos AlertDialog.Builder lugar de new AlertDialog() , y lo construimos a partir del objeto en lugar de hacerlo desde el constructor. La respuesta aquí es la misma que el patrón de método de fábrica visto comúnmente en Java y otros lenguajes de programación orientados a objetos. En particular (de Wikipedia), hay tres razones para esto:

1. La creación de un objeto impide su reutilización sin duplicación significativa de código.
2. La creación de un objeto requiere acceso a información o recursos que no deben estar contenidos en la clase de composición.
3. La gestión durante toda la vida de los objetos generados debe centralizarse para garantizar un comportamiento coherente dentro de la aplicación.

Estos se explican bastante bien; Hablan contra la duplicación de código (ser capaces de manejar toda la funcionalidad de creación dentro de una clase), acceso no autorizado (malas prácticas de encapsulación) y un comportamiento consistente de la construcción. También no aparece aquí es la legibilidad del código .

Sospecho – en una corazonada – que AlertDialog es un proceso muy intenso de recursos. Detiene partes del sistema operativo, mantiene a otros corriendo, tiene que cargar los recursos del sistema, y ​​así sucesivamente. Como se detalla en esta respuesta , no queremos proporcionar acceso directo a la clase externa ( AlertDialog en este caso). Esto permite que el Builder maneje todas las operaciones de uso intensivo de recursos correctamente. También nos impide tener que manejar situaciones esotéricas que los desarrolladores de SO consideraron, pero no lo hicimos.

Por lo tanto, para concluir, este es en realidad un patrón de diseño decentemente común, pero no uno que tiene un significado real explícitamente definido. Por el contrario, es por la facilidad de uso, comprensión y mantenibilidad. Usted menciona una preocupación por las consideraciones de diseño anteriores; No me preocuparía demasiado en eso. Simplemente tenga en cuenta que las clases internas estáticas siempre deben estar relacionadas únicamente con su clase externa, y debería estar bien.

Voy a tratar de aclarar detrás de este tipo de organización.

En primer lugar, Builder es una clase dentro de la clase AlertDialog. ¿Por qué crear una clase dentro de otra clase? Yo personalmente sólo crear clases anidadas si quiero añadir más funcionalidad a una clase existente y no creo que desde un punto de vista de diseño que la clase debe ser extendido. Estoy seguro de que se podría discutir sobre este, ya que hay toneladas de diferentes maneras de agregar más funcionalidad a una clase; Pero las clases anidadas pueden ser preferidas por encima de otras (para algunas personas).

Aquí está el punto de vista de los oráculos en las clases anidadas.

Sólo usaría clases anidadas si descubro que hace que el código sea más fácil de mantener e intuitivo.

En este caso creo que los chicos de Google encontraron que en lugar de crear una nueva clase llamada AlertDialogBuilder en comparación con AlertDialog.Builder, es porque ambos producen los mismos resultados; Un diálogo que muestra alguna información en la pantalla con algunos botones. La única diferencia entre ambos (creo) es que se puede establecer el botón positivo, neutral y negativo en el AlertDialog.Builder (que da más funcionalidad a la clase, pero no es necesario más que la clase se debe ampliar, de nuevo la opinión personal).

Al final lo importante es que el código funcione (esperemos que sin errores), es mantenible, legible e intuitivo. No hay una respuesta definitiva a su pregunta, ya que las personas tienen diferentes opiniones sobre este tema.

Espero que esto ayude.

El método utilizado para construir AlertDialog Object se llama Builder Pattern para mejorar la legibilidad. Cuando se quiere construir un nuevo objeto, pero este objeto requiere muchas propiedades para crearlo como demasiados parámetros (más de 4) pasando al constructor, se confunde. Si quieres saber más sobre el patrón constructor, creo que esta respuesta satisfará tus necesidades. La construcción de AlertDialog es bastante similar al ejemplo en el enlace:

 @Override public Dialog onCreateDialog(Bundle savedInstanceState) { return new AlertDialog.Builder(getActivity()) .setMessage("Do you really want to exit?") .setCancelable(false) .setNegativeButton("No", new DaialogInterface.onClickListener() { public void onClick(DialogInterface dialog, int id) { ((AlertDialogActivity) getActivity()) .continueShutdown(false); } }) .setPositibeButton("Yes", new DialogInterface.onClickListener()) { public void onClick( final DialogInterface dialog, int id) { ((AlertDialogActivity) getActivity()) .continueShutdown(true); } }).onCreate(); } 

Este método devuelve Objeto de diálogo que pregunta al usuario si desea salir de la aplicación, como puede ver, no tiene sentido crear un objeto AlertDialog llamando a un constructor con demasiados argumentos. Imagine si AlertDialog tiene tal constructor:

 AlertDialog ad = new AlertDialog(getActivity(), "Do you really want to exit?", false, "No", .... )//and the list goes on 

Comparar este enfoque con onCreateDialog método Creo que el método onCreateDialog gana derecho?