Creating sub-classes of all external classes

Question

I am in a team developing Android applications in an enterprise corporate .One of team members suggested that we should create our own classes, so extending every classes of UI kit (Material Design).

So, if we are going to use a view called Button, we should create class MyPrefixButton extend Button. It's a huge kit and creating all classes takes time and make project larger.

I don't understand the point of intercepting all classes even you are not going to make changes most of them? Does it really neccessary to do that?

I would like to hear your opinions and suggestions.

Answer 1

This sounds like a clear violation of YAGNI (You aren't gonna need it). Do not develop features, or methods that you do not directly need. Basically only create what you know you are going to need, not what you might need in the future. Who knows you might choose to take an entirely different approach before you have the need.

Besides that, who says that the best way to customize is through the use of inheritance, it could just as well be through composition. Or through some other means of achieving the same.

I would challenge the need for extending all classes, and ask what value it would add to your project here and now. Even if you need the customization later on, you still want to depend on an abstraction any place you use the button.

So if you have the need for a button you depend on Button and not MyPrefixButton or any other specific implementation of the button. So creating a new customization, should not spawn a need for changing too many places in the code.

So based on YAGNI, and the general dependency inversion principle I do not recommend this approach.

Answer 2

We may need to customize views in future if needed. Creating it earlier and using it makes less refactoring effort.

If this is an actual reason, you're using the wrong tools.

Imagine that at some point, you need to add a behavior to all of the buttons in your application, and for some reason, creating a base class is the most straightforward way to do it.

So, what's the problem? You just search the whole source code for the locations where the native button class is used, and you replace them by your own base class. Then you run the tests to check if you didn't break anything, and the change is done. As easy as that.

If you use an IDE (with autocompletion and all), it should have a way to show all the references to a class. Once those references replaced, the IDE can help by showing that now, you have only one reference to the native button class—the one from your own base class.

If you use a text-based editor where you can't search for references, plain text search should do the trick as well. One of the caveats may be the way the external packages are referenced. I don't know how things happen in the language used to develop Android applications, but in C#, for instance, one can fully qualify the name of a class (i.e. prefix it with the namespace), or use just the name of the class, or prefix it with a part of the namespace, or use an alias. This means that you have to do extra work here, which means that for this sort of refactoring, you should favor an IDE.

Answer 3

This is an argument you'll need to have with your colleagues. It's probably not necessary, but they might make a good case. Nevertheless, there are some reasons I would tend to avoid this - you will have to judge which ones apply:

• There's a good chance you won't need those changes down the line
• If you do, changing the existing uses probably won't be that hard
• It's quite likely that you'll have to change the call-site even if you do have a wrapper
• You may want to include updates from the library, which could force you to update your wrapper and the call site and get rid of something that conflicts with a new feature
• You're increasing the learning curve and invalidating a wealth of online documentation, examples, and support that you get for free by using an existing library

You would be delaying the initial delivery in order to maybe save a little time down the road. That might sound pretty good, but the feedback you can get from an early prototype is much more valuable.