Re: How is this "pattern" called?

final class Main
{
  /* model */

  final private java.util.Collection<java.awt.Point> collection
   = new java.util.ArrayList<>();

  /* view */

  Panel panel;
  final private class Panel extends javax.swing.JPanel
  { public Panel()
    { this.setPreferredSize( new java.awt.Dimension( 300, 300 ));
      this.addMouseListener( new MouseListener() ); }
    final @java.lang.Override public void paintComponent
    ( final java.awt.Graphics graphics )
    { super.paintComponent( graphics );
      for( final java.awt.Point point : Main.this.collection )
      graphics.fillRect( point.x, point.y, 4, 4 ); }}

  final private class Frame extends javax.swing.JFrame
  { Frame()
    { Main.this.panel = new Panel(); this.add( Main.this.panel );
      this.setDefaultCloseOperation
      ( javax.swing.WindowConstants.DISPOSE_ON_CLOSE );
      this.pack(); this.setVisible( true ); }
    final @java.lang.Override public void dispose(){ super.dispose(); }}

  /* controller */

  final private class MouseListener extends java.awt.event.MouseAdapter
  { public final void mousePressed
    ( final java.awt.event.MouseEvent mouseEvent )
    { Main.this.collection.add
      ( new java.awt.Point( mouseEvent.getX(), mouseEvent.getY() ));
      Main.this.panel.repaint(); }}

  public final java.lang.Runnable buildGui = new java.lang.Runnable()
  { @java.lang.Override public final void run(){ new Frame(); }};

  public final void buildGui()
  { java.awt.EventQueue.invokeLater( this.buildGui ); }

  public static void main( final java.lang.String args[] )
  { new Main().buildGui(); }}

  I do not see a real problem with this style, assuming that
  the assignment at hand was just to write such a simple dot
  paint program.

  The inner classes can easily share a common model and
  identifier scope, while at the same time there is some
  reasonable separation between the different concerns
  of the inner classes.

  Should it be required later to decouple one of these inner
  classes more than now, this is also possible using a
  refactor that will make it become an outer class or will
  introduce an observer relationship. But should it not
  be required later, no time is wasted now to implement a
  decoupling and separation not needed.