[AccessD] AccessD Digest, Vol 98, Issue 7

<<< I doubt seriously that anyone uses your paradigm in .net. >>>

http://fsharp.net ?

--
Shamil
 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: 12 ?????? 2011 ?. 0:36
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] AccessD Digest, Vol 98, Issue 7

 > I haven't found a reason why classes can't rely on properly crafted and
tested module-level functions.

Do you program in .Net?  Everything is an object.  There is no "module",
though there can be static classes / functions.  I haven't done a poll, but
I doubt seriously that anyone uses your paradigm in .net.

John W. Colby
www.ColbyConsulting.com

On 4/11/2011 4:09 PM, Kenneth Ismert wrote:
> John,
>
> I understand the reasoning and all however... because the code is no 
> longer
>> contained within the object that needs it, you now open yourself up 
>> to the old "I need to modify this method... oops... that change 
>> breaks something else that uses the code".
>>
>
> It is always possible to over-factor, and merge two similar pieces of 
> code together that really should be separate. In that case, you factor 
> the code back into multiple pieces, and correct the dependencies.
>
>
>> Class programming exists for a reason.  Placing code in the object 
>> that needs the code exists for a reason.  Black box programming 
>> exists for a reason.  The reason in many cases is to prevent exactly 
>> this kind of interaction when we accidentally change a piece of code 
>> used in many places and break one of those places.
>>
>
> I would submit that calling side-effect free functions from a class 
> does not pierce the black box. The important things, state and access, 
> are protected by the class. But the function can be anywhere: built-in 
> VBA functions, Access application methods, or DAO library calls. You 
> undoubtedly call these functions from within your classes.
>
>
>> Yes, there are instances where lots of different things need the 
>> exact same code, and yes, I have been known to call module functions 
>> from classes, but it truly is a questionable practice in most cases.
>>
>
> Test cases replace questionability with a guarantee of proper 
> function. The function shouldn't define what it does -- the test cases 
> should. If changes to a function break a test, then you know 
> immediately that there is a problem. Functional unit testing guards 
> against changes that would break dependent code.
>
> I haven't found a reason why classes can't rely on properly crafted 
> and tested module-level functions.
>
> -Ken
>
>
>>
>> John W. Colby
>> www.ColbyConsulting.com
>>
>> On 4/11/2011 1:10 PM, Kenneth Ismert wrote:
>>
>>> John, All:
>>>
>>> I'm going to expand a little on what I'm trying to get at. This post 
>>> really isn't advice on what you should do. And it certainly isn't 
>>> criticism.
>>>
>>> I have been returning to the old Lisp idea of functional programming:
>>> libraries of functions that act only on their inputs and only return 
>>> a result. The goal is 'side-effect-free' -- inputs are NEVER 
>>> modified, and external variables are never referenced. If a function 
>>> needs to return complex information, it returns either a type or an 
>>> object. Database functions unavoidably have side-effects, but these 
>>> are regarded as 'external' to the code, and are explicitly documented.
>>>
>>> The thing that surprised me was how well libraries play with objects.
>>> Libraries provide discrete, testable chunks of code that support any 
>>> instance. Libraries separate functions into common-sense groups. 
>>> Classes provide an instance wrapper over the libraries, stringing 
>>> functions together to support the application.
>>>
>>> Plus, it is pretty easy to convert classes to this scheme while 
>>> maintaining compatibility.
>>>
>>> The advantages became apparent when I refactored some of my early 
>>> monolithic classes. These large, 'kitchen sink' classes had dozens 
>>> of methods which mixed database, business, and application 
>>> functionality. They were unwieldy, hard-to-understand, and 
>>> hard-to-extend. I simply copied the class into a module, stripped 
>>> out the instance stuff (properties and module-level variables), and 
>>> turned the methods into side-effect-free functions. I then stripped 
>>> out the code within the original class methods, turning them into 
>>> wrappers calling library functions with their instance variables.
>>>
>>> The result: classes become lightweight, making their functionality 
>>> much more obvious. Compatibility is maintained, but the new system 
>>> is much easier to refactor and extend.
>>>
>>> The class on-top-of function approach is also a good answer to those 
>>> who want to re-use your code, but can't because they need some 
>>> method that is marked private in a class. They typically demand that 
>>> all methods be made public, which is usually silly because the class 
>>> designer has good reasons for limiting the public visibility of certain
methods or properties.
>>>
>>> But with a function library, you can have your cake and eat it, too.
>>> Classes
>>> hold the instance information, and interact with libraries in an 
>>> instance-safe way, because the functions never modify their inputs. 
>>> Others with different needs can call the functions directly, or 
>>> write their own classes. Heck, I even find myself cramped by my own 
>>> classes at times, and having the option to call underlying functions
directly has benefited me.
>>>
>>> Writing test code for functions is much easier than for complex 
>>> class systems. Test code provides reasonable proof of reliability.  
>>> Reliable complexity can only be built out of small, simple, 
>>> understandable, and testable pieces.
>>>
>>> -Ken
>>>
>>>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com