tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/568-understanding-the-feature-package-structureRobotlegs: Discussion 2013-04-28T10:20:51Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/75108152011-05-28T08:37:26Z2011-05-28T08:37:26ZUnderstanding the feature package structure<div><p>Hi Thomas,</p>
<p>for every feature I have 2 child packages: api and
restricted.</p>
<p>Classes within the api package are open to be used by other
features. Classes within the restricted package are only for use
within this feature. You can't 'enforce' this using the compiler,
but you can verify it using FlexPMD.</p>
<p>Sub-packages within restricted usually start with one of the
mvcs packages.</p>
<p>Generally, the API package should only contain events, vos and
interfaces. Nothing more complex than an event/vo should be
directly referenced using the concrete class outside of the feature
that 'owns' it.</p>
<p>If a class needs to be extended, or really does have use across
multiple features, then I have one or more shared / common packages
which don't have the api/restricted packages, but instead go
straight to mvcs or whatever is appropriate. If the 'common'
classes clearly fall into feature-related areas then I'd express
that in the top level package (eg com/app/common/ui) before going
into mvcs only if it's appropriate.</p>
<p>So - in the end what you have is (for your example below)</p>
<pre>
<code>com
app
common
errorrecovery
ui
utils
doctor
api
core (contains interfaces)
events
vos
restricted
controller
commands
events
model
services
view
childviewa
childviewb
drug
api
core (contains interfaces)
events
vos
restricted
controller
commands
events
model
services
view
childviewa
childviewb</code>
</pre>
<p>In theory you should be able to compile any feature using only
that feature's package, plus common, plus api packages from other
features.</p>
<p>One of the things it draws your attention to is any time you
want to do new ThingThatIsInADifferentRestrictedPackage() you have
to come up with a different solution that couples you only to the
interface. Well - you don't "Have" to - your code will still
compile - but it encourages you to do that. And to at least know
where you're breaking that pattern and why. Mindfulness is the main
win.</p>
<p>In the end, any carefully-considered package structure beats any
not-really-thought-about-it package structure.</p>
<p>I hope that sounds sensible. I think the lack of downloadable
examples will be due to the fact that this becomes useful on a
larger project, and on the whole we're not able to share client
code freely.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/75108152011-05-28T08:41:57Z2011-05-28T08:42:27ZUnderstanding the feature package structure<div><p>Excellent , I understand this approach now from the well laid
out formatting above of the structure.</p>
<p>Yes that is always the case with larger client projects heh.</p>
<p>I will start implementing this on the not so large site I'm
building even though perhaps at this stage, it will only be one
feature.</p>
<p>But this surely seems like a good habit!</p>
<p>Thanks</p>
<p>Thomas</p></div>thomas.thorstenssontag:robotlegs.tenderapp.com,2009-10-18:Comment/75108152011-05-28T08:44:33Z2011-05-28T08:44:33ZUnderstanding the feature package structure<div><p>Great :) And yes - definitely a good habit!</p></div>Stray