| To: | <esumerfd@xxxxxxxxxxxxxx>, <users@xxxxxxxxxx> |
|---|---|
| Subject: | RE: [cinjug-users] Brandan Jones Presentation |
| From: | "Forsythe, Brian" <Brian.Forsythe@xxxxxxxxxxxxxxxxxxxxxxxx> |
| Date: | Wed, 18 Oct 2006 12:57:55 -0400 |
| Delivered-to: | mailing list users@cinjug.org |
| Mailing-list: | contact users-help@cinjug.org; run by ezmlm |
| References: | <E7BB966639B3C447A88EC8C545B727DD05577269@im02> <6a216ba20610180804h7deb28bk2945f6a58b615863@mail.gmail.com> |
| Thread-index: | Acbyxwu1EmBCydrmSde3L+lzuJPhzgAD4Kh6 |
| Thread-topic: | [cinjug-users] Brandan Jones Presentation |
I concur in spirit, though I think it better to recognize "helper classes/methods" as an antipattern than to remove them from our vocabulary. (Better the devil you know...) ________________________________ As a side note, the term "helper" should be eradicated from our dictionary. All features need to be implemented in a domain appropriate class to optimize reusability and flexibility. Helper classes are like constant classes, they serve as the procedural programmers dumping ground for stuff that they can't work where to put it. You used the term differently in that you intend methods to go in those classes. It is just a distasteful term. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [cinjug-users] Brandan Jones Presentation, inmanjon |
|---|---|
| Next by Date: | [cinjug-users] Helper classes, Abdul Habra |
| Previous by Thread: | Re: [cinjug-users] Brandan Jones Presentation, Edward Sumerfield |
| Next by Thread: | [cinjug-users] Helper classes, Abdul Habra |
| Indexes: | [Date] [Thread] [Top] [All Lists] |