🚀 go-pugleaf

On 28 Feb 2018 21:08:45 GMT, Jorgen Grahn <grahn...@snipabacken.se>
wrote:

>On Tue, 2018-02-27, Gene Wirchenko wrote:
>> On Sun, 25 Feb 2018 19:17:36 +0000, Ahem A Rivet's Shot
>> <ste...@eircom.net> wrote:
>>
>> [snip]
>>
>>>	Most definitely, one of the more interesting variants comes from an
>>>approach common in the Java 'Enterprise' world where the aim is to put the
>>>complexity into the object structure of the program and not expose it in the
>>>code. This kind of code tends to have vast numbers of classes defined
>>>(many autogenerated or 90% autogenerated), most with names partly derived
>>>from a design patterns (FooDAO, FooInterface, FooImplemetation, FooListView,
>>>FooDetailView) and a flow of control that is almost impossible to find
>>>because it is *deliberately* hidden from view.
>>
>>      I bounced off the patterns book.  It seemed as if actually simply
>> instantiating a class was to be avoided.
>>
>>      Did I dodge a bullet?
>
>I think you did.

     I have been wondering.  I thought I made the right decision, but
any decision can be wrong.

>It seems to me most of the GoF patterns were about techniques for
>writing reusable libraries, using the tools available in Smalltalk
>(mostly inheritance).  For most code, it's simply not needed ... but
>a lot of people thought their job was to cram in as many patterns as
>possible in the code.

     Whereas I try to keep things simple.  I do not use very many
levels of classes.  Often, it is a services class that does a lot of
heavy lifting used by specific classes for the specific form or
report.

>No doubt many people still feel patterns are important, but there
>/was/ a backlash at some point.  And popular languages like Python and
>C++ are unlike Smalltalk, with standard libraries not based on
>patterns.

     I missed the backlash: too bad.

     I thank you for the reassurance.

Sincerely,

Gene Wirchenko