2 ms·

As a client of an interface you shouldn't make assumptions which are not guaranteed by the interface in the first place. Sure. But as an author of an interface

As a client of an interface you shouldn't make assumptions which are not guaranteed by the interface in the first place. Sure. But as an author of an interface you should strive to make your interface easier to use correctly. It's easy to blame the programmer who makes the wrong assumptions about your code, but if you can make your interface in way that reduces the possibility of that happening, why wouldn't you? Large software platform vendors are generally more succesful if they instead of blaming application developpers for misusing the APIs, change the APIs so that they are easier to use correctly. The fixed aspect-ratio issue (square or not) actually applies very well to this scenario, video players will often have a fixed aspect-ratio (matching that of the video they're playing + some decoration), and while you can control the width or height [...] A video player getting getting its window locked to the aspect of the video it is playing may be the desired behaviour. Or not. In any case, it should be the video player that makes this decision, not whomever provides the video. Imagine you have an video library API that returns a Rectangle with the dimensions of the video, which previously returned a Rectangle proper (ie. one that allows changing width and height independently). In a recent update however, it changes its internal implementation, and while the signature of the API is unchanged (it still returns a Rectangle), it now returns a Square. This has the effect of changing the behaviour of your application though nothing in it has changed!

masklinn 10y ago
> Sure. But as an author of an interface you should strive to make your interface easier to use correctly. Yes? > It's easy to blame the programmer who makes the wrong assumptions about your code, but if you can make your interface in way that reduces the possibility of that happening, why wouldn't you? I really don't see what point you're trying to make. > Large software platform vendors are generally more succesful if they instead of blaming application developpers for misusing the APIs, change the APIs so that they are easier to use correctly. Well yes, that pretty much my point. The original interface as you defined it is either unreliable if you interpret it literally (and allow fixed-aspect-ratio or even fixed-size rectangles) or completely pointless if you interpret it "smartly" (since it pretty much mandates one specific implementation). > A video player getting getting its window locked to the aspect of the video it is playing may be the desired behaviour. Or not. In any case, it should be the video player that makes this decision, not whomever provides the video. The video player can be an application or a component, it makes no difference. If the video player is an application it changes the behaviour of your OS's maximize or fullscreen feature, or the behaviour of your window-resizing script, or whatever.
- adamlett 10y ago
  Well yes, that pretty much my point. The original interface as you defined it is either unreliable if you interpret it literally (and allow fixed-aspect-ratio or even fixed-size rectangles) or completely pointless if you interpret it "smartly" (since it pretty much mandates one specific implementation). Are you somehow under the impression that I am advocating the example I gave as something to emulate? Your argument seems to be that the example of bad design I gave, is bad design. I'm aware of that, thank you. I'm trying to illustrate why it's bad design. It turns out that this particular bad design is common enough that it has been studied, and it has a name (well not quite, but the principle you have to follow to avoid, it has a name). You may think that my example is contrived, but exchange Rectangle for Window and FixedAspectWindow for Square, and you have something which looks reasonable to most OOP novices. The reason the problem arises is that in classical OOP we are taught that subclasses should be specializations of the parent class. It seems reasonable therefore to make Square a subclass of Rectangle (or FixedAspectWindow a subclass of Window).

masklinn 10y ago

> Sure. But as an author of an interface you should strive to make your interface easier to use correctly. Yes? > It's easy to blame the programmer who makes the wrong assumptions about your code, but if you can make your interface in way that reduces the possibility of that happening, why wouldn't you? I really don't see what point you're trying to make. > Large software platform vendors are generally more succesful if they instead of blaming application developpers for misusing the APIs, change the APIs so that they are easier to use correctly. Well yes, that pretty much my point. The original interface as you defined it is either unreliable if you interpret it literally (and allow fixed-aspect-ratio or even fixed-size rectangles) or completely pointless if you interpret it "smartly" (since it pretty much mandates one specific implementation). > A video player getting getting its window locked to the aspect of the video it is playing may be the desired behaviour. Or not. In any case, it should be the video player that makes this decision, not whomever provides the video. The video player can be an application or a component, it makes no difference. If the video player is an application it changes the behaviour of your OS's maximize or fullscreen feature, or the behaviour of your window-resizing script, or whatever.

adamlett 10y ago
Well yes, that pretty much my point. The original interface as you defined it is either unreliable if you interpret it literally (and allow fixed-aspect-ratio or even fixed-size rectangles) or completely pointless if you interpret it "smartly" (since it pretty much mandates one specific implementation). Are you somehow under the impression that I am advocating the example I gave as something to emulate? Your argument seems to be that the example of bad design I gave, is bad design. I'm aware of that, thank you. I'm trying to illustrate why it's bad design. It turns out that this particular bad design is common enough that it has been studied, and it has a name (well not quite, but the principle you have to follow to avoid, it has a name). You may think that my example is contrived, but exchange Rectangle for Window and FixedAspectWindow for Square, and you have something which looks reasonable to most OOP novices. The reason the problem arises is that in classical OOP we are taught that subclasses should be specializations of the parent class. It seems reasonable therefore to make Square a subclass of Rectangle (or FixedAspectWindow a subclass of Window).