<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept xml:lang="en" id="GUID-348E8B54-88D9-5D66-AD11-09131EC387F9"><title>Object Orientation Basics</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>Symbian platform C++ uses the standard object-orientated idioms of encapsulation, inheritance, polymorphism and relationships. This page provides a brief summary of these idioms. </p> <section><title>Encapsulation</title> <p>Encapsulation is the art of exposing the aspects of a class that a user can see, but hiding the parts that should not be seen. C++ provides the <codeph>public</codeph> and <codeph>private</codeph> qualifiers to express this: </p> <codeblock id="GUID-078A33E1-511D-53AF-A3EA-E92AF6649153" xml:space="preserve">class TS
    {
public:
    S(T1 aArg1, T2 aArg2);
    void Use(T3 aArg1,    T4 aArg2);
    ~S();
private:
    TInt iInt;
    TText8 iText;
    TReal iReal;
    };</codeblock> <p>Often, functions are public, while data is private. This allows a choice of representations for a class. In practical OO programming, classes often have many private functions. For classes whose representation is a fairly basic property and whose functions would provide direct read/write access to member variables, it is quite acceptable to make data public. </p> </section> <section><title>Inheritance</title> <p>Inheritance is used to express an is-a relationship: for instance, “a button is-a bordered control”. This allows taxonomies of objects to be built up. In C++, inheritance is represented by derivation. </p> <codeblock id="GUID-D8E3EFDD-AF22-5FB1-87EA-4A61BE64A667" xml:space="preserve">class CEikButtonBase : public CEikBorderedControl
    {
    // etc
    };</codeblock> <p>Encapsulation is enhanced by the <codeph>protected</codeph> qualifier, which means effectively <codeph>private</codeph> for non-derived classes, but <codeph>public</codeph> for derived classes. </p> <p>Inheritance is often over-used by designers of object-oriented systems. Inheritance should not be used unless it is natural: for instance, no-one would dispute that a button is a bordered control. But in Smalltalk, a process is an ordered collection. Of what?! In cases like this, it is better for a class to <i>use</i> another class, rather than <i>derive</i> from it. </p> </section> <section><title>Polymorphism</title> <p>Polymorphism builds on inheritance to allow an <keyword>abstract</keyword> base class to be defined, from which <keyword>concrete</keyword> derived classes may inherit. But, these concrete objects may be used without knowing anything about them, other than that they are derived from the abstract base class. </p> <codeblock id="GUID-87BA8309-C6E7-5389-8A87-2BA8536F1B74" xml:space="preserve">Foo(CCoeControl* aControl)
    {
    aControl-&gt;Draw();
    }</codeblock> <p>In the code above, for instance, the function knows that a control has a <codeph>Draw()</codeph> function, but it knows nothing about the type of control or how it is drawn. </p> </section> <section><title>Relationships</title> <p>In object oriented systems, the relationships between objects matter very much. Some examples from the Symbian platform include: </p> <ul><li id="GUID-68CCE95A-17AE-5809-B983-B8DE739BDD81"><p>the control environment (<codeph>CCoeEnv</codeph>) has-a window server session (<codeph>RWsSession</codeph>). The lifetime of the window server session is identical to that of the control environment. </p> </li> <li id="GUID-2EB9F004-D6BF-56C9-99F4-652230CE2393"><p>the app UI (<codeph>CEikAppUi</codeph>) uses-a document (<codeph>CEikDocument</codeph>). The document has independent existence: the app UI may come into being for a while, and then be destroyed, but throughout the app UI’s lifetime, it uses the document. </p> </li> </ul> <p>In these relationships, cardinality is important. An app UI uses only one document, and a control environment has only one window server session. But a dialog (<codeph>CEikDialog</codeph>) has any number of lines. </p> </section> </conbody></concept>