MajP
You've got your good things, and you've got mine.
- Local time
- Today, 13:25
- Joined
- May 21, 2018
- Messages
- 8,887
So recently there was a discussion on the value of Object Oriented Programming, and I will contend that since this is an Access forum that, that question makes no sense. Everything you do in VBA is object oriented.
Yes VBA is an object oriented programming language, but limited. There are four pillars of OOP and they are Encapsulation, Abstraction, Inheritence, and Polymorphism. Clearly vba does encapsulation by having classes and letting you build custom classes. This is by far the most important pillar.
"Encapsulation is the mechanism of hiding of data implementation by restricting access to public methods. Instance variables are kept private and accessor methods are made public to achieve this"
VBA does not have real class inheritance where you can build a base class and inherit its properties, methods, and events in a subclass. Polymorphism and inheritance go hand and hand and easier to explain if you had inheritance.
However, I recently learned you can build interfaces in VBA which definitely incorporates Abstraction, Polymorphism, and a little sort of inheritance.
Peason does a great job of explaining how to do an interface in VBA, what may not jump out is the so what.
http://www.cpearson.com/excel/Implements.aspx
So read the above in detail. This assumes you know how to make and use classes and understand basic OOP. If not this thread is not for you. I will try to give the so what.
So Mr. Pearson built a class to sort an array. And lets assume that is all he built for himself, but provided it to others to use. That is kind of the Idea of OOP. You do not need to know how to build the watch just how to use it. He said, I do not know how you would compare 2 items in an array so I will leave it to you to provide the rules. If not he would have wrote 100s of select cases to handle all the possibilities. Instead he provided an Icompare interface. The interface is a contract that says you will use the properties, methods, and events with the same signatures. A signature is the arguments and argument types and the return type. This allows you to determine how two objects are compared and determine which one should be sorted first.
So that is the big deal. If you build a class that implements the interface you can pass that to the Sort class. It is as if you can pass a function to a procedure. Based on the class you pass in, it will use the rule. The big deal is that you do not have to write select case statments or even rewrite code, you just pass in how you want to compare two items. More importantly you would not even be able to write the select statement becuase you do not know how the user in the future will compare two items.
A shortcoming with Pearson example that his Icompare is based on a string. If he would have used objects (and he alludes to it) it would have been more illustrative since there could be infinite ways to compare two objects. With strings there is probably only so many ways. So assume his interface was
How do you sort an array of objects? There could be an infinite amount of ways to do this. By name, value, weight, color, Fun Factor, Pain index... There is no way you could write all the select case statements. However, using the interface the user could define how you compare two objects without writing a lot of code in the sort procedure.
So doing this without the interface would require the user to "break" the sort module, write select cases, and result in non structured code.
The use of Interfaces in VBA is not a "game changer". The OOP attributes work together and since VBA does not have all of them (abstraction, inheritance, overloading, ...) it diminishes what you can do. However, this is a potential tool in you tool box, although limited.
Yes VBA is an object oriented programming language, but limited. There are four pillars of OOP and they are Encapsulation, Abstraction, Inheritence, and Polymorphism. Clearly vba does encapsulation by having classes and letting you build custom classes. This is by far the most important pillar.
"Encapsulation is the mechanism of hiding of data implementation by restricting access to public methods. Instance variables are kept private and accessor methods are made public to achieve this"
VBA does not have real class inheritance where you can build a base class and inherit its properties, methods, and events in a subclass. Polymorphism and inheritance go hand and hand and easier to explain if you had inheritance.
However, I recently learned you can build interfaces in VBA which definitely incorporates Abstraction, Polymorphism, and a little sort of inheritance.
Peason does a great job of explaining how to do an interface in VBA, what may not jump out is the so what.
http://www.cpearson.com/excel/Implements.aspx
So read the above in detail. This assumes you know how to make and use classes and understand basic OOP. If not this thread is not for you. I will try to give the so what.
So Mr. Pearson built a class to sort an array. And lets assume that is all he built for himself, but provided it to others to use. That is kind of the Idea of OOP. You do not need to know how to build the watch just how to use it. He said, I do not know how you would compare 2 items in an array so I will leave it to you to provide the rules. If not he would have wrote 100s of select cases to handle all the possibilities. Instead he provided an Icompare interface. The interface is a contract that says you will use the properties, methods, and events with the same signatures. A signature is the arguments and argument types and the return type. This allows you to determine how two objects are compared and determine which one should be sorted first.
So that is the big deal. If you build a class that implements the interface you can pass that to the Sort class. It is as if you can pass a function to a procedure. Based on the class you pass in, it will use the rule. The big deal is that you do not have to write select case statments or even rewrite code, you just pass in how you want to compare two items. More importantly you would not even be able to write the select statement becuase you do not know how the user in the future will compare two items.
A shortcoming with Pearson example that his Icompare is based on a string. If he would have used objects (and he alludes to it) it would have been more illustrative since there could be infinite ways to compare two objects. With strings there is probably only so many ways. So assume his interface was
Code:
Public Function Compare(X As Object, Y As Object) As Long
End FunctionSo doing this without the interface would require the user to "break" the sort module, write select cases, and result in non structured code.
The use of Interfaces in VBA is not a "game changer". The OOP attributes work together and since VBA does not have all of them (abstraction, inheritance, overloading, ...) it diminishes what you can do. However, this is a potential tool in you tool box, although limited.
