Use Modular Architecture

From APIDesign

Revision as of 00:33, 13 April 2008 (edit) Tomwheeler (Talk | contribs) ← Previous diff		Current revision (03:47, 10 June 2022) (edit) (undo) JaroslavTulach (Talk | contribs)
(9 intermediate revisions not shown.)
Line 1:		Line 1:
-	The example of the JDK as non-modular may be out of date by the time you go to print! :)	+	== Have You Ever Wondered...? ==
-	I'd like some discussion of how you modularize a project that already has a large, non-modular, full-of-spaghetti code base.	+	OK, so you want to prevent [[NetBeans Runtime Container#Modularity Manifesto|object-oriented spaghetti mess]] by splitting our systems into into independent modular pieces, however I wonder how to glue them together? Are there some good practices for doing so? Yes, there are and the
-	I think this would resonate with a lot of programmers.	+	[[Use Modular Architecture|Chapter 7]] gives some. For example to glue pieces together you need some ''injection'' to configure all individual components to work together. The [[Use Modular Architecture|Chapter 7]] builds the understanding for this by starting with the most straightforward and hand-coded solutions and then enhances them to cover ''injection'' as provided by [[wikipedia::Spring_Framework| Spring Framework]] as well as latest releases of [[wikipedia::JDK|JDK]].
-	Also, I'd like you to address non-runtime modularization. That is, just enforcing module dependencies at compile time, in the	+	=== Manifesto of Modular Programming ===
-	ant script. It's perfectly valid, requires no additional software like OSGI, but has some pitfalls (Class.forName, etc).	+
-	For some organizations that are mistrustful of runtime modularization's performance impact (warranted or not), it's better	+
-	than nothing.	+
-	--[[User:RichUnger|RichUnger]] 22:40, 10 April 2008 (UTC)	+
		+	Get the feel for necessity of [[module system|modular programming]] by reading through the [[NetBeans Runtime Container#Manifesto|manifesto]] and going through the demo described at [[NetBeans Runtime Container]] page.
-	# Page 99: "Modular programming is here to make it happen." This implies that modular programming encourages the degradation of the architecture rather than preventing it, so you probably meant "Modular programming is here to help prevent it."	+	=== Double [[Injection]] ===
-	--[[User:TomWheeler|TomWheeler]] Sat Apr 12 19:13:37 CDT 2008	+	The [[Use Modular Architecture|Chapter 7]] also mentions that it might be beneficial to join the strength of [[Spring]] (or other [[Dependency Injection]] technology) and [[Lookup]]. The time has passed since then, and the bridge between these two is available. See [[LookupAndSpring]] for more details. We even have a more theoretical explanation why [[singleton]]s need not be evil.

---

Current revision

Have You Ever Wondered...?

OK, so you want to prevent object-oriented spaghetti mess by splitting our systems into into independent modular pieces, however I wonder how to glue them together? Are there some good practices for doing so? Yes, there are and the Chapter 7 gives some. For example to glue pieces together you need some injection to configure all individual components to work together. The Chapter 7 builds the understanding for this by starting with the most straightforward and hand-coded solutions and then enhances them to cover injection as provided by Spring Framework as well as latest releases of JDK.

Manifesto of Modular Programming

Get the feel for necessity of modular programming by reading through the manifesto and going through the demo described at NetBeans Runtime Container page.

Double Injection

The Chapter 7 also mentions that it might be beneficial to join the strength of Spring (or other Dependency Injection technology) and Lookup. The time has passed since then, and the bridge between these two is available. See LookupAndSpring for more details. We even have a more theoretical explanation why singletons need not be evil.