How is this "pattern" called?
 

In the MVC pattern, I think, M, V, and C should be at least
one non-innner class each?

I often have seen (possibly, especially in beginner code) a
coding pattern, where there is only one single non-inner class:
the model.

The listeners and the view then are embedded into this
model, possibly, as inner classes. It's not really MVC
as the observer pattern is not used for decoupling.

So, to code a simple Java-GUI application, one just writes
a single class with the model and the controllers as inner
classes and no observer pattern for model-view decoupling.
Is there a name for this simple design?

What about »the bulk-class pattern«? Or »the naive GUI pattern«?

Re: How is this "pattern" called?
 

On 5/18/2012 1:53 AM, Stefan Ram wrote:
> In the MVC pattern, I think, M, V, and C should be at least
> one non-innner class each?
>
> I often have seen (possibly, especially in beginner code) a
> coding pattern, where there is only one single non-inner class:
> the model.


"Especially in beginner code" seems to say to me that they might be
copying from beginner examples, especially of the sort that appear in
Oracle's Java tutorial. These example are designed to be shorter to
read on a web page or book page, and don't show best practice or correct
pattern. The examples simply show how to use the API.

Also, MVC is not MVC. That is, most languages and frameworks use a
modified MVC that really isn't MVC. Java itself uses a "split model"
design pattern. Model-Presenter-Controller is currently a popular
design pattern which can be used in Java.

<http://www.martinfowler.com/eaaDev/uiArchs.html>


>
> The listeners and the view then are embedded into this
> model, possibly, as inner classes. It's not really MVC
> as the observer pattern is not used for decoupling.


"Close coupling" is an anti-pattern in most cases.

Do you have an example we could look at?

Re: How is this "pattern" called?
 

On 5/18/2012 8:29 AM, markspace wrote:
> design pattern. Model-Presenter-Controller is currently a popular design


Argh. Model-View-Presenter. How did I mix those up?

Re: How is this "pattern" called?
 

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> In the MVC pattern, I think, M, V, and C should be at least
> one non-innner class each?
>
> I often have seen (possibly, especially in beginner code) a
> coding pattern, where there is only one single non-inner class:
> the model.
>
> The listeners and the view then are embedded into this
> model, possibly, as inner classes. It's not really MVC
> as the observer pattern is not used for decoupling.
>
> So, to code a simple Java-GUI application, one just writes
> a single class with the model and the controllers as inner
> classes and no observer pattern for model-view decoupling.
> Is there a name for this simple design?
>
> What about »the bulk-class pattern«? Or »the naive GUI pattern«?

Big Ball of Mud seems to fit:

http://laputan.org/mud/

--
Jim Janney

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.

Re: How is this "pattern" called?
 

On 5/18/2012 9:59 AM, Stefan Ram wrote:

> 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.


Right, though the style doesn't particularly teach best practice either.

I think I'd call this the "monolithic example" pattern. It's similar to
a lot of example code I see in books and the Java tutorial. It's
monolithic because it crams everything into a single class, or at least
into the minimum page space.

And it's an example because that's what it is. A short program that
isn't written by more than one person, and will not be maintained. It's
fine for what it is, but it's not an example of good production style
coding either.

Re: How is this "pattern" called?
 

On Fri, 18 May 2012 10:03:04 -0600, Jim Janney
<jjanney@shell.xmission.com> wrote:

>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> In the MVC pattern, I think, M, V, and C should be at least
>> one non-innner class each?
>>
>> I often have seen (possibly, especially in beginner code) a
>> coding pattern, where there is only one single non-inner class:
>> the model.

Beginner code does tend to be for a small system.

>> The listeners and the view then are embedded into this
>> model, possibly, as inner classes. It's not really MVC
>> as the observer pattern is not used for decoupling.
>>
>> So, to code a simple Java-GUI application, one just writes
>> a single class with the model and the controllers as inner
>> classes and no observer pattern for model-view decoupling.
>> Is there a name for this simple design?

How about "KISS"?

>> What about »the bulk-class pattern«? Or »the naive GUI pattern«?
>
>Big Ball of Mud seems to fit:
>
>http://laputan.org/mud/

If the ball is not big, then it is a case of KISS or maybe YAGNI.

There is little sense in using large system methodology on a
small system. (Do watch though that you do not keep adding to a small
system and switch over to having a large system wihtout realising it.)

Sincerely,

Gene Wirchenko

Re: How is this "pattern" called?
 

On 5/18/2012 10:50 AM, Gene Wirchenko wrote:

> a case of KISS or maybe YAGNI.


I like these too; good thoughts.

Re: How is this "pattern" called?
 

In article <MVC-20120518183901@ram.dialup.fu-berlin.de>,
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> 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.

I sometimes strive to make nested classes static in order to facilitate
re-factoring, as suggested in the example below. Static also keeps me
honest on inadvertent coupling. I also use the somewhat dated Observer
and Observable classes to stress the observer pattern, even implementing
Observer despite leaking `this`.

Here's my understanding of the basic architecture:

<http://stackoverflow.com/a/2687871/230513>

Here's a more elaborate example that mentions other ways to implement
the observer pattern:

<http://stackoverflow.com/a/3072979/230513>

And I frequently refer to this article on Swing & MVC

<http://java.sun.com/products/jfc/tsc/articles/architecture/>

import java.awt.Color;
import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.Graphics;
import java.awt.Point;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import java.util.ArrayList;
import java.util.List;
import java.util.Observable;
import java.util.Observer;
import javax.swing.JFrame;
import javax.swing.JPanel;

public class MVCMain {

public static void main(String args[]) {
new MVCMain().buildGui();
}

public void buildGui() {
EventQueue.invokeLater(new Runnable() {

@Override
public void run() {
Model model = new Model();
View view = new View(model);
Control control = new Control(model, view);
JFrame f = new JFrame();
f.add(view);
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.pack();
f.setLocationRelativeTo(null);
f.setVisible(true);
}
});
}

private static final class Model extends Observable {

private List<Point> points = new ArrayList<Point>();

public void next(Point p) {
points.add(p);
setChanged();
notifyObservers();
}

public List<Point> getPoints() {
return points;
}
}

private static final class View extends JPanel implements Observer {

private Model model;

public View(Model model) {
this.model = model;
this.model.addObserver(this);
}

@Override
public void paintComponent(Graphics g) {
super.paintComponent(g);
g.setColor(Color.blue);
for (Point p : model.getPoints()) {
g.fillRect(p.x, p.y, 8, 8);
}
}

@Override
public Dimension getPreferredSize() {
return new Dimension(300, 300);
}

@Override
public void update(Observable o, Object arg) {
repaint();
}
}

private static final class Control {

private Model model;
private View view;

public Control(final Model model, View view) {
this.model = model;
this.view = view;
this.view.addMouseListener(new MouseAdapter() {

@Override
public void mousePressed(MouseEvent e) {
model.next(e.getPoint());
}
});
}
}
}

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: How is this "pattern" called?
 

On Fri, 18 May 2012 12:20:11 -0700, markspace <-@.> wrote:

>On 5/18/2012 10:50 AM, Gene Wirchenko wrote:
>
>> a case of KISS or maybe YAGNI.

>I like these too; good thoughts.

I have tended to avoid using OOP patterns except for what I came
up with myself. I did try reading one of the OOP patterns books, but
ugh! Some people seem to think that the last thing you should is do
in OOP is write a statement that actually instantiates an object.
(Qual horreur!) Instead, you call a factory -- is that it? -- and
have all sorts of indirection.

If you *really* need that, fine, but I do not. The closest that
I have come to this is related classes needing common code. I have
them inherit from a class with that code. That code class is never
instantiated itself.

With all of the hoopla over OOP patterns, it is difficult for me
to tell how much they are really needed.

Yes, I go for keeping it fairly simple.

Sincerely,

Gene Wirchenko