U++ forum: Welcome to the forum

Re: Overriding Display methods too complicated due to high amount of arguments [message #55473 is a reply to message #55468]

Sat, 14 November 2020 14:23

Klugier
Messages: 1099
Registered: September 2012
Location: Poland, Kraków

Senior Contributor

Hello Mirek,

I see EncodeHtml declaration. It has 9 parameters, so you should be pretty sure that nobody wants to deal with that code. This is not good for the framework to be over-complicated. We pride ourselves on simplicity, but in some places we do something opposite. Where is logic here? Only to avoid small amount of lines in the library. We are here for the users not to create library with the fewer possible lines of code. If we would follow that path we will end with things like Display API and EncodeHtml. My point of view here is simple, we should think what is the best/easiest for our users.

Quote:

- the function is rarely called by client code

But this is the library public API, we should care about it.

Quote:

- the parameter types are well different, which is very important, it greatly reduces the chance of error. It is one thing to have
Foo(int bar, int quo, int boo, int hoo, int woo) and Foo(Font bar, String quo, Color boo, int *hoo, Image wpp).

Sure, however you still to remember about them all, when creating new Display! The learning curve with one parameter and six are much more easier.

Quote:

- it is just 2 more parameters over 4...

The limit should be reasonable. I think that the clean code assumes that maximum 3 parameters are optimal. Anyway for rare cases 4 is fine too, but more is over-complicated. You could say the same for 6 parameters plus 2, because why not. And we will finish with EncodeHtml Smile

We should be rational here and follow industry best practices in API design. I am fine with that on application level...

Quote:

Adding one class and 6 methods just to fix nothing? Are you paid by line written or what?

If you would like to simplify it you could use structure here, then this 6 methods will not be needed. Just document it well and it should be fine. As I said before adding additional lines of code to the library is fine until end results are better. In this case it is simpler more easy to use API. So, why do not add this additional lines?

So, in this particular change request i do not see any OVERENGINEER-ing we just simplify things and reduces overenginnering on the clinet site. Do not force people to add parameters to they overridden classes to have parameters in their functions they will not needed? Do somebody pays them to have it there Smile

KISS on API level Smile

Klugier

U++ - one framework to rule them all.

[Updated on: Sat, 14 November 2020 14:26]

Report message to a moderator