>>>>>We've been writing new VFP apps with SQL-Server backend. We use a cursoradaptor class we built and it's doing what we need it to do. It seems like there are very few people using cursoradaptor. My questions is... What are you all using to retreive, update, etc. data between VFP and SQL-Server?
>>>>>Thanks,
>>>>>Mark
>>>>
>>>>I use CAs and SPT. NO VIEWS :-)
>>>>Working with CAs is veery easy nd they are very flexible.
>>>
>>>Hi Borislav,
>>>
>>>Can you please elaborate more on advanatages of CA over SPT and Remote Views? I had an interview recently and I was also suggesting a use of CAs over SPT because they ease all data related operations. However, I was told, that hiding complexity is not always a good thing and with SPT you have a better control of what's going on.
>>
>>That's really too bad. Hiding complexity is always a good thing.
>>
The people interviewing you do not understand this fundamental concept. Unfortunately it doesn't surprise me.
Hiding complexity is the very purpose of software. You build something complex and hand it to a user - so it had better be hiding the complexity. If you make a UDF, you are hiding the complexity - at runtime. At design time, nothing is hidden. At runtime, one component cannot and should not be able to determine how another component works, but simply call upon it for service.
>
>I actually had a very strange interview (by phone). Every statement of mine was questioned and turned to be not entirely correct. One of the other paradoxical questions was to name situations when OOP is not a good thing. This really took me off guard and I could not think of such a situation except for too deep inheritance.
If you call a method of an object, it is slower than calling a .prg based UDF. Consider runtime versus design time again here. At runtime, you would build the .PRG UDF into the .EXE. At design time, the .PRG UDF would be in the VFP path. Testing my performance statement in a design session would not yield the same result as testing it in the EXE.
Stringing a hundred methods together into a swiss army knife kind of class is also not a good way to do OOP.
Too deep inheritance? Not a problem - if you keep the design clear.
>
>However, on the Russian VFP site I got these two interesting links:
>
http://www.geocities.com/tablizer/oopbad.htm>
http://www.devx.com/opinion/Article/26776Those articles are just their opinions. Copy and pasting code is not "reusing" code. If fact that is one of the worst things to do. This guy has confused design time activities with runtime activities. At runtime you reuse a UDF by calling it from multiple places or multiple times. At design time you copy and paste the code. Which makes double the maintenance and double the debugging and double the trouble.
The design of a spark plug is REUSED. The physical spark plug, after manufacture is now an instance (at runtime) and there should be multiple phsical instances. In the physical world, you cannot share one spark plug instance.
But this is software - it's virtual - it's magical. You can share a single instance of a spark plug be used on every car. That's reuse - that's power!
We inherit the design of a spark plug, we don't really need to know HOW it works, just THAT it works.
I'm not favoring OOP over procedural, each has their place. I can give you detailed instructions to make a cup of tea (procedural) and you inherit and reuse the design of the teabag, teapot, stove (OOP).
I wrote an article for FoxPro Advisor where I took a procedural task - scanning a bunch of files looking for a particular type and redid it in OOP - with design patterns. I found the OOP one far more flexible - and I had MASSIVE reuse - of the designs. The one guy is right though, NOBODY (except me it seems) writes articles showing the practical application of OOP.
Our last user group meeting I explained how a single large chunk of code probably has opportunities for encapsulation and reuse. I have one DO CASE statement in a large stream of code that SHOULD have been made into it's own UDF. That is Encapsulation. This UDF could then be reused in other systems in the company. But no! It's been copied and guess what? Each copy is slightly different!
Build an engine as a single massive complex unit with no separate parts and it becomes impossible to maintain. Build it with separate parts that have clear functions and you can maintain it.
