How is this "pattern" called?

[Gene Wirchenko]

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

 

[Gene Wirchenko]

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

 

[Gene Wirchenko]

On 5/18/2012 1:50 PM, Gene Wirchenko wrote:
[snip]

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.

See? You agree with me. Different sizes of systems need
different methodologies.

Sincerely,

Gene Wirchenko

 

[Lew]

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]

Gene Wirchenko wrote:
[snip]

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.

See? You agree with me. Different sizes of systems need
different methodologies.

Two smart people agree on something that is true. Amazing.

 

[Gene Wirchenko]

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?

I have been referring to OOP patterns.

If so, you are lying.

More than a bit strong of language.

Sincerely,

Gene Wirchenko

 

[Lew]

(e-mail address removed) says...

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