I was going over some GUI related code the other day and saw something I figured I could share with the world. Don’t design your views through inheritance. Design them through components instead. Not that this is GUI specific, but I tend to see the same problem again and again when people think about designing GUI related code.
\n<\/p>\n
The code usually looks something like this<\/p>\n
Nothing really looks wrong here, and in fact you’re reusing code which is good right? Nope sorry you lose! You’ve just created a set of views which depend on each other and are now a pain to try to customize.<\/p>\n Let’s work through this and go a bit deeper first so that we really understand the problem. You’ve now got two separate views and you’re asked to change only one of them. In particular let’s add a new “Donate” button in SubFoo in between the OK and Cancel. At this point most people will create a virtual in Foo called getOtherButton(). The new method returns null in Foo, and the new Button in SubFoo, and then if not null, it adds the button into the middle of our container. That’s kind of an odd bit of knowledge Foo now has about its children. I’m also going to claim that it’s much harder to maintain the two views. It’s harder because now when you change one, you have to think about the effects in the other. In fact, before you change one, you should probably understand what the effects are for both.<\/p>\n I think it’s our perception of a View and how we’re using it here that is the real problem, and that’s probably why I typically relate it to GUI design. A View is a set of components that we can see and often a View is really just a component itself, but I ask you to think of a View and a set of components as slightly different. A set of components is just that, a set of components arranged together and any one of those components is swappable with another. Where as the View is that top level component that holds everything and you don’t usually swap between views in the same way as components. I think most people usually consider the View in this scenario as the Controller as well.<\/p>\n So what does it actually mean to subclass a View? Can you really think of a View that should change polymorphically? Is it really the View that should be changing polymorphically or is it one of the components within the View? If it’s one of the components within, then yes I can definitely understand wanting to reuse code to do something that’s very similar. And in fact we’re all taught that we should reuse code whenever possible. Well in this case it’s bad\u2026 or at least there’s a better place to reuse the code.<\/p>\n Look at what you’re trying to do. You’re trying to create two separate views with a very similar sets of components. So why not create a new MegaComponent that is the similar set of components? Then you can create a MegaSubComponent that fills in the new Button in the middle, and each View creates the component it wants. Yes, we’ve really only moved the code reuse to another spot, but now each of our views are separate, just like how we normally think about them from a high level. The views are now being created through reusable components, you just happened to have created a new tree of components to use.<\/p>\n No the code isn’t very different between the two cases, but I really want to stress that there is a huge difference in the design at this point. And a huge difference in how things will get reused later on. You can now reuse that bigger component in many different scenarios without pulling in some of the other code that might be related to the View. People will also be able to quickly jump into code based on the View they see and trace through things from a solid starting point, rather than having to know the intricacies of everything all up front.<\/p>\n In most cases subclassing Views in order to inherit code means you’re creating hard to maintain dependencies. Instead, code should be pulled out to a helper class or separate component etc. in order to allow the same reuse. Remember design by inheritance is BAD! Design by components is GOOD!<\/p>\n","protected":false},"excerpt":{"rendered":" I was going over some GUI related code the other day and saw something I figured I could share with the world. Don’t design your views through inheritance. Design them through components instead. Not that this is GUI specific, but I tend to see the same problem again and again when people think about designing […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-72","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/posts\/72","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/comments?post=72"}],"version-history":[{"count":10,"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/posts\/72\/revisions"}],"predecessor-version":[{"id":128,"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/posts\/72\/revisions\/128"}],"wp:attachment":[{"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/media?parent=72"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/categories?post=72"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/GetOffMyLawnEntertainment.com\/blog\/wp-json\/wp\/v2\/tags?post=72"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nclass Foo {
\n...
\n virtual void setup() {
\n view.set(createBunchOfWidgetsLookAndFeel());
\n }<\/code><\/p>\n
\n Container createABunchOfWidgetsLookAndFeel() {
\n Container c = createContainer();
\n c.add(new Button(\"OK\"));
\n c.add(new Button(\"Cancel\"));
\n c.add(new Text(\"hi\"));
\n return c;
\n }
\n...
\n};
\n<\/code>
\n
\nclass SubFoo : public Foo {
\n...
\n void setup() {
\n Container c = createABunchOfWidgetsLookAndFeel();
\n c.add(new OtherWidget());
\n view.set(c );
\n }
\n...
\n};<\/code><\/p>\n