Home → Problems →

a model with [robot]legs

• Edit

kevin.dowd

08 Jul, 2010 12:02 AM

I find myself often getting into difficulty with the 'Model' as my applications grow in size.

I have business logic, model events and VO's all lumped into a single Model package and frankly I always
get that 'bad code smell' sensation near the end of the project.

It's happening again right now.

If anybody has any pointers or a good RL example of the Model in use then I'l love to see it.

regards

1. 1 Posted by Stray on 08 Jul, 2010 08:49 AM

   

   Hi Kevin,

   do you separate your packages into functional areas?

   This might be overkill for what you were looking for, but generally I think the 'too many classes in a package' code smell is a sign that there's a good split to be made higher up - rather than inside the model / services package. The exception is views - if you have a very detailed view and you're mediating at a granular level then it follows that you'll have view.sky and view.grass packages etc.

   For an app that is more than a couple of days work, I use the practice of separating functional areas (even when my apps aren't actually modular) and then within those packages I have api and restricted. You can then make use of the FlexPMD utility to check that you're not using any restricted classes or interfaces outside of their intended domain.

   For example, in a twitter client I would first split my app conceptually into these functional areas (as packages): shell, twitterhookup, tweetreader and tweetwriter. [This is just an off-the-top-of-my-head list, so forgive the clumsiness of the names.]

   Then each of these would have 2 packages: api and restricted.

   The api package then includes classes and interfaces which can be used by other functional areas - generally this consists of events, VOs and interfaces only. If there are only a handful then I just leave them directly in api. If there are more than is comfortable to look at in one list then I split off an events or vos package. If you've got so many interfaces that you want to split them into mvcs then I'd suggest something has gone wrong in your functional separation and you need to split again at a higher level :)

   In the restricted package I don't have model events with the model package, or service events within the service package. This is entirely without basis, but I consider any class that subclasses Event to be part of my controller package. My controller package will have commands and events and signals (if I'm using them) packages. If there are a lot of events then I might split them further back into model / service etc, but again, it's usually a sign that there's a more useful split to be made at a higher level, so unless I'm 90% done I'd take that as a cue to think harder about my functional areas.

   I only do this stuff because it makes my life easier. Your mileage may vary etc.

   For me, the cognitive load is reduced by first filtering my classes by functional area, and then sorting them by mvcs. The ability to use a programme to check that you've adhered to the api / restricted rules is a great bonus. It forces you to build to interfaces instead of implementations and all that good OO stuff that can go out the window when we're not concentrating :)

   Also, the api packages give you a very fast overview of how different functional areas are connected to each other. And you can search your project for 'import tweetreader.api' to remind yourself exactly how one functional area impacts upon another. Probably not that useful today, but hugely useful when you come back to code that you've not looked at in weeks to make a 'tweak'. If the class you're tweaking resides in the 'restricted' package then you know instantly that it has no impact on other functional areas. Win.

   If you use robotlegs, with separate functional areas, and you stick to a single context then you will find that FlexPMD complains that you've imported your restricted classes into your main context. You can just ignore its whining about that :)

   I hope that's helpful,

   Stray

   • Edit

2. 2 Posted by kevin.dowd on 08 Jul, 2010 09:36 AM

   

   Stray,

   Thank you for that response.

   For me, the cognitive load is reduced

   I know what you mean by this - the lower the load the faster the code gets written.

   do you separate your packages into functional areas?

   Not for the model I don't. I think its time to start breaking up the model into more than one package.

   I think I have a particular problem with date that is generated by the UI for use by other element of the UI. I lump it into one big Value Object and just send the whole lot with a custom event. Not good if you have 30 odd getters and setter inside the VO.

   Anyway thanks for the input
   

   • Edit

3. kevin.dowd closed this discussion on 08 Jul, 2010 09:36 AM.