Developing In Access

[pa2]

Currently I develop in Access systems to suit the business. I use master and replica and synchronise them and the users access them through Server and Citrix.

For best results and the direction to move in for the future should I: -

1. Change to Visual Studio and redevelop my existing db's in VB. (I see no benefits here)

2. Convert my db's to ADP in which case I believe I will need to use SQL server as a backend (I have SQL Server and believe this is the best option to date)

3. Or is there a better solution?

 

[BobRodes]

<VBA doesn't support inheritance, and thus lacks two of the key advantages of OO code: Code reuse

Code reuse is not dependent on inheritance, as your conclusion suggests. Code reuse is defined as using the same code in multiple contexts. While inheritance is certainly an example of code reuse, I can just as certainly reuse code that isn't inherited from another class. For example, if I have a bit of code in a class that debits one account and credits another, applying certain business rules as I do so, I may well find that many different objects instantiate that class and use the functionality that it exposes. The fact that it is or isn't derived from a more generalized class is irrelevant; it's still being reused.

<I fix the bug in Dinosaur, which automatically fixes TRex and Pterodactyl
While this is true in theory, it is far from that simple in practice. I read about half of this paper

http://www.cas.mcmaster.ca/~emil/publications/fragile/ecoop98.pdf

on the well known "fragile base class problem" and it describes the problem very well.

I have argued the point many times about what constitutes an OO language. To say that languages that have inheritance are OO and those that don't aren't seems to me to miss the point: the fundamental artifact of an OO language is the Object! The value of an OO language is code reuse, and the chief means of achieving that reuse is the encapsulation of functionality, exposed through a known interface--in other words, the object. The rest is enhancements. Now, one could say that Java, or any of the .Net languages, are "more" OO than VB or VBA (and C++ either "more" or "less", depending on the capacities of the practitioner), assuming that OO has numerous artifacts (encapsulation, inheritance, polymorphic characteristics, and so on) that cumulatively "rank" a devolopment solution's "OO-ness". However, one can also argue that "Object-Oriented" means simply that you have reusable objects, and the rest are more-or-less useful enhancements. Given that definition, VB is as OO as any other OO language.

I'll leave the "true" answer to the academics. Personally, I find inheritance to be something to use sparingly, unless I have rigid control of the process of specialization, such as when building a framework. For example, the .Net framework makes extensive use of inheritance, and it was developed by a team, where any mods to the base classes were well known to the developers of the subclasses, and in fact were probably often the same person. (One should NOT create a base class, expose it to unknown specialization, and then feel confident that one may modify the base class as desired without breaking any subclasses "out there".)

If I don't have that control, I prefer to use interfaces.

Bob

 

[JoeAtWork]

Hi Bob,

In the example you gave, I do not see how I could create a new TRex class that inherits from Dinosaur. That's what I meant about copying and pasting code. If I add a new method to Dinosaur, I also have to add the code to TRex and Pterodactyl. The closest equivalent to inheritance I can get in VB is encapsulation. So if I wanted to create TRex that has all functionality of Dinosaur, my code would be somehting like:

Private baseDinosaur As New ServerApp.Dinosaur

Public Sub Eat()
  baseDinosaur.Eat()
End Sub

Public Sub Walk(metres As Long)
  baseDinosaur.Walk(metres)
End Sub

Public Sub Run(speed As Long, distance as Long)
  baseDinosaur.Run(speed, distance)
End Sub

'And so on, if Dinosaur has 100 public methods, I've got
'97 more subs to write

To accomplish the same in C#:

Public Class TRex : Dinosaur

One line in C# versus 300 in VB!

What's more, if at some point I decide all dinosaurs should have a BecomeExtinct method, in C# all I need to do is add the method to Dinosaur. In VB I would have to add BecomeExtinct to TRex, Pterodactyl, and every other dinosaur derived class.

If inheritance were the single difference between .NET and Access, that alone would make .NET the preferred choice a no-brainer.
------------------------------------------------------
JBarnett - I've read Rocky's original book and have indeed applied some of his methods in both VB and Access. Particularly I have adapted his techniques to support Undo functionality, and the use of Error collections.

I'm also in the process of reading his "C# 2005 Business Objects" book, which is his adaptation of CSLA (Component Based Scaleable Architecture) in C#. Rocky himself states that .NET solves the most akward aspects of his original VB implementation (using remoting versus DCOM, for example).

I've participated in one .NET project so far that used CSLA. The ability to create a class that inherits from CLSA.BusinessBase reinforced my belief in using OO languages. With one line of code, my new class supported multi-level Undo capabilities, broken business rule traking, and the ability to deploy in any tier of an n-tier architecture.

 

[BobRodes]

<that alone would make .NET the preferred choice a no-brainer.

Hmm...You're telling me that it takes no brains to choose C# over VB? I must be too smart to do so, then, not to mention a number of the other MVP's in the VB forum, notably strongm.

Now, if I wanted to create TRex that had all the functionality of Dinosaur, I would do this:

Public Function MakeTRex() as Server.Dinosaur
makeTRex = New Server.Dinosaur
End Function

Note that my solution also accomplishes the support of the MakeExtinct method.

(taking tongue out of cheek) Ok, I understand what you are saying, but as far as I'm concerned you're overblowing the importance of inheritance, as IMHO is often done. I've already stated my case on that matter, and do encourage you to at least skim over the fragile base class paper that I linked. As for a number of the other features of .Net, some are very useful, there are many improvements, especially in ASP.Net. But hardcore VB programmers can do a great deal of what can be done in .Net, and usually with a smaller footprint.

Bob

 

[MichaelRed]

thanks to all who contributed. it is a bit much ti chew on, so I will at least take some time to review this in detail and may (or may not) respond further.





MichaelRed

 

[JoeAtWork]

I am a hardcore VB programmer. My original point was that I believe that Access is rarely the best solution for a professional application. I've always preferred writing VB interfaces as opposed to Access front-ends.

Perhaps my enthusiasm for inheritance is because I felt it was the one thing I always wished VB would support. I have worked on projects where being able to create a base class and then inheriting from it with several subclasses would have saved a great deal of time and made my code easier to maintain.

One project dealt with citations for many different types of publications: books, magazines, newspapers, thesis papers, etc. All of these had the same core properties, like author(s), but they also had properties unique to their type, such as issue number for magazines.

Some places in my code I needed to deal with all types, in other places I needed to deal with specific types. What I eventually did was create a Publication interface that all types implemented, so in cases where I wanted to deal with all objects as the generic type, I would create a Publication instance and in a loop set that to each of the objects to process them.

But I would have preferred to create a base Publication object that all my other classes could inherit from. I would have been less work and easier to maintain the code.

I tried reading your article but the PDF text does not render very legibly on my screen. I googled "Fragile Base Class" and from what I dredged up there seems to be a pro vs. against debate on using inheritance. But as I understood it the fragile base problem seems to occur when poor design choices are made in the inheritance chain. I.E. if you subclass something that does not have an IS-A relation to the base class.

It seemed similar to the problem when a COM component breaks compatibility with it's former version. Wouldn't this be a case where the problem occurs from improper design, rather than a problem with inheritance itself?

 

[BobRodes]

<Wouldn't this be a case where the problem occurs from improper design, rather than a problem with inheritance itself?

Yes, I feel exactly the same way, and I'm completely in agreement with your last post. I didn't mean to suggest that I had a problem with inheritance per se. Rather, I was making the point that the assertion that a "true" OO paradigm included support for inheritance is open to debate.

My other point about inheritance itself is that, in general, the less control over the specialization process one has, the more sparingly one should use inheritance. Again, the .Net framework is a good example of where inheritance works well, in part because the entire framework itself implies a generalization/specialization paradigm, and in part because the entire framework was and is under a unified design process. Another good example of this is the JDK. Where inheritance does NOT always work so well is when the design of specialized classes is not under the control of, or at least done in communication with, the base class designers. I would be very nervous about, say, overriding some part of the .Net System.Security class tree, and then running off several levels of inherited objects, even if I had a lot of bright people who were putting a lot of effort into that design. On the other hand, creating classes that override System.Object's ToString method is very common, in part because that was the intent of the .Net architects.

So yes, inheritance definitely has an important place, and is very useful. However, OO doesn't require it to be OO. if all your stuff is objects, why, you're oriented towards objects. Sorry if I'm being simple-minded, but that's my position.

Interesting discussion, by the way, and I guess it has enough relevance to the original topic to be on topic, albeit a bit tenuously.

Bob