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