How is this "pattern" called?

Discussion in 'Java' started by Stefan Ram, May 18, 2012.

  1. Stefan Ram

    Stefan Ram Guest

    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«?
     
    Stefan Ram, May 18, 2012
    #1
    1. Advertising

  2. Stefan Ram

    markspace Guest

    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?
     
    markspace, May 18, 2012
    #2
    1. Advertising

  3. Stefan Ram

    markspace Guest

    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?
     
    markspace, May 18, 2012
    #3
  4. Stefan Ram

    Jim Janney Guest

    -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
     
    Jim Janney, May 18, 2012
    #4
  5. Stefan Ram

    Stefan Ram Guest

    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.
     
    Stefan Ram, May 18, 2012
    #5
  6. Stefan Ram

    markspace Guest

    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.
     
    markspace, May 18, 2012
    #6
  7. On Fri, 18 May 2012 10:03:04 -0600, Jim Janney
    <> wrote:

    >-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
     
    Gene Wirchenko, May 18, 2012
    #7
  8. Stefan Ram

    markspace Guest

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

    > a case of KISS or maybe YAGNI.



    I like these too; good thoughts.
     
    markspace, May 18, 2012
    #8
  9. In article <-berlin.de>,
    -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>
     
    John B. Matthews, May 18, 2012
    #9
  10. 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
     
    Gene Wirchenko, May 18, 2012
    #10
  11. Stefan Ram

    markspace Guest

    On 5/18/2012 2:13 PM, Gene Wirchenko wrote:

    >
    > 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!
    > ...
    > If you *really* need that, fine, but I do not.



    To me, this is the key part here. If you actually get the Gang of Four
    book on patterns and read it -- and I mean read ALL of it, starting with
    the front inside cover -- it says in the *introduction* not to use the
    patterns exactly as presented, but to modify them to your particular
    requirements. Patterns are there for you to get ideas from, but they
    are not laws that must be followed with out deviation. You're still
    required to think when using any given pattern.

    In addition, with each pattern (that I've read, at least), the GOF
    include a list of pro's and con's, and sometimes the cons are quite
    surprising. For example the Visitor pattern doesn't work well when the
    nodes/tree to traverse under goes lots of changes. The reason is that
    the Visitor pattern isolates the implementation for each node, and it
    can be a pain to go back into each implementation and add code for each
    new type of node. They recommend not using the Visitor pattern at all
    in this circumstance. Just use polymorphism and add the visitor API to
    each node directly.

    *That* is the biggest advantage to patterns and their study, imo. NOT
    "rah rah yay patterns" but telling you when using a pattern might leave
    you up a creek with no paddle. It allows you to eliminate a broad swath
    of design space quickly and points you in a better direction.
     
    markspace, May 18, 2012
    #11
  12. On Fri, 18 May 2012 14:35:57 -0700, Patricia Shanahan <>
    wrote:

    >On 5/18/2012 2:13 PM, Gene Wirchenko wrote:


    [snip]

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

    >
    >I think a lot depends on the answer to one key question:
    >
    >What is the cost if this needs to be changed?


    Exactly.

    >If we are talking about a widely distributed API, where a change will
    >break thousands of programs, it is worth doing a lot to minimize the
    >risk of incompatible change. If we are talking about code that is used
    >in a couple of places in one program, KISS and refactor if necessary.


    I quite agree with you.

    With the amount of noise over patterns though, you would think
    that many people need the patterns. For me, supporting an in-house
    application, there is no or little need. I suspect that there are
    many in my situation.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, May 18, 2012
    #12
  13. Stefan Ram

    Arne Vajhøj Guest

    On 5/18/2012 4:53 AM, Stefan Ram wrote:
    > In the MVC pattern, I think, M, V, and C should be at least
    > one non-innner class each?


    Yes.

    Although sometimes the V is not a class but JSP/XHTML/FXML.

    > 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«?


    I prefer "the big mess pattern".

    :)

    Arne
     
    Arne Vajhøj, May 20, 2012
    #13
  14. Stefan Ram

    Arne Vajhøj Guest

    On 5/18/2012 12:59 PM, Stefan Ram wrote:
    > 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.


    From a theoretical point of view V and C are not part of M.

    From the practical point of view the pattern (combined with
    your non standard formatting) ensures that it takes 10
    times longer to read and understand the code.

    Arne
     
    Arne Vajhøj, May 20, 2012
    #14
  15. Stefan Ram

    Arne Vajhøj Guest

    On 5/18/2012 1:50 PM, Gene Wirchenko wrote:
    > On Fri, 18 May 2012 10:03:04 -0600, Jim Janney
    > <> wrote:
    >> -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.)


    True.

    But separation of M, V and C seems to become relevant when
    passing the 500 LOC mark.

    Arne
     
    Arne Vajhøj, May 20, 2012
    #15
  16. Stefan Ram

    Arne Vajhøj Guest

    On 5/18/2012 5:13 PM, Gene Wirchenko wrote:
    > 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.


    That means that either you are absolute brilliant or a fool
    not to learn from other.

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


    ????

    There are plenty of new'ing in patterns.

    Some patterns with the purpose of making the client code
    use different implementations use factories. Obviously since
    new does not meet the requirement for enabling the use of
    different implementations.

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


    Almost all Java code uses various well defined patterns. Large parts
    of both Java SE and Java EE uses them.

    Arne
     
    Arne Vajhøj, May 20, 2012
    #16
  17. Stefan Ram

    Arne Vajhøj Guest

    On 5/18/2012 6:29 PM, Gene Wirchenko wrote:
    > With the amount of noise over patterns though, you would think
    > that many people need the patterns. For me, supporting an in-house
    > application, there is no or little need.


    Or you have not realized the need.

    Arne
     
    Arne Vajhøj, May 20, 2012
    #17
  18. Stefan Ram

    Lew Guest

    Arne Vajhøj wrote:
    > Gene Wirchenko wrote:
    >> With the amount of noise over patterns though, you would think
    >> that many people need the patterns. For me, supporting an in-house
    >> application, there is no or little need.

    >
    > Or you have not realized the need.



    Or both of you are looking at it from the wrong perspective.

    I would bet that both of you use "patterns" in the larger, non-buzzwordy
    sense, that is, you recognize the shape of structures in your model and can
    exploit common idioms for common shapes. Both of you appear to be competent
    programmers from what this newsgroup shows, and programmers become competent
    only if they have that skill.

    The argument is over "patterns" in the GoF sense, a highly bureaucratized,
    overly-verbose and religiously canonical set of labels and formats to describe
    them. But even amidst all the sturm und drang over the latter kind of
    patterns, they provide value in a common terminology and informal use. So when
    we discuss Visitor or Singleton, we all know what we mean. ("We" being
    competent programmers. One occasionally sees posters here who are less
    knowledgeable.)

    I favor having a library of common pattern labels to facilitate both
    communication and program design. No one should think that the list in
    GoF-land is exhaustive, and certainly not mandatory. Just because you haven't
    used one of the patterns from the Official List doesn't mean you don't need
    patterns, or don't use them.

    The point of the Official List is to identify some (only some!) of the most
    common patterns and get us used to thinking in terms of patterns, not to be
    set upon an altar and have thurifers waved at them.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 20, 2012
    #18
  19. On 5/20/2012 2:34 PM, Lew wrote:
    > Arne Vajhøj wrote:
    >> Gene Wirchenko wrote:
    >>> With the amount of noise over patterns though, you would think
    >>> that many people need the patterns. For me, supporting an in-house
    >>> application, there is no or little need.

    >>
    >> Or you have not realized the need.

    >
    > Or both of you are looking at it from the wrong perspective.
    >
    > I would bet that both of you use "patterns" in the larger, non-buzzwordy
    > sense, that is, you recognize the shape of structures in your model and
    > can exploit common idioms for common shapes. Both of you appear to be
    > competent programmers from what this newsgroup shows, and programmers
    > become competent only if they have that skill.
    >
    > The argument is over "patterns" in the GoF sense, a highly
    > bureaucratized, overly-verbose and religiously canonical set of labels
    > and formats to describe them. But even amidst all the sturm und drang
    > over the latter kind of patterns, they provide value in a common
    > terminology and informal use. So when we discuss Visitor or Singleton,
    > we all know what we mean. ("We" being competent programmers. One
    > occasionally sees posters here who are less knowledgeable.)
    >
    > I favor having a library of common pattern labels to facilitate both
    > communication and program design. No one should think that the list in
    > GoF-land is exhaustive, and certainly not mandatory. Just because you
    > haven't used one of the patterns from the Official List doesn't mean you
    > don't need patterns, or don't use them.
    >
    > The point of the Official List is to identify some (only some!) of the
    > most common patterns and get us used to thinking in terms of patterns,
    > not to be set upon an altar and have thurifers waved at them.


    ????

    I don't think anyone suggested to treat patterns religiously. What is
    it that you call arguments against something that no one has actually
    suggested?

    There are no official list. There are multiple lists: GoF which
    are somewhat general OOP, specific Java EE etc..

    The common terminology is one of the benefits.

    The other big benefit is to learn from others experience instead
    of spending a decade or more to learn it the hard way. That point
    is actual very much emphasized in the GoF book.

    Arne
     
    Arne Vajhøj, May 20, 2012
    #19
  20. Stefan Ram

    markspace Guest

    On 5/20/2012 11:34 AM, Lew wrote:
    > No one should think that the list in
    > GoF-land is exhaustive, and certainly not mandatory.



    I'm sure no one does. In support of this idea, I'll offer a couple of
    good finds by Y.T. First, xUnit Test Patterns by Meszaros, an absolute
    seminal work on test patterns for all you TDDers out there.

    <http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054>

    The other is Refactoring by Martin Fowler. It's organized as patterns
    of change, ways that you can modify your code to improve it. The
    organization into is useful because it gives each type of change an
    distinct and succinct name, which facilitates communication. For
    example, several of Fowler's patterns appear on the NetBeans "Refactor"
    menu, and do exactly what he describes.

    <http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672>
     
    markspace, May 20, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Apricot
    Replies:
    4
    Views:
    562
    velthuijsen
    Apr 16, 2004
  2. Weng Tianxiang
    Replies:
    6
    Views:
    606
    glen herrmannsfeldt
    Sep 12, 2007
  3. S_K
    Replies:
    6
    Views:
    1,255
    Robert Dunlop
    Nov 8, 2007
  4. Jimmy Hartzell
    Replies:
    0
    Views:
    440
    Jimmy Hartzell
    May 19, 2008
  5. Jimmy Hartzell
    Replies:
    2
    Views:
    1,185
    Jimmy Hartzell
    May 20, 2008
Loading...

Share This Page