-
Notifications
You must be signed in to change notification settings - Fork 2k
Expand file tree
/
Copy pathDubiousDowncastOfThis.qhelp
More file actions
31 lines (28 loc) · 1.65 KB
/
DubiousDowncastOfThis.qhelp
File metadata and controls
31 lines (28 loc) · 1.65 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<!DOCTYPE qhelp PUBLIC
"-//Semmle//qhelp//EN"
"qhelp.dtd">
<qhelp>
<overview>
<p>If a type <code>Derived</code> inherits (either directly or indirectly) from a type <code>Base
</code>, then it has a dependency on <code>Base</code> by virtue of this inheritance relationship -
that is, it cannot be used without <code>Base</code> also being present. If, in addition to making
<code>Derived</code> inherit from <code>Base</code>, you also write code that depends on <code>
Derived</code> within <code>Base</code>, you cause <code>Base</code> to depend on <code>Derived
</code> as well, resulting in a dependency cycle between the two types. Dependency cycles are a
well-known design smell, in that they make code both difficult to read and difficult to test.</p>
<p>In the situation just described, the dependency cycle has been introduced by writing code that
coerces the type of <code>this</code> to a derived type. This is a very unwise thing to do - a type
should never know about its specific descendants, even though it may of course choose to impose some
constraints on them as a group (such as the need for every derived type to implement a method with a
specific signature).</p>
</overview>
<recommendation>
<p>The appropriate solution to this problem is to redesign the base and derived types so that there
is no longer a need for the base type to depend on the types that derive from it.</p>
</recommendation>
<example>
<p>In this example <code>BaseClass</code> attempts to downcast itself to various known subclasses
in order to call methods specific to those subclasses. This is very bad practice.</p>
<sample src="DubiousDowncastOfThis.cs" />
</example>
</qhelp>