Changeset 184
- Timestamp:
- Jan 8, 2007, 8:31:05 PM (19 years ago)
- File:
-
- 1 edited
-
DOV/ch03.xml (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
DOV/ch03.xml
r70 r184 35 35 </section> 36 36 37 <section id="dov.vd.g.co"> 38 39 <title>Classes and Objects</title> 40 41 <para>The user of the desktop is dealing with objects. Files for 42 example are not classic files like on other systems but real 43 objects in the sense that they might carry additional information 44 which is encapsulated and come with object methods to work with 45 them. For example one doesn't copy a file by using a 46 filemanager or the desktop application and calling some <function> 47 copy()</function> API of the operating system. Instead a method 48 on the file object is invoked and the file object handles the 49 copying by itself.</para> 50 51 <para>Every object is an instance of a class which is registered 52 with the desktop. Classes may be registered and de-registered at 53 any time (a restart of the desktop may be necessary). They are 54 implemented as shared libraries and link dynamically to the 55 desktop. By basing the whole desktop on an object model which 56 allows subclassing and class replacement without recompiling 57 it's possible for independent developers to create new 58 classes without access to the desktop source code. In fact 59 developers are encouraged not to modify sources to extend the 60 desktop but to create new classes to add functions to the 61 desktop. By replacing classes with new versions overriding 62 inherited methods it's possible to modify the behaviour of 63 any class of the desktop.</para> 64 65 <para>The root class of the whole desktop is 66 <classname>SOMObject</classname> which is also the root class of 67 the underlying object system (see picture below). 68 <classname>WPObject</classname> implements basic desktop methods 69 like menus or property notebooks. Derived from the basic desktop 70 class is the filesystem class for objects representing files or 71 folders. A subtree handles all types of folders which isn't 72 covered here. All kinds of files live on the left part of the 73 tree. A basic datafile class <classname>WPDataFile</classname> 74 implements methods common to all files like querying the filesize 75 or getting the date of creation. A subtree starting with 76 <classname>MMAudio</classname> implements audio multimedia files 77 while a class <classname>MMVideo</classname> handles digital 78 video files. The <classname>WPDataFileExt</classname> class will 79 be covered later.</para> 80 81 <para>The benefits of using such a class tree in the desktop are 82 easily spotted. The <classname>MMAudio</classname> class 83 implements basic features like playing audio files or displaying 84 audio information like the playtime of the file in question using 85 operating system features. It may also provide a method for 86 accessing tags in the audio file containing the artists name or 87 the trackname. One may implement the latter by adding code to 88 handle ID3 tags of MP3 files and code to handle the same for OGG 89 files. In the end, <classname>MMAudio</classname> would contain 90 code for every tag format known. If a developer ever came up with 91 a new audio codec and a different tag architecture, the 92 maintainer of the desktop or the <classname>MMAudio</classname> 93 class had to be asked to add additional parsing code. Even after 94 the code addition users can't immediately benefit from it 95 because the next release may only be available at some point in 96 the future.</para> 97 98 <section id="dov.vd.g.s"> 99 100 <title>Subclassing</title> 101 102 <para>Using derived classes said developer may just create a 103 new class which inherits everything from 104 <classname>MMAudio</classname> but overrides the method which 105 deals with tag parsing to implement the new parser. Using a 106 binary compatible object system this class can be added without 107 recompiling the desktop. Even more the developer doesn't 108 need the desktop sources at all and doesn't have to care 109 about the rest of the class hierarchy or changes to 110 <classname>MMAudio</classname> made by others (as long as the 111 others don't break the class by changing the binary 112 interface by purpose). Users may install the new class without 113 changing anything of their current system and may immediately 114 use the new features implemented by the class seamlessly. So 115 instead of adding more and more code to 116 <classname>MMAudio</classname> it's better to move 117 specialized code like tag parsing to specialized classes as 118 done in the example with <classname>MMMp3</classname> and 119 <classname>MMOgg</classname>. This also helps to keep the 120 source maintainable because possible execution path are clear 121 and well contained.</para> 122 123 </section> 124 125 <section id="dov.vd.g.cr"> 126 127 <title>Class Replacement</title> 128 129 <para>FIXME</para> 130 131 </section> 132 133 </section> 37 <section id="dov.vd.g.co"> 38 39 <title>Classes and Objects</title> 40 41 <para>The user of the desktop is dealing with objects. Files for example are not 42 classic files like on other systems but real objects in the sense that they might 43 carry additional information which is encapsulated and come with object 44 methods to work with them. For example one doesn't copy a file by using a 45 filemanager or the desktop application and calling some <function> 46 copy()</function> API of the operating system. Instead a method on the file 47 object is invoked and the file object handles the copying by itself.</para> 48 49 <para>Every object is an instance of a class which is registered with the desktop. 50 Classes may be registered and de-registered at any time (a restart of the desktop 51 may be necessary). They are implemented as shared libraries and link 52 dynamically to the desktop. By basing the whole desktop on an object model which 53 allows subclassing and class replacement without recompiling it's 54 possible for independent developers to create new classes without access to the 55 desktop source code. In fact developers are encouraged not to modify sources to 56 extend the desktop but to create new classes to add functions to the desktop. By 57 replacing classes with new versions overriding inherited methods it's 58 possible to modify the behaviour of any class of the desktop.</para> 59 60 <para>The root class of the whole desktop is <classname>SOMObject</classname> 61 which is also the root class of the underlying object system (see picture below). 62 <classname>WPObject</classname> implements basic desktop methods like 63 menus or property notebooks. Derived from the basic desktop class is the 64 filesystem class for objects representing files or folders. A subtree handles 65 all types of folders which isn't covered here. All kinds of files live on the 66 left part of the tree. A basic datafile class 67 <classname>WPDataFile</classname> implements methods common to all files 68 like querying the filesize or getting the date of creation. A subtree starting 69 with <classname>MMAudio</classname> implements audio multimedia files 70 while a class <classname>MMVideo</classname> handles digital video files. 71 The <classname>WPDataFileExt</classname> class will be covered 72 later.</para> 73 74 <mediaobject> 75 <imageobject> 76 <imagedata fileref="images/subclassing.pdf" format="PDF"/> 77 </imageobject> 78 <imageobject> 79 <imagedata fileref="images/subclassing.png" format="PNG"/> 80 </imageobject> 81 <textobject> <phrase>Subclassing</phrase> 82 </textobject> 83 <caption> 84 <para>Some blabla text for it.</para> 85 </caption> 86 </mediaobject> 87 88 <para>The benefits of using such a class tree in the desktop are easily spotted. The 89 <classname>MMAudio</classname> class implements basic features like 90 playing audio files or displaying audio information like the playtime of the 91 file in question using operating system features. It may also provide a method 92 for accessing tags in the audio file containing the artists name or the 93 trackname. One may implement the latter by adding code to handle ID3 tags of MP3 94 files and code to handle the same for OGG files. In the end, 95 <classname>MMAudio</classname> would contain code for every tag format 96 known. If a developer ever came up with a new audio codec and a different tag 97 architecture, the maintainer of the desktop or the 98 <classname>MMAudio</classname> class had to be asked to add additional 99 parsing code. Even after the code addition users can't immediately 100 benefit from it because the next release may only be available at some point in the 101 future.</para> 102 103 <section id="dov.vd.g.s"> 104 105 <title>Subclassing</title> 106 107 <para>Using derived classes said developer may just create a new class which 108 inherits everything from <classname>MMAudio</classname> but overrides 109 the method which deals with tag parsing to implement the new parser. Using a 110 binary compatible object system this class can be added without 111 recompiling the desktop. Even more the developer doesn't need the 112 desktop sources at all and doesn't have to care about the rest of the 113 class hierarchy or changes to <classname>MMAudio</classname> made by 114 others (as long as the others don't break the class by changing the 115 binary interface by purpose). Users may install the new class without 116 changing anything of their current system and may immediately use the new 117 features implemented by the class seamlessly. So instead of adding more and 118 more code to <classname>MMAudio</classname> it's better to move 119 specialized code like tag parsing to specialized classes as done in the 120 example with <classname>MMMp3</classname> and 121 <classname>MMOgg</classname>. This also helps to keep the source 122 maintainable because possible execution path are clear and well 123 contained.</para> 124 125 </section> 126 127 <section id="dov.vd.g.cr"> 128 129 <title>Class Replacement</title> 130 131 <para>FIXME</para> 132 133 </section> 134 135 </section> 134 136 135 137 <section id="dov.vd.g.fv">
Note:
See TracChangeset
for help on using the changeset viewer.
