Reputation
9,415
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
2 28 61
Impact
~603k people reached

Jan
22
reviewed Approve REST API vs directly DB calls in Desktop Application
Jan
22
reviewed Approve Is it a good practice to avoid constants by using getters?
Jan
21
awarded  Notable Question
Jan
2
awarded  Pundit
Dec
20
awarded  Nice Answer
Dec
12
awarded  Nice Answer
Dec
7
reviewed Approve Checking if a method returns false: assign result to temporary variable, or put method invocation directly in conditional?
Dec
7
comment Efficiently determining many-to-many subset relation
"I then have a set of itemsets" Is an itemset just a set of items? How is that different from the set of items you are calling a Transaction? "The number of transactions of which the itemset is a subset" What? Can you re-word that somehow? It makes no sense to me whatsoever.
Dec
6
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
added 448 characters in body
Dec
6
comment How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
@DavidPacker In your example, you work around the issue by letting Point2D know about the Point3D subclass. The OP question was about why it's a stronger commitment to define an API method to be overridden, which implies you don't have knowledge of all sub-classes. Designing a class and sub-class together is a much easier problem than making a public API for other people to subclass, for exactly this reason.
Dec
6
comment How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
@DavidPacker I'm missing something here. If you project the 3D point onto a plane (e.g. Z = 0), it can theoretically be meaningfully compared with other 2D points on that plane. But in 3D space, the comparison is meaningless because the 2D point lacks information in that context (it lacks a Z coordinate). Each meaningful field in a class can be thought of as a comparison context. If you add an important field in a sub-class, you add a context which breaks the equals contract between sub-class and super-class. It breaks Substitution. Usually you subclass to add a meaningful field...
Dec
6
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
added 163 characters in body
Dec
6
comment How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
@chepner and @DavidPacker I've changed the examples to use super() and rely on the super-class as much as possible. It's functionally the same as it was before, just leverages inheritance more. Any implementing class can break Liskov Substitution and you can design an interface that is impossible to inherit from correctly in all circumstances. .equals() is such a method on java.lang.Object. Comparator (and the Strategy pattern) work around the problems with equals() but it's more work to use. glenpeterson.blogspot.com/2013/09/…
Dec
6
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
deleted 74 characters in body
Dec
5
comment How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
@jpmc26 great point: "The more tricky way is bad!" Amen! But what is the more reliable way you mention?
Dec
5
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
added 90 characters in body
Dec
4
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
added 95 characters in body
Dec
4
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
added 70 characters in body
Dec
4
comment How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
@user2357112 You are right and I have removed that example. SortedMap.equals() being compatible with Map is a separate issue which I will proceed to complain about. SortedMap is generally O(log2 n) and HashMap (the canonical implmementation of Map) is O(1). Therefore, you would only use a SortedMap if you really care about ordering. For that reason I believe the order is important enough to be a critical component of the equals() test in SortedMap implementations. They should not share an equals() implementation with Map (they do through AbstractMap in Java).
Dec
4
revised How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
deleted 47 characters in body