[AccessD] Access XP forms bound to ADO recordsets

Shamil Salakhetdinov shamil at users.mns.ru
Tue Mar 28 04:09:03 CST 2006


> Is it simply to force compliance with the selected interface
John,

For this thread practical testing task 
(http://smsconsulting.spb.ru/download/tests/a2dds.htm) interfaces(Implements 
feature) is used to:

- have clearly defined interfaces to bind a form to its datasource(s) and to 
have this form communicating with custom class(es) handling runtime events;
- have prepared "socket interfaces"/pluggable test-bed to easily substitute 
one solution's code with the others. This substitution can be done 
dynamically(on run-time) or statically(on design time).

I don't have a good web page link to read on interfaces(Implements feature).
This concept of (abstract) interfaces has many practical applications.
On the other hand there is a lot of hype around it.
And there are different opinions is this concept good(has more positive 
effect) or bad(has almost only negative effect) in solving everyday tasks of 
practical programming especially in custom programming of (relatively 
simple) tasks for small-/middle-size businesses.

>From "rocket computer science" point of view interfaces are the base to 
implement in practice a subset of what is called also "Liskov Principle" ( 
http://en.wikipedia.org/wiki/Liskov_substitution_principle) and its 
consequence "don't talk to stranger" OOP principle - the "Law of Demeter" - 
http://www.site.uottawa.ca:4321/oose/index.html#LawofDemeter

My own understanding of these concepts and their applicability  in practical 
tasks fluctuates with time.
But only in positive spectrum part of opinions.
And I see more and more practical applications of this concept.
And especially in programming for small-/middle-size businesses or 
programming shareware tools - this is the market(IMO) which urge for agile 
eXtreme Programming(XP) and Test Driven Development (TDD) as one of the most 
powerful and flexible practical methods of XP. And the interfaces are a 
corner stone concept of TDD and code refactoring in its modern 
understanding - http://martinfowler.com/.

The best book (IMO) I have ever read on such advanced concepts is "Object 
Thinking" by David West (http://www.techbookreport.com/tbr0083.html) - "a 
kind of philosophical journey towards an understanding of 'object 
thinking."...

The best practical books to get broad vision on this concept and to see real 
samples are collected here I think 
(http://www.awprofessional.com/series/series.asp?st=44117&rl=1) - I have 
just found it.

Here is one of my exersizes - 
http://smsconsulting.spb.ru/patterns/labs/ObserverPatternLab.htm ...

Here is a very quick introduction to OOP concepts including interfaces - 
http://java.sun.com/docs/books/tutorial/java/concepts/

"All that jazz"/buzz of the modern understanding of programming has got a 
lot from the  works of Christopher Alexander 
(http://www.greatbuildings.com/architects/Christopher_Alexander.html), 
Smalltalk community and from the work of GoF("Gang of Four" - Erich Gamma, 
Richard Helm, Ralph Johnson, John M. Vlissides) - "Design Patterns: Elements 
of Reusable Object-Oriented Software" 
http://www.awprofessional.com/bookstore/product.asp?isbn=0201633612&rl=1 and 
their followers as well as from the works/books of Kent Beck - "Embrace 
change","Test Driven Development by Example" etc. 
(http://search.barnesandnoble.com/booksearch/isbninquiry.asp?z=y&pwb=1&ean=9780321278654)

That my e-mail may look a little bit more theoretical than practical - I 
wanted to outline by that not my "shift" to theoretical computer 
science/programming but my opinion that a modern advanced programmer has to 
have a broad vision/broad context picture of what are all that nowadays 
OOA&D principles, what associations they are based on and where they go...

As a conclusion I must say I didn't read even a half of the sources/books I 
referred above - I just compiled their list now as a reply on your question 
:)
If I ever had an opportunity for half an year paid vacations (dreams, 
dreams...) I'd spend the first part in lazy doing nothing and the second 
reading/investigating all that stuff I referred above - I do think (and I do 
know from what I read, found by myself or in books/articles and use in my 
practice) that this is a "nuclear power" stuff with a broad applicability in 
practical everyday work of every modern programmer.

And I must outline as a final conclusion - reading all these good books and 
artciles gives a lot to not "reinvent the wheel" (because they talk about 
natural things every programmer will come to by themselves sooner or later) 
but only everyday practice in using these methods will make a developer 
agile. This "nuclrear stuff" is not easy and one without enough practice may 
have easily lost themselves in many classes of the solutions created based 
on these principles...

I'm not there yet (where I should have been as I think after I have got 
where these principles lead) - "most practioners would agree that it takes a 
few years to really 'get' objects, unlike the weeks or months it takes to 
learn the syntax of a language."...

Shamil

P.S. Of course one can say they can program without objects etc. - yes, I 
also can do that - it all depends on context of a practical task/project to 
be developed....

----- Original Message ----- 
From: "John Colby" <jwcolby at ColbyConsulting.com>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Sent: Monday, March 27, 2006 6:02 PM
Subject: Re: [AccessD] Access XP forms bound to ADO recordsets


> Shamil,
>
> Can you give me a quick rundown (or a web page to read) about interfaces 
> and
> why you use them?  Is it simply to force compliance with the selected
> interface (ensure that all methods / properties are implemented) or is 
> there
> some larger reason?
>
>
> John W. Colby
> www.ColbyConsulting.com
>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com 




More information about the AccessD mailing list