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