0

I am studying the fragile base class problem and found the following paper interesting: https://www.research.ibm.com/haifa/info/ple/papers/class.pdf

In this paper it is argued that it would be great if Java had a 'sealed' access modifier; not like 'sealed' in C#, which is equivalent to Java's 'final' keyword. The sealing mechanism proposed would make it impossible to extend these sealed classes outside of their packages.

However, most of the material that I have found about the FBC problem dates back to the late 90s, early 00s, so it makes me wonder if the 'problem' is no longer a major issue.

I know that Joshua Bloch is an advocate of restrictive use of inheritance, especially across libraries, and he certainly seems to be a Java authority.

I know how to make oligomorphy happen by creating a set of final inner classes that inherit from a class with a private constructor, but this seems a bit inappropriate somehow.

Is the sealing proposed basically similar to making classes default/package-private, or is there actually some kind of class sealing mechanism in Java today?

  • Could you possibly outline what exactly you're asking about with some examples? The paper is ~10 pages of mostly dense prose, discussing it in detail as-is is probably outside the scope of SO. – millimoose Mar 10 '13 at 23:47
  • Oh sorry, I'll edit it with a brief explanation. –  Mar 10 '13 at 23:50
  • A final class cannot be extended, a default / package private class cannot be used outside the package, so there is a difference. – flup Mar 10 '13 at 23:50
  • I'd say IBM have fallen a long way from their original position of a place of excellence. In my opinion the linked document is utter garbage. You would do well to ignore it and go about your studies as if you have never read the article. Of course - this is only my personal opinion. – OldCurmudgeon Mar 10 '13 at 23:57
  • @OldCurmudgeon: Interesting! It would however be great if you could explain why it is rubbish. My wild amateurish guess would be that it would be impossible to make the dynamic class loading work efficiently with such a keyword. –  Mar 11 '13 at 00:12
  • @talt - please refer to my [rant](http://stackoverflow.com/a/15329367/823393) for more details. – OldCurmudgeon Mar 11 '13 at 00:18
  • @OldCurmudgeon - Rants are great! –  Mar 11 '13 at 00:20
  • @flup - I did not mean 'final' classes (equivalent to 'sealed' in eg C#). I edited my question to clarify this after you commented on it. –  Mar 11 '13 at 00:43

3 Answers3

2

However, most of the material that I have found about the FBC problem dates back to the late 90s, early 00s, so it makes me wonder if the 'problem' is no longer a major issue.

I think it's more that the issue is now well-understood. Similarly, you won't find too many recent papers discussing problems with GOTO and how to address them, not because these problems no longer exist, but because people now know how to avoid them.

Is [the proposed class sealing mechanism] not basically the same thing as making classes default/package-private?

No. Package-private classes and "sealed" classes are similar in that both cannot be extended by classes outside the package, but they differ in that the former also cannot be used by classes outside the package. That is — if a class X is package-private, then a class outside its package can't even refer to X: no extends X, no X x = new X(), no Class<X> clazz = X.class. But if it's merely sealed, then a class in a different package cannot write extends X, but can still write X x = new X() and Class<X> clazz = X.class and so on. (Just as important, it can still write X x = new Y(), if Y is a subclass. So it can still take advantage of X's type hierarchy, even though it itself can't extend X.)

ruakh
  • 175,680
  • 26
  • 273
  • 307
  • Thank you ever so much for a great answer! –  Mar 11 '13 at 00:19
  • One thing though: the goto statement was omitted when programming languages turned more structured; inheritance is still all over the place. I can't help but wonder if this still non-present sealing mechanism could prove useful in Java after all. –  Mar 11 '13 at 00:46
  • @talt: I think that's because the problems with `GOTO` became apparent much longer ago. And some of the tail-end of the `GOTO` debate still affects newer languages -- issues like how variable-scope should interact with `switch`, like whether exceptions cause the same problems, etc. Note that some newer languages, e.g. Go, *do* avoid implementation inheritance. It won't surprise me if some future languages support it, but with various restrictions, like how in C# a `switch` statement requires a `break` at the end of every non-empty `case`. – ruakh Mar 11 '13 at 00:58
  • Thanks for the Go recommendation. I suppose that's an indication that implementation inhertitance is not a OO necessity, even if it is handy and logical. –  Mar 11 '13 at 03:06
0

I know how to make oligomorphy happen by creating a set of final inner classes that inherit from a class with a private constructor, but this seems a bit inappropriate somehow.

I wouldn't say this technique is inappropriate - the real problem is that mainstream OOP languages lack a mechanism to define a type by cases. Doing this conflates cases with types (unless you hide the subclasses by making them private) but it's the only option you have in Java.

ruakh's answer addresses your question about the sealing mechanism so I'll skip that. As for avoiding the Fragile Base Class Problem, this paper presents a solution that currently works in Java. The idea is to make all public methods final and implement them in terms of protected methods. This ensures that subclasses can only override those methods you deem safe.

The problem with inheritance as implemented in mainstream OOP languages is that it's something you have to opt out of when it should be something you have to opt into. That said, other than defining a type by cases I'm not sure what other use inheritance has that's not better replaced with aggregation/composition.

Community
  • 1
  • 1
Doval
  • 2,516
  • 1
  • 22
  • 22
-1

There is actually no such thing as the Fragile Base Class Problem despite the fact that there's a Wikipedia page for it and even a StackOverflow question about it. The reason you cannot find any recent references to it is because it was renamed in the mid 80s to The Incompetent Programmer Problem.

The reason it was renamed was because someone finally realised the problem it describes, where changing some seemingly insignificant method in a base class has far-reaching consequences in all the inherited sub classes, is actually not a problem with oop, it is a problem of putting the wrong code in your base class.

If you want to code oop properly and you wish to make use of inheritance it surely must be completely and utterly obvious that you make sure your base classes only ever contains totally stable and totally reliable code. Because once you start deriving from it you're stuck. If you find you are tempted to change your base class once you have derived from it a few times you have essentially already shot yourself in the foot.

Faffing around with strange private hierarchies is not the answer.

Community
  • 1
  • 1
OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • 1
    Re: "If you want to code oop properly and you wish to make use of inheritance it surely must be completely and utterly obvious that you make sure your base classes only ever contains totally stable and totally reliable code": There is *nothing* that only ever contains totally stable and totally reliable code -- even TeX had several bugs that required fixing -- so this is equivalent to saying "You cannot code OOP properly and make use of inheritance". (And that's a valid opinion, but if it's what you really think, then your current phrasing is cowardly.) – ruakh Mar 11 '13 at 00:26
  • Had a feeling this would be a touchy subject :) –  Mar 11 '13 at 00:31
  • @ruakh - please don't get me wrong. I know you **can** code OOP properly **and** make use of inheritance because I do it all the time. All I am saying is that being scared of inheritance because of all these "Problem"s is just plain wrong. All you need to do is understand that whatever you push down deep into the hierarchy had better be right. BTW - I love your use of Tex as an example but I think you would depress `Knuth` terribly if he ever found out you were using his work to advocate not using inheritance. – OldCurmudgeon Mar 11 '13 at 00:33
  • @OldCurmudgeon: Where did I advocate not using inheritance? (Answer: nowhere. I couldn't, because I myself use inheritance all the time -- just in carefully controlled ways.) – ruakh Mar 11 '13 at 00:36
  • I am not an experienced programmer, but to me it seems difficult to rule out the possibility of ever needing to change base class code. Is it really possible to avoid implementatin inhertiance being error-prone, considering the number of programmers involved, some of whom may not be as experienced as others. –  Mar 11 '13 at 03:02
  • "There is no problem as long as you screw up" is not a valid answer - this is the same line of thought some people use to assert that there's nothing wrong with C/++. Code needs to be able to evolve. Even if your code is correct today, you don't know what changes need to be made tomorrow. Moreover, the fragile base class problem is NOT obvious and is generally neither brought up in introductory language books nor university courses. – Doval Jan 16 '14 at 19:53