7 Replies - 609 Views - Last Post: 21 November 2012 - 12:32 AM

#1 zedth2  Icon User is offline

  • D.I.C Head

Reputation: 2
  • View blog
  • Posts: 121
  • Joined: 14-September 09

Bigger Program or Small Modules

Posted 09 November 2012 - 05:22 PM

So here's the thing I've got a fairly large project I'm building. Many of the pieces and be broken up into there own libraries. I can see how creating smaller libraries would be better for long term maintenance but I could also do it all together as one big program which frankly I think would look like a complete mess. So here's the question is it better to build one giant application or a bunch of little libraries and bring them together for the application?

Thanks in advance.

Is This A Good Question/Topic? 0
  • +

Replies To: Bigger Program or Small Modules

#2 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2216
  • View blog
  • Posts: 9,352
  • Joined: 29-May 08

Re: Bigger Program or Small Modules

Posted 09 November 2012 - 05:55 PM

I'd go with separate projects and libraries, so much easier to maintain and develop.
Allows a separation of concerns.
  • Interfaces
  • Abstract / Base Classes
  • Inherited / Derived Classes
  • Concrete Implementations
  • Data Access Layer
  • Business Logic Layer
  • Presentation Layer


If I develop something that could be useful in future projects I'll section it out into it own project, create DLL and NuGet package. Copy the package in to my Local NuGet repository (just network shared folder). Then in the next project I just add a reference to the NuGet and voila i get all the good stuff I previously coded. Allow me to concentrate my efforts on the part of the project that is specific to this one.

Small projects and libraries (DLL) allows me to create a simple plug-in system, using MEF.
Another thing to consider is that separate projects and libraries allow multiple developers to develop the solution at the same time.

This post has been edited by AdamSpeight2008: 09 November 2012 - 06:00 PM

Was This Post Helpful? 0
  • +
  • -

#3 Tayacan  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 145
  • View blog
  • Posts: 275
  • Joined: 18-January 11

Re: Bigger Program or Small Modules

Posted 18 November 2012 - 11:31 AM

You answered it yourself. Smaller modules are nice, one big program is a mess. Modularity is always good!

Also, do yourself the favor of making your modules as general as you can. Even if you never touch them again, it's a good habit.
Was This Post Helpful? 0
  • +
  • -

#4 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 571
  • View blog
  • Posts: 2,979
  • Joined: 19-May 09

Re: Bigger Program or Small Modules

Posted 20 November 2012 - 09:12 PM

You'll want to read up on "cohesion" and "coupling". Basically, cohesion means that a unit of code serves a single purpose, and coupling (loose coupling is the goal) means that different units of code need to communicate sparsely. A "tell" for lack of cohesion is excessive decision logic; a "tell" for coupling problems is excessive communication. If your unit spends too much time deciding what it is supposed to do at any given time, then break it apart. If it spends too much time "talking" to another unit, then merge them.
Was This Post Helpful? 1
  • +
  • -

#5 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7294
  • View blog
  • Posts: 12,137
  • Joined: 19-March 11

Re: Bigger Program or Small Modules

Posted 20 November 2012 - 09:54 PM

Yes, what Bob said.
Was This Post Helpful? 0
  • +
  • -

#6 zedth2  Icon User is offline

  • D.I.C Head

Reputation: 2
  • View blog
  • Posts: 121
  • Joined: 14-September 09

Re: Bigger Program or Small Modules

Posted 20 November 2012 - 10:25 PM

Thanks that all makes sense, I guess the only question that I would think to ask now is when is it to small? Like I've got parts that are fairly small and don't require other pieces but are used very heavily in the pieces further up. I didn't want to put them together because the smaller piece isn't reliant on anything so I put it separate. I mean it makes sense to me and it's just a project I'm kind of doing for myself so these are just questions I find in my own coding.
Was This Post Helpful? 0
  • +
  • -

#7 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7294
  • View blog
  • Posts: 12,137
  • Joined: 19-March 11

Re: Bigger Program or Small Modules

Posted 20 November 2012 - 10:49 PM

You're not likely to err on the side of "too small". If you see a set of statements which constitute a nameable action, it's probably best to make those a function. If you're using an object-oriented approach, anything that looks like a noun should be considered a potential object.

I've seen a lot more problems arise from failing to decompose a problem sufficiently than I've ever seen from overdoing the decomposition.

For example, at my work right now I'm looking at a website which creates modal popups using ad-hoc calls to the simplemodal library. Each one is created a little differently. We'd like to change them all, in the same way. This means I have to solve the same problem, differently, for each modal popup. There are a lot of them.

The efficient solution to this is in fact to roll back and decompose the problem correctly, such that one small set of functions is sufficient to create any modal in the site, and then apply the change to that. Clearly, having decomposed the problem correctly from the start would have made this a non-issue, but the guy who wrote that code didn't do that.
Lesson: if it's a nameable action, it's a function.
Was This Post Helpful? 1
  • +
  • -

#8 Tayacan  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 145
  • View blog
  • Posts: 275
  • Joined: 18-January 11

Re: Bigger Program or Small Modules

Posted 21 November 2012 - 12:32 AM

Also consider this - it's much easier to refactor several small modules into a big one, than it is to split a huge mess of code into sensible parts. If you're going too far in one direction, at least pick the one where it's easy to get back.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1