Question: How can I reload a ListView from inside an AlertDialog? This AlertDialog is spawned by a ContectMenu.

```
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    registerForContextMenu(getListView());
    ......
    MatrixCursor cursor;
    cursor = NameManager.getnameList();
    ........
    final SimpleCursorAdapter adapter = new SimpleCursorAdapter(this,
            R.layout.row, cursor, from, to);
    setListAdapter(adapter);
}
.......
.......
case R.id.delete:
            new AlertDialog.Builder(this)
            .setTitle("Delete " + cursor.getString(1))
            .setMessage("Are you sure?")
            .setPositiveButton("Ok",
                    new DialogInterface.OnClickListener() {
                @Override
                public void onClick(
                        DialogInterface dialogInterface, int i) {
                    try {
                        .......
                        // TODO reload listview

                    } catch (IOException e) {
                        e.printStackTrace();
                        return;
                    }
                }
            }).setNeutralButton("Cancel", null)
            .create().show();
            return true;

```

Answer: 
I would go with the second, "Have a really long superclass constructor." If we follow the approach detailed in the [question you referenced](https://stackoverflow.com/questions/2327509/abstract-class-with-final-uninitialized-field), the superclass constructor is `protected` and not meant to be called by anything external to the class hierarchy or package. My feeling always is, once something is not exposed beyond that boundary - i.e., is not part of the "API" as it were - then it doesn't matter what it looks like. Let it have eight different parameters of varying types, or even more. Yes, it's visible from within the package, but it's clear from the original solution that that constructor is not meant to be called by anything other than the subclasses. That's another motivation for non-`public` visibility. 

Of course, your instincts for doing something cleaner are correct when it comes to `public` stuff. The fact that you asked this question at all shows you have the right instincts.
When I have a need for an immutable object (all members are final) that takes many different parameters in the constructor I usually use a Builder pattern.

In this case you can make the builders subclass each other and in this way you will still maintain the ability to extend.

For an example you can see the Guava API for ImmutableCollection [Builder](http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/ImmutableCollection.Builder.html).
Or if you don't require immutability, here is an example of [CacheBuilder](http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/cache/CacheBuilder.html) also taken from the same library:

```
Cache<Key, Graph> graphs = CacheBuilder.newBuilder()
   .concurrencyLevel(4)
   .weakKeys()
   .maximumSize(10000)
   .expireAfterWrite(10, TimeUnit.MINUTES)
   .build(
       new CacheLoader<Key, Graph>() {
         public Graph load(Key key) throws AnyException {
           return createExpensiveGraph(key);
         }
       });

```

As you can see the use of a builder replaces the need to pass in 6 parameters in the constructor and makes for more readable/usable code.

If you still don't want to use builders I would go with option (3) as that will prevent some of the hassle of maintaining a very long constructor