Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote -1 down vote favorite

SOLID principles are described here: http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

I am developing a large ASP.NET app. The previous developer created a few very large classes each with lots of different purposes. It is very difficult to maintain and extend. The classes are deployed to the web server along with the code behind files etc.

I want to share a small amount of the app with another application. I am considering moving all of the classes of the ASP.NET web app to a DLL, so the small subset of functionality can be shared. I realise it would be better to only share the classes which contain code to be shared but because of the dependencies this is proving to be very difficult e.g. class A contains code that should be shared, however class A contains references to classes B, C, D, E, F, G etc, so class A cannot be shared on its own.

I am planning to refactor the code in the future. As a temporary solution I am planning to convert all the classes into a single class library. Is this a bad idea and if so, is there an alternative? as I don't have time to refactor at the moment.

share|improve this question
It's the first step I would take in a major refactoring anyhow. – CaffGeek Sep 18 '12 at 20:25
@CaffGeek , do you know any limitations of creating a single DLL for such a large system? – w0051977 Sep 18 '12 at 20:26
@w0051977 as opposed to what? The classes in your ASP.Net web app are already being compiled to a DLL (go check in the bin folder). In any case, if you are worried about "too many classes" going into a single DLL, you will hit readability and maintainability barriers far earlier than any technological ones for compiling it. – Daniel B Sep 19 '12 at 7:31
@Daniel B, as apposed to only converting part of the app into a DLL. This will take longer. What "technological ones" are you referring to? – w0051977 Sep 19 '12 at 8:40
@w0051977 actually, I'm not aware of any strict technological limits (if we're talking about simply compiling / loading the DLL - you'll probably find that DLLs over 100 MB are possible), but you seemed to be worried about something along those lines. Basically the only impact a large DLL will have - at runtime - is taking up slightly more RAM, and the JIT taking slightly longer when your app is started up. Unless we're talking about a DLL that's (well) over 10 MB, you're probably over-thinking this. – Daniel B Sep 19 '12 at 9:09
show 2 more comments

closed as too localized by Eric King, Oded♦, ElYusubov, gnat, MainMa Sep 19 '12 at 18:37

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, see the FAQ.

2 Answers

up vote 1 down vote

We all know that when we say "I'll go back and fix that later", later never happens. You should take the time to refactor just the bits that the other app is going to need. If the current budget does not allow the time you need to do it properly, I would tell my boss that I need more time. As a matter of professionalism, make the budget match the scope, or cut scope.

To answer your specific question though, this is a bad idea. Try your best to not allow the bad coding practices from the existing app into the new app.

share|improve this answer
Or have your boss find someone else to do the job and lose yours. – Oded♦ Sep 18 '12 at 20:19
That wouldn't be a very good boss then. In my experience, managers prefer an honest truth up front over a rude awakening at the end of a project. Plus, that manager will begin to respect and trust your judgment and not treat you like a worker bee. – Jared Sep 18 '12 at 20:20
@Oded, are you saying don't refactor? – w0051977 Sep 18 '12 at 20:21
@w0051977 - I am saying do what's practical. Talk to your boss first and see what he says. I was commenting to Jared's answer - refactor everything may not be feasible for you and the answer takes no prisoners. – Oded♦ Sep 18 '12 at 20:23
2  
@w0051977 - Jared is saying that you should refactor at all costs. I am saying that doing so may be detrimental to your job. – Oded♦ Sep 18 '12 at 20:26
show 2 more comments
up vote 1 down vote

I am planning to refactor the code in the future. As a temporary solution I am planning to convert all the classes into a single class library. Is this a bad idea and if so, is there an alternative? as I don't have time to refactor at the moment.

It's definitely a good idea. Actually, this is already a type of refactoring that you're doing, it just happens to be a pretty easy one to do (copy files over / change namespaces). You mention that you want to share some of the functionality with another app - if the other app is not an ASP.Net app, I would be more careful about this; it's possible that the classes assume that they're being run in that environment (use Request / Session, etc).

I realise it would be better to only share the classes which contain code to be shared but because of the dependencies this is proving to be very difficult...

Of all the problems that you have, worrying about sharing too many classes is one of the smallest. In the comments, you alluded to worrying about the DLL getting too big - I don't know what your project's size is (and what your performance requirements are), but this is generally not a major issue. It requires a fair bit of code to produce a large DLL, so if we're talking about anything under 100 KLOC, you shouldn't worry.

When your DLL is loaded by IIS, it will not take up significantly more memory than it's original size; most of the DLL consists of machine instructions. When your code creates an instance of a class, the data (fields, etc) in that class take up new memory, but the code (methods, etc) are not copied for each class. Having lots of methods in your classes will therefore only increase the memory footprint once globally, not once for each object you create. This is why I say that the DLL won't cause a big issue - if you manage to create a 10MB DLL (which is pretty big), it will take up about the same amount of RAM when it's loaded. This is typically not worth worrying about - your bottlenecks are with the data created with each object.

I mentioned JIT / app startup specifically because this is one area where having large DLLs will affect performance. If you've deployed the app correctly (release mode, etc), re-JIT-ing is not typically supposed to happen, however. Depending on your performance requirements, this may or may not be acceptable. Again, however, this is typically not a huge issue, compared to other areas where performance issues typically lie.

To wrap up, I've added the above for your info, specifically because you asked for it; as I mentioned in the comments, the size of the DLL is really not a huge worry unless we're talking about a project in the millions of lines of code range. Refactoring an old code base with many god objects is enough of a challenge without worrying about this.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.