title: Best way to apply inheritance and code reuse
body: <p>I have a question regarding the best way to structure code for reuse with inheritance in cases, where some methods in the base class does not make sense in the inheriting class.
  I think this is a general OOP issue and not only peculair to TypeScript...</p>
  
  <p>So basically, in some form of pseudo code, the issue is similar to this:</p>
  
  <p>class BaseClass
          makesSenseForA
          makesSsenseForA
          ....
          doesnotMakeSenseForA
          doesnotMakeSenseForA
          ....</p>
  
  <p>How then to have a <code>Class A</code> inherit <code>BaseClass</code>. Just direct inheritance means that <code>Class A</code>  would have member methods that does not really make sense.</p>
  
  <p>Not using inheritance means the things that code would be duplicated in both <code>BaseClass</code> and <code>Class A</code></p>
  
  <p>Moving  the <code>makesSenseForA</code> methods to an external class and have both <code>BaseClass</code> and it's children class depend on this extracted class (ie using composition) does not work in this particular scenario, because the extracted class should actually be seen as A <code>BaseClass</code>.</p>
  
  <p>How really is the best way to handle this kind of OOP modeling situation?</p>
  
  <p>EDIT:
  For lack of better example, it is like trying to model <code>Human</code> and <code>Cyborg</code> - this two would share a ton loads of similar implementation and hence first thought might be to have <code>Cyborg</code> extends <code>Human</code>...</p>
  
  <p>But also there would be a ton of implementation that <code>Human</code> has that <code>Cyborg</code> should not have.</p>
  
  <p>Doing away with inheritance means those similar functionality would have to be duplicated in <code>Human</code> and Cyborg`.</p>
  
  <p>And composition also does not work, because if you extract those implementation that are similar into a separate object, that object, and it's method would have a property of <code>Human</code>, and hence should be seen as a <code>Human</code> in our modelling.</p>