<?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->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>