Top Banner

Click here to load reader

CPP14 - Encapsulation

Nov 02, 2014

ReportDownload

Software

This is an introductory lecture on C++, suitable for first year computing students or those doing a conversion masters degree at postgraduate level.

  • 1. Encapsulation Michael Heron
  • 2. Introduction One of the things that distinguishes object orientation from other kinds of programming is the tight coupling between functions and data. This is a principle known as encapsulation. In this lecture we are going to talk about why this is such an important technique. And the problems it was designed to resolve.
  • 3. Scope Cast your minds back to a few weeks ago when we talked about global scope. I mentioned this was an easy way to cause problems in large programs. By storing data along with the methods that act on that data (in a class), it is possible to have access to data without global scope. Variables inside a class have class-wide scope.
  • 4. Encapsulation Encapsulation is the principle of keeping data and functions together in one unit. The class By doing this, we have a highly portable unit of data we can manipulate. But only through the functions that we set. We can set an interface on an object that permits us fine- grained control over access.
  • 5. Back To Our Account Class class Account { private: int balance; int overdraft; public: int query_balance(); void set_balance (int); int query_overdraft(); void set_overdraft (int); bool adjust_balance (int); };
  • 6. Private and Public We set sections of the code to be either private or public. private for variables public for functions These are known as visibility modifiers. They change how visible these things are to other pieces of code. There exists a third called protected. Of more niche benefit.
  • 7. Private Private visibility means that variables (or functions) are available only to the class in which they are defined. We can access balance and overdraft as variables within the methods of our object. We cannot access them outside of that object. We do this to make sure that people cannot simply set the value on our data. They have to go through methods we provide
  • 8. Public Public means anything has access. Its the highest level of visibility. We reserve this visibility for methods that we dont mind everyone being able to use. These methods make up our interface to the object. We use a pair of such methods around private variables. We call these access methods Usually a query_x and a set_x.
  • 9. Impact of Change Its very common when writing a program to have to change the way things work. Alas, this comes with major side-effects for many situations. When working with other developers especially, you need to be wary. The interface to the objects you write is a kind of informal contract with your colleagues. Its important to be respectful when developing.
  • 10. Impact of Change Impact of Change defines how much code is likely to need changed if you make an adjustment to your code. The higher the impact, the more code will need modified. Some things are almost always safe to do. Add in variables. Add in methods Some things are almost never safe to do. Change what a method does
  • 11. Impact of Change In large object oriented programs, there may be thousands of classes. All interrelated in complex ways. It is not possible to know which objects may be using public methods and variables in your code. You have to assume if it can be accessed, it will be accessed. Cant change code indiscriminately. Thats not respectful.
  • 12. Impact of Change Instead, what we do is restrict visibility. To private, ideally. We expose as public only those methods we are happy to support. This limits the impact of change. We only need to change things in our own class if we modify things. Important to be able to make adjustments in your code. Private access permits this.
  • 13. What is the benefit? Simplify documentation. External documentation can focus on only relevant functions. Can ensure fidelity of access. If the only access to data is through methods you provide, you can ensure consistency of access. Hides the implementation details from other objects. In large projects, a developer should not have to be aware of how a class is structures. Simplifies code All access to the object through predefined interfaces.
  • 14. Designing A Class A properly encapsulated class has the following traits. All data that belongs to the class is stored in the class. Or at least, represented directly in the class. All attributes are private. Theres almost never a good reason to make an attribute public. Hardly ever a good reason to make an attribute protected.
  • 15. The Class Interface Classes have a defined interface. This is the set of public methods they expose. A properly encapsulated class has a coherent interface. It exposes only those methods that are of interest to external classes. A properly encapsulated class has a clean divide between its interface and its implementation.
  • 16. Interfaces The easiest way to think of an interface is with a metaphor. Imagine your cars engine. You dont directly interact with the engine. You have an interface to that car engine that is defined by: Gears Pedals Ignition Likewise with the car wheels. Your steering wheel is the interface to your wheels. As long as the interface remains consistent It doesnt matter what engine is in the car. Change the interface, and you can no longer drive the car the same way.
  • 17. Interface and Implementation Within a properly encapsulated class, it does not matter to external developers how a class is implemented. I know what goes in I know what comes out The interface to a class can remain constant even while the entirety of the class is rewritten. Not an uncommon act in development.
  • 18. Interface and Implementation Its important to design a clean an effective interface. Its safe to change encapsulated implementation. Its usually not safe to change a public interface. You are committed to the code that you expose publicly. When new versions of Java deprecate existing functionality, they never just switch it off.
  • 19. Interface Our interface may expose a set of public methods with a certain signature. Return type Name Parameters As long as we keep those signatures constant, it doesnt matter how our class works internally.
  • 20. Object Oriented Terminology Object orientation comes with an extra jargon burden. As with most things in programming. Variables in classes are usually known as attributes. It just means a variable that belongs to a class Functions are usually known as methods. Or behaviours.
  • 21. Object Oriented Programs The relationship between objects and classes becomes very complex in many computer programs. Some means of representing this complexity at a glance is useful. This is what a class diagram is used for. It gives the static view of a programs architecture. Other techniques exist too. They vary in effectiveness.
  • 22. Class Diagrams At their simplest, class diagrams are just boxes with lines connecting them to other boxes. They show the relationship between classes only.
  • 23. Class Diagrams At the next level of usefulness, class diagrams also contain information about attributes and methods. Attributes in the second row Methods in the third At their best, class diagrams contain class relationships, methods, attributes, and the visibility of each. They also explicitly show multiplicity. How many of one object relate to how many of another.
  • 24. Class Diagram with Attributes
  • 25. Summary Today we talked about encapsulation. Storing attributes along with the methods that act on them. It is a powerful technique for ensuring fidelity of our objects. People cant change the except through the interfaces we provide. Good object design is to keep attributes private. And permit access only through accessor methods.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.