What is encapsulation ?
Something you can do to make your code easier to maintain, debug, improve and possibly scale.
How does encapsulation make your code easier to maintain, debug, improve and possibly scale ?
1. By reducing coupling between classes:
I didn’t really understand this at first and had to work thru an example
Both TaxCalculatorA and TaxCalculatorB can access Foo.TaxRate, either to use it’s value in a calculation ( and thus become dependent on it ), or to alter it’s value ( and thus cause a side-effect in those classes that depend on it ). Now, Foo, TaxCalculatorA and TaxCalculatorB are all dependent on each other ( coupled together )
Any change to Foo.TaxRate has the potential to break any and all coupled classes, in this case TaxCalculatorA and TaxCalculatorB. Imagine your project contained hundreds of classes, all capable of getting/setting Foo.TaxRate – you could be there for hours trying to track down a bug
In the example above, TaxCalculatorA thinks the current tax rate is 0.4 and returns $40 as expected. TaxCalculatorB decides to change the tax rate 0.2 and returns 20. TaxCalculatorA has to perform a second tax due calculation but this time returns an erroneous 20 instead of 40.
You can avoid these issues by encapsulating Foo.TaxRate. To encapsulate Foo.TaxRate you could change the access modifier to private and wrap it in a property:
You’ve effectively decoupled TaxCalculatorA and TaxCalculatorB from each other because TaxCalculatorA relies on Foo.TaxRate and TaxCalculatorB can no longer change Foo.TaxRate and vice versa.
You’ve also effectively decoupled Foo from TaxCalculatorA and TaxCalculatorA because both A and B cannot change the value of Foo.TaxRate
One of the reasons given to encapsulate was that it would make your code easier to debug – you’re testing your CalcTaxDue calculations and you realize the function is returning erroneous values. To track down the bug you would only have to look in one class – Foo to see where the TaxRate value is being set. Without encapsulating TaxRate, you would have to check all classes with access to the public variable. Only 2 classes in the example above, but consider a solution with 100 classes.
2. By protecting class data from accidental corruption:
You need to create a class which represents a trade – symbol, quantity, price and principal.
In the unencapsulated version ( UnencapsulatedTrade ) it’s possible to corrupt the data by updating the Px after the constructor has been called. It’s also possible to corrupt the Principal value as this is not automatically updated should the Px and/or Qty properties are updated after the constructor has been called.
In the encapsulated version ( EncapsulatedTrade ) the addition of properties prevents the corruption of data. The private set makes each property read-only once their value has been set in the constructor, therefore they cannot be changed once the constructor has been called, preventing an inaccurate Principal value or negative Qty/Px values.
3. By hiding data and behavior which are not part of the public interface:
You’ve been asked to create a class to load data from a flat file into a database table. You come up with the following class definition:
The LoadFile function will do the actual work of loading the flatfile contents into the database. You decide to add an additional method – LogStatusStep, to help you debug if something goes wrong. The LogStatusStep method is an internal method, not something you want the consumers of your class using or even being aware of. The fact you’ve marked it as public means it can be called by any consumer, introducing the possibility of erroneous status messages being logged. It also means you cannot change the signature of the method without breaking code in the consumer classes e.g. you may decide that instead of logging status messages by the string JobName, you want to log by an integer.
To avoid this problem, all methods which are not part of the public API should be marked as private or internal.
C#/SQL Notes 
Leave a comment