Originally posted by boyet silverio:
(In a different thread/topic I had been recommended, by Ilja, a book - Agile SW Development by Martin - which may have something on this topic based on its online table of contents, but I'm still in the process of scraping for the "hefty" USD 55 needed to buy the book... meanwhile...)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Frank Carver:
Is there something else preventing you from cutting out unused classes?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The Reuse-release Equivalence Principle (REP)
The granule of reuse is the granule of release
This principle is based on the idea that packages rather than individual classes are the units of reuse. If a package is to be reused, all classes in that package should be designed for reuse.
The Common Reuse Principle (CRP)
The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.
This principle is also based on the idea that packages rather than individual classes are the units of reuse. Classes that are intended to be reused together, should be put in the same package.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Frank Carver:
A jar file should have everything that someone downloading it might need, otherwise it's really hard to tell what should be downloaded. The fact that batik seems to need such a complex diagram of its own internal code astonishes me. I'd just put all the classes from all the batik jars into one big single download.
Does anyone still do this kind of "manual linking" where some jar files are included in the classpath, and some are not. Whether your program works or crashes depends on whether any of the unsatisfied methods are accidentally called or not. Scary!
The way I work is to put all my general-purpose classes into one big jar file (currently about 220K), then run genjar against my application specific code to build a new application-specific jar file using only the utility classes that are actually used. Even my most complex application jar files are usually less than about 60K, including the bits they need from the general utilities.
This way, there's no chance of "class not found" problems (if you don't use Class.forName(), but that can always fail), and you get a small, complete application.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
As I far as I know, the "bad" things about dependencies are where they are cyclical
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
This article is the first of several that will describe principles that govern the macro structure of large object-oriented applications. I emphasize the word large, because these principles are most appropriate for applications that exceed 50,000 lines of C++ and require a team of engineers to write.
...
As software applications grow in size and complexity they require some kind of high level organization. The class, while a very convenient unit for organizing small applications, is too finely grained to be used as an organizational unit for large applications. Something "larger" than a class is needed to help organize large applications.
Several major methodologists have identified the need for a larger granule of organization. Booch uses the term "class category" to describe such a granule, Bertrand Meyer refers to "clusters", Peter Coad talks about "subject areas", and Sally Shlaer and Steve Mellor talk about "Domains". In this article we will use the UML 0.9 terminology, and refer to these higher order granules as "packages".
The term "package" is common in Ada and Java circles. In those languages a package is used to represent a logical grouping of declarations that can be imported into other programs. In Java, for example, one can write several classes and incoporate them into the same package. Then other Java programs can "import" that package to gain access to those classes.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
Ooh, a lot to reply to ...
Stan:If I'm going to carve out some of my favorite goodies to give you for reuse, I think I'd like to just put the appropriate packages into a jar for you. I would not like to put some fraction of one package, and some other fraction of another.
Can you explain a little more why you wouldn't like to do this? Is it because you lack the tools to do it? is it because you'd be worried about missing some classes?
Jar files containing classes from more than one package are so common they it would surprise me if a jar only had classes from one package. Can you point to any popular downloads which have single-package jars?
Stan:That is, I buy the principle that if you're going to need something in a package, you should need (almost?) everything in the package. That principle rejects the notion that packages are "just" name spaces.
I still can't understand this. Why should I want to include a whole bunch of classes I never use?
Ilja:It comes in one single zip file, containing all the jar files. The point is, if my batik-application doesn't use Swing, why should I need to deliver the batik-swing classes with it?
So it actually comes in one big "deliverable" anyway. So you (the application developer) are expected to manually split open this zip file and perform a rough, manual process for your application.
Ilja:Seriously, I would think that if I knew batik a little bit better, the diagram would make perfectly clear which jar files are needed for which application.
But why should I need to know or care? Why should I have to study and learn the result of some other developers trying to guess what I might need, when I have a tool which will quickly, reliably, and automatically do it for me.
Note, though, that it is the external jar files that matter here. My complaint with the batik diagram was that it split up its own internal classes in such a complicated way.
I suggest that a reasonable model might be one deliverable (jar) for each separately managed project with a separate deliverable timeline.
Ilja:Especially with Webstart applications, you want to have the application in as many small jar files as makes sense, so that the automatic updates use as few bandwith as possible.
Fair enough. But I hope you are not advising that we partition every application or utility collection this way, just in case someone ever wants to deploy it by webstart!
Ilja:Class.forName() doesn't typically fail if you use it wisely, for a small amount of classes (for example in the way JAXP uses it). I guess you could always include those dynamically loaded classes as additional "root classes" to your genjar process, but it seems to me that it would make the build process unnecessarily brittle...
I guess there was a little confusion there. What I meant to say was that the "trimmed" jar files produced by genjar are as complete as hand-generated ones.
If you start allowing classes to be created from externally-entered names, then any application might fail, not just one built using genjar.
Ilja: quoting objectmentorIn Java, for example, one can write several classes and incoporate them into the same package. Then other Java programs can "import" that package to gain access to those classes.
Do you honestly still use whole-package import statements?
It really seems that many of these sources are confusing the roles of "namespace", "conceptual partitioning", and "deliverable unit", and often trying to assign all three to the poor overused "package" statement.
Note also that the objectmentor article was written before jar files existed, and when there was no real way of bundling or partitioning deliverables.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
--------------------------------------------------------------------------------
Stan:That is, I buy the principle that if you're going to need something in a package, you should need (almost?) everything in the package. That principle rejects the notion that packages are "just" name spaces.
I still can't understand this. Why should I want to include a whole bunch of classes I never use?
--------------------------------------------------------------------------------
You shouldn't - that's exactly the point: If you need a package, you should need the whole package, not just disconnected parts of it.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Frank Carver:
This still baffles me, and all the repetition of the same bald statement "If you need a package, you should need the whole package" isn't making it any clearer.
In my code I have a core abstraction class Tract, which lives in package org.stringtree.tract. In that package with it are five or six other classes for things like serializing a tract to an OutputStream, decorated versions with argument type conversion etc. These other classes are all very dependent on Tract, but Tract itself is unaware of their existence, and in general they are unaware of each other.
In some application code, I decide that a Tract is a fine representation for some application specific concept, so I import org.stringtree.tract.Tract
I don't need to serialize it or pass Date objects to any of its methods, so I don't import those other classes.
Yet, those of you who argue in favour of the "common reuse principle" seem to be saying that I should bring these other classes in and bloat my code just for the sake of the "principle", even though this application doesn't need them and never uses them.
This sounds mad. What am I missing?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
But in an acyclic class dependency graph this force is resolved only when we achieve one class per package.
When a new release of that [reused] component [read: package/deliverable] is created, the reuser must reintroduce it into existing applications.
- There is a cost for this
- And a risk
Therefore, the user will want each component to be as focused as possible.
- If the component contains classes which the user does not take use of, then the user may be placed in the position of accepting the burden of a new release which does not affect any of the classes within the component that he is using.
I suggest that this indicates a flaw in the princple.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
The package structure is used only as a namespace mechanism.
I would agree much more with some of the "principles" as expressed in this thread if the word "package" is replaced with "component", "deliverable", "library", "jar", "module", or any other word for an arbitrary lump of code.
"a delivered component should contain no unused resources". I would achieve this by using tools such as ant and genjar to construct an application-specific jar file containing only classes and resource files actually used by the application.
Are we still disagreeing?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
say in an mvc application, one way would be to do as follows (e.g. based on component function in a pattern):
package model;
package view;
package controller;
another way would be something based on business areas like
package savings;
package loans;
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
from Don:
In the example, if you have a loans package and in it you will have entity, model & controller classes all related to loans which will be relatively tightly coupled. There will be few interdepencies between the saving and loans packages.
If using the former strategy and have packages such as model, view, controller & entity. In each of these packages you place the relevent classes pertaining to both savings and loans. In this instance you will have relatively lots of interdepencies between packages. Also the packages will contain fairly unrelated classes.
from Stan:
...you might want packages to reflect your organization...
from Stan:
Any harm in slicing both ways? loan.model, loan.view, loan.controller, savings.model, etc?
Any harm in slicing both ways? loan.model, loan.view, loan.controller, savings.model, etc?
--------------------------------------------------------------------------------
this is similar to what we've done which reflects more on the second case, and which I understand is Don's drift.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
quote from Stan James:
Look at the dependency every other package has on the shared stuff package when they extend base framework classes. Any concerns?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Don't get me started about those stupid light bulbs. |