DeepHierarchy - Revision history

JaroslavTulach: /* Substitution Principle */

2022-09-24T05:45:06Z

Substitution Principle

←Older revision		Revision as of 05:45, 24 September 2022
Line 35:		Line 35:
	=== Substitution Principle ===		=== Substitution Principle ===

-	~~Simply exposing a deep hierarchy of classes is unlikely to improve an [[API]]’s usability.~~
	When writing an [[API]], the term ''subclass'' shouldn’t be used for someone who can ''participate		When writing an [[API]], the term ''subclass'' shouldn’t be used for someone who can ''participate
	in a switch'', but for someone who ''behaves exactly like me'', plus adds some additional behavior.		in a switch'', but for someone who ''behaves exactly like me'', plus adds some additional behavior.
-	True, many would agree that a '''Human''' is a subclass (a specialization) of a '''Mammal'''. ~~But how~~	+	True, many would agree that a '''Human''' is a subclass (a specialization) of a '''Mammal'''.
-	~~much can you use this fact in~~ an API ~~design?~~	+	Nice, but simply exposing a [[DeepHierarchy]] of classes is unlikely to improve an [[API]]’s usability magically.

-	Especially [[GUI]] toolkits got this all wrong.	+	Especially [[GUI]] toolkits (full of widgets inheriting from each other) got this all wrong.
	They like to claim that a {{JDK\|javax.swing\|JFrame}} is a specialization of {{JDK\|javax.swing\|JComponent}},		They like to claim that a {{JDK\|javax.swing\|JFrame}} is a specialization of {{JDK\|javax.swing\|JComponent}},
	but try to use {{JDK\|javax.swing\|JFrame}} where you can use {{JDK\|javax.swing\|JComponent}}! It is going to fail.		but try to use {{JDK\|javax.swing\|JFrame}} where you can use {{JDK\|javax.swing\|JComponent}}! It is going to fail.
-	That is not a failure of the usage, but a failure of the ~~[[GUI]] toolkit~~ [[API]] designer!	+	That is not a failure of the usage, but a failure of the [[API]] designer!

	== Do Not Expose Deep Hierarchies! ==		== Do Not Expose Deep Hierarchies! ==

JaroslavTulach: /* OOP Models the World */

2022-09-24T05:41:13Z

OOP Models the World

←Older revision		Revision as of 05:41, 24 September 2022
Line 10:		Line 10:
	easy it is to describe nature, the object-oriented concept is also elevated to be the right programming		easy it is to describe nature, the object-oriented concept is also elevated to be the right programming
	technique to describe the real world. [[OOP]] languages are supposed to be more suitable		technique to describe the real world. [[OOP]] languages are supposed to be more suitable
-	than traditional~~, procedural~~ ones for coding and capturing real-world concepts.	+	than traditional ones for coding and capturing real-world concepts.

	=== Just an Intricate Switch ===		=== Just an Intricate Switch ===

JaroslavTulach: /* Just an Intricate Switch */

2022-09-24T05:35:13Z

Just an Intricate Switch

←Older revision		Revision as of 05:35, 24 September 2022
Line 15:		Line 15:

	After maintaining a [[NetBeans\|framework in Java]] for more than fifteen years, I don’t buy this. Honestly, ''virtual method dispatch''		After maintaining a [[NetBeans\|framework in Java]] for more than fifteen years, I don’t buy this. Honestly, ''virtual method dispatch''
-	is nothing ~~other~~ than an	+	is nothing else than an
	''intricate switch statement''! A method call isn’t a direct invocation of some code but rather a		''intricate switch statement''! A method call isn’t a direct invocation of some code but rather a
	switch that chooses from multiple implementations. The switch is based on the list of subclasses		switch that chooses from multiple implementations. The switch is based on the list of subclasses

JaroslavTulach: /* Just an Intricate Switch */

2022-09-24T05:34:56Z

Just an Intricate Switch

←Older revision		Revision as of 05:34, 24 September 2022
Line 14:		Line 14:
	=== Just an Intricate Switch ===		=== Just an Intricate Switch ===

-	After maintaining a [[NetBeans\|framework in Java]] for more than fifteen years, I don’t buy this. Honestly, ~~_virtual~~ method ~~dispatch_~~	+	After maintaining a [[NetBeans\|framework in Java]] for more than fifteen years, I don’t buy this. Honestly, ''virtual method dispatch''
	is nothing other than an		is nothing other than an
	''intricate switch statement''! A method call isn’t a direct invocation of some code but rather a		''intricate switch statement''! A method call isn’t a direct invocation of some code but rather a
Line 21:		Line 21:
	it’s still a '''switch'''. Of course, explaining [[OOP]] as an ''enhanced switch'' is		it’s still a '''switch'''. Of course, explaining [[OOP]] as an ''enhanced switch'' is
	much less fancy than presenting it as a technology that helps us model the real world. That’s		much less fancy than presenting it as a technology that helps us model the real world. That’s
-	why computer courses are likely to stick with the '''Mammal''' example.	+	why computer courses are likely to stick with the '''Mammal''' example.

	=== Switch with no Limits! ===		=== Switch with no Limits! ===

JaroslavTulach at 05:34, 24 September 2022

2022-09-24T05:34:16Z

←Older revision		Revision as of 05:34, 24 September 2022
Line 1:		Line 1:
	[[OOP]] encourages code reuse and may lead to deep subclassing hierarchies. Beware of that when designing [[API]].		[[OOP]] encourages code reuse and may lead to deep subclassing hierarchies. Beware of that when designing [[API]].

-	== ~~Do Not Expose Deep Hierarchies~~ ==	+	=== [[OOP]] Models the World ===

	Classic [[OOP\|object-oriented programming languages]] are said to be inspired by nature and its		Classic [[OOP\|object-oriented programming languages]] are said to be inspired by nature and its
Line 46:		Line 46:
	That is not a failure of the usage, but a failure of the [[GUI]] toolkit [[API]] designer!		That is not a failure of the usage, but a failure of the [[GUI]] toolkit [[API]] designer!

-	== ~~Avoid~~ Deep Hierarchies ~~in Your [[API]]~~! ==	+	== Do Not Expose Deep Hierarchies! ==

	Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose subtyping, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a subtype, it has to inherently		Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose subtyping, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a subtype, it has to inherently

JaroslavTulach: /* Avoid Deep Hierarchies in Your API! */

2022-09-24T05:32:56Z

Avoid Deep Hierarchies in Your API!

←Older revision		Revision as of 05:32, 24 September 2022
Line 48:		Line 48:
	== Avoid Deep Hierarchies in Your [[API]]! ==		== Avoid Deep Hierarchies in Your [[API]]! ==

-	Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose subtyping, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a subtype, it has inherently	+	Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose subtyping, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a subtype, it has to inherently
	be ready to be used in place of the original super class or interface.		be ready to be used in place of the original super class or interface.

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
	[[Category:APIDesignPatterns:Anti]]		[[Category:APIDesignPatterns:Anti]]

JaroslavTulach: /* Avoid Deep Hierarchies in Your API! */

2022-09-24T05:32:33Z

Avoid Deep Hierarchies in Your API!

←Older revision		Revision as of 05:32, 24 September 2022
Line 48:		Line 48:
	== Avoid Deep Hierarchies in Your [[API]]! ==		== Avoid Deep Hierarchies in Your [[API]]! ==

-	Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose ~~subclasses~~, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a ~~subclass or a subinterface~~, it has inherently	+	Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose subtyping, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a subtype, it has inherently
-	be ready to be used in place of the original ~~superclass~~ or interface.	+	be ready to be used in place of the original super class or interface.

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
	[[Category:APIDesignPatterns:Anti]]		[[Category:APIDesignPatterns:Anti]]

JaroslavTulach: /* Avoid Deep Hierarchies in Your API! */

2022-09-24T05:31:51Z

Avoid Deep Hierarchies in Your API!

←Older revision		Revision as of 05:31, 24 September 2022
Line 48:		Line 48:
	== Avoid Deep Hierarchies in Your [[API]]! ==		== Avoid Deep Hierarchies in Your [[API]]! ==

-	~~The advice here is: instead of big~~, ~~rooted families, try to define the real interface of the application and let users~~	+	Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible! If you have to expose subclasses, remember [[wikipedia:Liskov_substitution_principle\|Liskov's substitution principle]]: if something is a subclass or a subinterface, it has inherently
-	~~implement it. Always~~ remember ~~the ''~~Liskov's principle'': if something is a subclass or a subinterface, it ~~can~~ inherently	+	be ready to be used in place of the original superclass or interface.
-	be used in place of the original superclass or interface.	+
-		+
-	~~Rather than exposing [[DeepHierarchy]] separate [[APIvsSPI]] and stay as flat as possible!~~	+

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
	[[Category:APIDesignPatterns:Anti]]		[[Category:APIDesignPatterns:Anti]]

JaroslavTulach: /* Liskov's Substitution Principle */

2022-09-24T05:29:43Z

Liskov's Substitution Principle

←Older revision		Revision as of 05:29, 24 September 2022
Line 33:		Line 33:
	maintainable.		maintainable.

-	=== ~~Liskov's~~ Substitution Principle ===	+	=== Substitution Principle ===

-	~~So, simply~~ exposing a deep hierarchy of classes is unlikely to improve an ~~API’s~~ usability.	+	Simply exposing a deep hierarchy of classes is unlikely to improve an [[API]]’s usability.
-	When writing an API, the term ~~“subclass”~~ shouldn’t be used for someone who can ~~“participate~~	+	When writing an [[API]], the term ''subclass'' shouldn’t be used for someone who can ''participate
-	in a switch,” but for someone who ''behaves exactly like me'', plus adds some additional behavior.	+	in a switch'', but for someone who ''behaves exactly like me'', plus adds some additional behavior.
	True, many would agree that a '''Human''' is a subclass (a specialization) of a '''Mammal'''. But how		True, many would agree that a '''Human''' is a subclass (a specialization) of a '''Mammal'''. But how
-	much can you use this fact in an API design? Especially [[GUI]] toolkits got this all wrong.	+	much can you use this fact in an API design?
		+
		+	Especially [[GUI]] toolkits got this all wrong.
	They like to claim that a {{JDK\|javax.swing\|JFrame}} is a specialization of {{JDK\|javax.swing\|JComponent}},		They like to claim that a {{JDK\|javax.swing\|JFrame}} is a specialization of {{JDK\|javax.swing\|JComponent}},
	but try to use {{JDK\|javax.swing\|JFrame}} where you can use {{JDK\|javax.swing\|JComponent}}! It is going to fail.		but try to use {{JDK\|javax.swing\|JFrame}} where you can use {{JDK\|javax.swing\|JComponent}}! It is going to fail.
-	That is not failure of the usage, but failure of the [[GUI]] toolkit [[API]] designer!	+	That is not a failure of the usage, but a failure of the [[GUI]] toolkit [[API]] designer!
-		+

	== Avoid Deep Hierarchies in Your [[API]]! ==		== Avoid Deep Hierarchies in Your [[API]]! ==

JaroslavTulach: /* Switch with No Limits! */

2022-09-24T05:27:34Z

Switch with No Limits!

←Older revision		Revision as of 05:27, 24 September 2022
Line 23:		Line 23:
	why computer courses are likely to stick with the '''Mammal''' example.		why computer courses are likely to stick with the '''Mammal''' example.

-	=== Switch with No Limits! ===	+	=== Switch with no Limits! ===

	However, I’ll use the switch		However, I’ll use the switch