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.