Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14622 > unrolled thread

Re: How is this "pattern" called?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How is this "pattern" called? Jim Janney <jjanney@shell.xmission.com> - 2012-05-18 10:03 -0600
    Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-18 10:50 -0700
      Re: How is this "pattern" called? markspace <-@.> - 2012-05-18 12:20 -0700
        Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-18 14:13 -0700
          Re: How is this "pattern" called? Patricia Shanahan <pats@acm.org> - 2012-05-18 14:35 -0700
            Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-18 15:29 -0700
              Re: How is this "pattern" called? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-19 22:38 -0400
                Re: How is this "pattern" called? Lew <noone@lewscanon.com> - 2012-05-20 11:34 -0700
                  Re: How is this "pattern" called? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-20 14:59 -0400
                  Re: How is this "pattern" called? Patricia Shanahan <pats@acm.org> - 2012-05-20 12:03 -0700
                  Re: How is this "pattern" called? markspace <-@.> - 2012-05-20 13:19 -0700
                  Re: How is this "pattern" called? Wanja Gayk <brixomatic@yahoo.com> - 2012-05-30 14:32 +0200
                    Re: How is this "pattern" called? Lew <noone@lewscanon.com> - 2012-06-02 09:25 -0700
                Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-20 20:40 -0700
                  Re: How is this "pattern" called? Wanja Gayk <brixomatic@yahoo.com> - 2012-05-30 14:33 +0200
            Re: How is this "pattern" called? Wanja Gayk <brixomatic@yahoo.com> - 2012-05-30 14:32 +0200
          Re: How is this "pattern" called? markspace <-@.> - 2012-05-18 15:28 -0700
          Re: How is this "pattern" called? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-19 22:37 -0400
            Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-20 20:43 -0700
              Re: How is this "pattern" called? Lew <noone@lewscanon.com> - 2012-05-21 00:09 -0700
                Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-21 10:04 -0700
              Re: How is this "pattern" called? Wanja Gayk <brixomatic@yahoo.com> - 2012-05-30 23:58 +0200
      Re: How is this "pattern" called? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-19 22:33 -0400
        Re: How is this "pattern" called? Gene Wirchenko <genew@ocis.net> - 2012-05-20 20:44 -0700
          Re: How is this "pattern" called? Lew <noone@lewscanon.com> - 2012-05-21 00:11 -0700

Page 1 of 2  [1] 2  Next page →

#14622 — 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

[toc] | [next] | [standalone]

#14626

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

[toc] | [prev] | [next] | [standalone]

#14629

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

>       a case of KISS or maybe YAGNI.


I like these too; good thoughts.

[toc] | [prev] | [next] | [standalone]

#14631

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

[toc] | [prev] | [next] | [standalone]

#14632

On 5/18/2012 2: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.  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.

I think a lot depends on the answer to one key question:

What is the cost if this needs to be changed?

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.

Patricia

[toc] | [prev] | [next] | [standalone]

#14635

On Fri, 18 May 2012 14:35:57 -0700, Patricia Shanahan <pats@acm.org>
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

[toc] | [prev] | [next] | [standalone]

#14670

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

[toc] | [prev] | [next] | [standalone]

#14677

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

[toc] | [prev] | [next] | [standalone]

#14680

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

[toc] | [prev] | [next] | [standalone]

#14681

On 5/20/2012 11:34 AM, Lew wrote:
...
> 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 think the terminology point is very important. Saying "This is a
Singleton class" conveys a lot of information very compactly.

I do flip through GoF when I am looking for ideas of how to structure
something. Often, either one of the patterns fits or at least the idea
behind the pattern is useful to me. It's a useful catalog of alternatives.

Patricia

[toc] | [prev] | [next] | [standalone]

#14683

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>

[toc] | [prev] | [next] | [standalone]

#14937

In article <jpbdfd$2rk$1@news.albasani.net>, noone@lewscanon.com says...
> 
> 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.
> 
[..]
> 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 guess that's one of the most common misconceptions. Some people seem 
to think that patterns are used, because they are considered cool and 
fancy. While in the real world you use any certain pattern because and 
only when it solves your problem.

I have seldomly seen a visitor pattern in the wild, because there are 
not so many occasions where it's so considerably better than something 
that is easier to understand to make it worth using.
But the strategy pattern is used everywhere, everytime you use a 
Comparator for example, simply because it solves a very common problem 
very well. 

Kind regards,
-Wanja-


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#15004

Wanja Gayk wrote:
> noone@lewscanon.com says...
>> 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.
>>
> [..]
>> 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 guess that's one of the most common misconceptions. Some people seem
> to think that patterns are used, because they are considered cool and
> fancy. While in the real world you use any certain pattern because and
> only when it solves your problem.
>
> I have seldomly seen a visitor pattern in the wild, because there are
> not so many occasions where it's so considerably better than something
> that is easier to understand to make it worth using.
> But the strategy pattern is used everywhere, everytime you use a
> Comparator for example, simply because it solves a very common problem
> very well.

Someone who has actually read up on patterns will find that every pattern 
document includes the motivation or scenarios for which the pattern applies. 
No pattern is claimed to be universally applicable, or offered as "cool", but 
always as relevant for a particular type of situation.

Part of knowing about patterns is learning to discern when one is useful and 
when it isn't.

Any competent programmer who claims not to use patterns is lying, or at best 
being disingenuous. One might not use them literally in the GoF style, but 
they are there. As others in this thread have pointed out, if you program for 
Swing or use almost anything in the standard API, you're using patterns even 
if only those imposed on you by the API writer (e.g., MVC). Patterns in the 
general sense are at the heart of effective programming. (Patterns in the 
formal, strictly GoF-imitative sense not so much.)
-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#14706

On Sat, 19 May 2012 22:38:04 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

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

     Consider the possibility that the need might not be there at all.
I need to do X.  I can do X simply with Y.  What need of patterns
then?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#14938

In article <96ejr7hcmgv68n2itnip55edo0cg97vj8a@4ax.com>, genew@ocis.net 
says...
> 
> On Sat, 19 May 2012 22:38:04 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
> 
> >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.
> 
>      Consider the possibility that the need might not be there at all.
> I need to do X.  I can do X simply with Y.  What need of patterns
> then?

Let me give you an example:

You copy and modify your sorting routine for each class you like to 
sort, everywhere you need it. Simple, easy, does it:

for (int i = 1; i < articles.size(); i++){
  int j = i;
  final Article actual= articles.get(i);
  while (j>0 && articles.get(j-1).getAmount() > actual.getAmount())){
   articles.set(j, articles.get(j-1));
   j--;
  }
  articles.set(j, actual);
 }

[..]

 for (int i = 1; i < articles.size(); i++){
  int j = i;
  final Article actual= articles.get(i);
  while (j>0 && articles.get(j-1).getPrice() > actual.getPrice())){
   articles.set(j, articles.get(j-1));
   j--;
  }
  articles.set(j, actual);
 }

It works, it is straightforward, so what?

If you use the strategy pattern and instead of copying and modifying the 
sorting routine, just have one sorting method in a utility class, that 
you need to call, provide it with a list and a comparison strategy 
(Comparator):

class SortUtil{
 public static <T> sort(final List<T> items, 
                        final Comparator<? super T> strategy){
  for (int i = 1; i < items.size(); i++){
   int j = i;
   final T actual= articles.get(i);
   while (j>0 && strategy.compare(items.get(j-1), actual) > 0){
    items.set(j, items.get(j-1));
    j--;
   }
   items.set(j, actual);
  }
 }
}

You then define your comparison strategy and put it somewhere where it's 
easy and intuive to find:

class Article{

 public static Comparator<Article> COMPARE_BY_AMOUNT
     = new Comparator<Article>(){
  public int compare(Article a, Article b){
   return a.getAmount() - b.getAmount(); //I know it stinks of overflow!
  }
 };

 [..]

  public static Comparator<Article> COMPARE_BY_PRICE
     = new Comparator<Article>(){
  public int compare(Article a, Article b){
   return (int)(a.getPrice() - b.getPrice()); //I know it stinks hard!

  }
 };
}

That might look complicated first, but there is a huge benefit:
Wherever you sort articles, the result is quite readable:

SortUtil.sort(articles, Article.COMPARE_BY_AMOUNT);
SortUtil.sort(articles, Article.COMPARE_BY_PRICE);

Yes, you can also have that if you have a lot of copied methods like 
this:
sortArticlesByAmountAsc(articles);
sortArticlesByPriceAsc(articles);

But the huge difference is: If you find an error in your sorting 
routine, or if you want to change your sorting routine from insertin 
sort to quicksort, you only need to fix it in one place and every code 
that ises it will be fixed and sped up immediately.

You don't need to hunt down every copy that you have made (you will 
forget one for sure) and apply the same change to all of them (you will 
make a mistake somewhere). And since code evolves the fix might look 
different everywhere, so searching for the code you need to change is 
doomed to miss some occurrences.

Also you can easily re-use the comparison strategy, because is not 
buried under a load of sorting loopcode, but seperate from it. You can 
use it to compare two articles:

if(Article.COMPARE_BY_PRICE.compare(a1, a2)){
 highlightError(articleChoiceA);
}

Now imagine your code review shows that the code stinks as the price is 
of type "double", and you need to change that for "BigDecimal", then you 
can fix the Comparator once and every part of your code that uses it  
instantly works - so you have saved yourself a lot of time.
You did not need to hund down every sort routine you have copied and 
modified, not even search for the compiler errors in simple if-clauses 
where you had a < > operator first.

And since you know the Java-API, you also know that Collections.sort() 
was built the same way. For a good reason.

Kind regards,
-Wanja-

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#14936

In article <z_CdncDz595QXSvSnZ2dnUVZ_tOdnZ2d@earthlink.com>, 
pats@acm.org says...

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

It's rather two questions:

1. What is the cost if this needs to be changed?
2. What are the chances that we need to change this?

If the chances are low it can be more expensive. If the chances are 
high, because this part is important, you better be flexible.

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

Absolutely.

Kind regards,
-Wanja-

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#14634

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.

[toc] | [prev] | [next] | [standalone]

#14669

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

[toc] | [prev] | [next] | [standalone]

#14707

On Sat, 19 May 2012 22:37:07 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

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

     You are missing the possibility that they are not needed.  I do
not like overcomplicating my code.  I like to keep it simple since I
am probably the one who will have to modify it in the future.

     If a pattern works for me, fine, I will use it.  If I do not need
it, then I will not use it.

     I am not against patterns; I am against their use everywhere
regardless of circumstances.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#14715

Gene Wirchenko wrote:
> Arne Vajhøj wrote:
>> Gene Wirchenko wrote:
>>> markspace wrote:
>>>> 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.
>
>       You are missing the possibility that they are not needed.  I do
> not like overcomplicating my code.  I like to keep it simple since I
> am probably the one who will have to modify it in the future.
>
>       If a pattern works for me, fine, I will use it.  If I do not need
> it, then I will not use it.
>
>       I am not against patterns; I am against their use everywhere
> regardless of circumstances.
>
> [snip]

A 'for' loop is a pattern. A 'try-catch' idiom that reliably closes an 
external resource (e.g., 'Reader' or 'Writer') in the same way each time you 
write one is a pattern. Putting your member declarations in a certain order is 
a pattern. Are you seriously suggesting that you have written non-trivial code 
that is devoid of patterns?

If so, you are lying.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web