title: BestPractices: Is it bad OOP to subclass standard classes into a new one that does same thing, but "presuming" future changes?
body: <p>I have had similar cases in the past, and this is just an example to illustrate:</p>
  
  <p>I'm going to implement a new feature in my android app (but this applies to any kind of OO project), and at this point I need to implement some "action" in the "setVisibility" method from EVERY edittext in EVERY activity I have.</p>
  
  <p>To do it, I have to subclass "EditView", and override "setVisibity" method:</p>
  
  <pre><code>@Override
  public void setVisibility(int visibility)
  {
      super.setVisibility(visibility);
      // --&gt; do my stuff here! &lt;--
  }
  </code></pre>
  
  <p>So far, so good... the problem is to change all activities I have (more than 200, and thounsands code lines), and then I think: "<em>why on earth didn't I start the project subclassing the standard EditText, 'cos I knew some point I'll need to implement something like this</em>".</p>
  
  <p>That's the point: Is it bad OOP to subclass a "standard class" into a new one that does exaclty same thing, but just "presuming" cases like that? I mean, <strong>subclass everything</strong>, like buttons, activities, etc. </p>
  
  <p>AFAIK, desing pattern and OOP discourage the "presuming factor", but I'd to hear what you guys "do in real life" (or think about that), based on your programming experience.</p>
  
  <p>Also, maybe this type of question ("what you think", "what your oppinion") isn't a good practice here in SO, but I can't find any better place to put it on.</p>