3

I've come upon a situation several times in my career when previous developers have done something funny.

They will make a control (button) function radically different depending on how the screen was opened or some other condition in the data (e.g., save the data to a txt file vs. do a recalculation of something and store it in a database field). If you're lucky, they've changed the caption on the button when they change the functionality.

I've also seen them change the layout of the screen (hide controls, rename them, show entirely new sections). Again, likewise often they change the window caption.

This seems to be an anti-pattern because it make it hard for future developer to figure out what any one screen/control does without extensively walking the code and testing. And the temptation that they are falling for that they think they are saving the time to create a second form by creating one that works differently for different conditions.

What principle is being violated here? I know of the Single Responsibility Principle; but it doesn't seem to be a perfect fit. I think it's closer to "don't do this because it confuses the heck of the users", but I'm not sure if there is anything formal I can point to.

Improve this question
8
  • 5
    Pretty much "every principle".
    – Ross Patterson
    Commented Mar 20, 2015 at 13:35
  • 2
    *1 for "don't do this because it confuses the heck of the users" - When I next admonish someone for doing this, I will tell them it goes against BIBD's principle (or should that be BIBD's law? Which would you prefer on the WikiPedia page?)
    – Mawg
    Commented Mar 20, 2015 at 15:03
  • I vote for single responsibility principle. It could be that it's entirely hidden from the end user that the same form is being used in radically different ways and they're not astonished at all. But using it for more than one thing clearly violates single responsibility (aka do one thing, well).
    – Rob K
    Commented Mar 20, 2015 at 15:17
  • Make the developer use one of these confusing user interfaces. Barring that, make the developer describe how the constant positioning of buttons and menu items on his favorite IDE contributes to his productivity.
    – Gilbert Le Blanc
    Commented Mar 20, 2015 at 22:09
  • 1
    @mawg - How about BIBD's Context Consistency Corollary (which follows from POLA). If a control does one thing in one context, it should probably do something pretty similar in another context. e.g., if a control is called "print" sends the reports to the printer when you are in the report context; it should not try to scan your finger print when you are setting up user credentials. The latter could be renamed something like "Scan Finger Print" to distinguish it; while the former should remain "Print" because that an industry standard.
    – BIBD
    Commented Mar 23, 2015 at 17:44

2 Answers 2

Reset to default
14

It's consistency, or also "principle of least astonishment".

However, your less formal definition seems fine too, more pragmatic.

Improve this answer
2
4

I would say that it is the Single responsibility principle.

Even though it was first applied to Object Orientation, the underlying principle is valid even on non-OO environments - one thing, one job.

In object-oriented programming, the single responsibility principle states that every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Improve this answer
2
  • 1
    this is like the cannonical case for POLA
    – Jimmy Hoffa
    Commented Mar 20, 2015 at 16:04
  • I agree POLA is probably a bigger concern here; however, the SRP impacts the developer that follows along later. So +1. In hind sight it was really two principals involved; when I thought there was one.
    – BIBD
    Commented Mar 23, 2015 at 17:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.