VBA Class Modules: Encapsulation vs. Redundant Code

Greetings,

I am trying to implement class modules in my VBA code using best practices, but I have question about encapsulation vs. redundant code. Let's say I have two class objects, both of which need to be able (purely as an example) extract a filename from the end of a full name string. To avoid redundant code, my first inclination is to write this a public function and then call this function from both class modules, but now I seem to have violated the principle of code encapsulation. Is it better to copy the code as identical private functions inside each class module? Should I put this common code in a "utility" class module, so that it is explicitly called in the other classes, making the dependency clear to future users of the code? I look forwarding to hearing your opinions.

Thanks for your advice,
Jeff

VBA is not an OOP language. Even within OOP paradigm, not all languages strictly follow one of the pillars of OOPs: “Encapsulation”. For instance, in Python all attributes are “Public”. There is no concept of “Private Variable” (We are all adults after all). I know there are some convention you can adhere to restrict access.
Excel and VBA are not particularly secure applications. If someone determines to hack VBA’s code, it is not hard. Therefore, I would not too much concern about “Encapsulation”, rather focus on how to write a working code.

VBA is not a strictly OOP language although its Class feature allows programming using OOP concepts. When doing so, there are established OOD best practices that should be followed.

Encapsulation is not motivated by security. I would agree that Excel and VBA are not very secure but that is a different issue than how to design and code. Private and Public attributes in VBA, C++, Java, or Ada (I do not know Python) are not an attempt to secure code, it is about enforcing good design, which optimizes maintainability and reduces opportunities for bugs.

For example, suppose we have an object with an attribute that defines the state of the object, like the balance of a bank account. That attribute is encapsulated--it is private to the object, and the object has exclusive rights to manage that state. If external code needs to know that state, the object provides a function to return its value, and does not allow those entities to explicitly change it. Any change to the state must occur as a result of what methods are called and what inputs are provided (MakeDeposit, MakeWithdrawal, CreditInterest). However, if that attribute were to be made public for the convenience of a programmer who doesn't want to be bothered by writing a call to a function (or thinks it creates an efficiency issue), then the object loses control over its own state. It creates an opportunity to change the state that falls outside the rules defined by the object. This creates bugs that are hell to diagnose.

These concepts can be traced back as far as Edward Yourdon's work in structured design, where he identifies several types of coupling and several types of cohesion. Although OOD had not been invented yet, the concepts are still valid in all design paradigms. Public variables create what Yourdon called common data coupling, the worst type of coupling.

Originally Posted by 6StringJazzer

For example, suppose we have an object with an attribute that defines the state of the object, like the balance of a bank account. That attribute is encapsulated--it is private to the object, and the object has exclusive rights to manage that state. If external code needs to know that state, the object provides a function to return its value, and does not allow those entities to explicitly change it. Any change to the state must occur as a result of what methods are called and what inputs are provided (MakeDeposit, MakeWithdrawal, CreditInterest). However, if that attribute were to be made public for the convenience of a programmer who doesn't want to be bothered by writing a call to a function (or thinks it creates an efficiency issue), then the object loses control over its own state. It creates an opportunity to change the state that falls outside the rules defined by the object. This creates bugs that are hell to diagnose.

If this is not security to the integrity of the system, what it is then? If my object can access and modify the bank balance attribute, is it not security threat to the entire application? Yes, Encapsulation is not motivated by security,but if your data are not Encapsulated there is likely that the system security is compromised, so it helps you to enforce security.

Originally Posted by AB33

[...]if your data are not Encapsulated there is likely that the system security is compromised, so it helps you to enforce security.

I am not following the reasoning behind this. Making an attribute public does not allow external access to the system for nefarious purposes.

My main point is that just because VBA is not especially secure, that is no reason to abandon good design practices.

I have taken part of the paragraph from this link

https://en.wikipedia.org/wiki/Encaps...r_programming)

Encapsulation is one of the fundamentals of OOP (object-oriented programming). It refers to the bundling of data with the methods that operate on that data.[5] Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called getters and setters) to access the values, and other client classes call these methods to retrieve and modify the values within the object.

IMO, unauthorized parties' can compromise your data and thus your application.

Notwithstanding the fact that anybody can write anything in a Wikipedia article, the phrase "unauthorized parties'" here seems to mean "unauthorized objects" rather than "hackers." I cannot think of an example where an unauthorized party would be foiled by how a variable is declared. If you can write code that calls existing code, and you can get your code compiled and bound into an executable, and then run that executable in an environment, then the environment is compromised and you can pretty much do anything you want. You are not going to be stopped by a Private declaration.

There is a great description of the reason for encapsulation in an article that is linked by the Wikipedia article you cited.

Originally Posted by JavaWorld

David Parnas first introduced the concept of information hiding around 1972. He argued that the primary criteria for system modularization should concern the hiding of critical design decisions. He stressed hiding "difficult design decisions or design decisions which are likely to change." Hiding information in that manner isolates clients from requiring intimate knowledge of the design to use a module, and from the effects of changing those decisions.

This article goes on to give an excellent discussion with concrete examples in Java and rationale for encapsulation. Security, as it happens, is not mentioned.

To flip things to the other side, this tutorial about Java security mechanisms does not mention coding or design, much less private vs. public.

Although interesting, as I mentioned, this discussion is a diversion from the fact that you should still use good design principles in VBA even if the security of the environment is not a consideration.

Greetings All,

I greatly appreciate the thoughtful and insightful feedback that everyone has provided to my original post. I must admit to everyone that this was my first post on the forum. I thought I had set up an email trigger when someone replies to my post. I never received an email, so I assumed there were no responses (probably my error in setting up the feature), so I was thrilled when I finally logged back in a found the above vigorous and (for me) extremely helpful conversation.

I found the conversation about security and encapsulation fascinating, but I must admit my primary motivation to pursue encapsulation was to provide portability and more simplified logic for other users and programmers. I am writing Excel add-ins that are used by other people at my place of work. It started off as a side-project/hobby, but it has grown into an important tool for many of my co-workers. I know that I won't be doing it forever, so to be kind to whomever inherits my code, I am striving to make it as straightforward and self-documenting as possible.

Again, I really appreciate everyone's feedback, especially the references to other programming languages and the external links. And I apologize for my long absence and delayed response. Happy coding, all!

Sincerely,
Jeff