Most classes and member functions in one app!
-
I have mostly been developing in my professional life small applications that are in house for the companies I have worked for, just last night I have finished generating some object classes I needed for my application and WOW I was amazed that their was 15 classes and one of the classes had over 50 member functions... What are the most amount of classes you have worked on in one applications? And did it become rather ungainly?!?! It was a pain to look at the classview control and when I clicked on one class it expanded the node beyond the limits of my class view had to actually scroll! Just curious and would like to know how you guys work around "BIG" projects with these many classes? Do you have developers work on smaller amount of classes and link to .LIB file? Or they just work on the Class with a link to the main object and when the builds are ran they hook into those? Like to know....Very curious :-) Sam C ---- Systems Manager Hospitality Marketing Associates
Well, I guess I might as well chime in here. Lets see... 45 projects, probably about half and half between exe's and dll/static libs, looks like about 70 or so classes per project, each class probably averages about 20 or so members functions. Lots of client/server/multithreaded stuff, but no COM. Thats far from the biggest project I've ever worked on, but since I'm the only full time developer here, its a bit of a challange.
-
Since applications are getting more and more complex and "feature rich" the projects to build them are growing of course also bigger. My actual "masterpice" shows the following stats 10 subprojects (libs to avoid DLL hell where possible) with the following number of classes: 144, 9, 34, 9, 117, 10, 44, 23, 2, 127 And thats's without the COM stuff (which is generated via #import) or external libs. LOC 156000+ And remember this is still a 1 person project Some multiperson projects are much bigger
A one-person project? Cool :cool:! What's the project about? -- See me: www.magerquark.de Want a job? www.zeta-software.de/jobs
-
If you've got a class with 50 member functions you're probably in desperate need of refactoring! I've worked on several large projects, and usually you break things up into smaller chunks. For instance, you can code each view in an MDI in seperate MFC extension DLLs. Or any other way to split things up into more managable "chunks". William E. Kempf
-
"More managable" doesn't necessarily mean "put the code in DLL's". There's nothing wrong with a class that has 50 member functions. He never mentioned whether the ratio of public/non-public functions, so who are we to say? :-) I worked on an app that had a base view class that had almost 150 member functions (a handful of public and most or the others were protected). The base view class was comprised of EIGHT CPP files each of at most 1500 lines in length. There was also a series of core calculation classes that involved over 20 files, 300 member functions (all totalled), and about 40,000 lines of code.
>> "More managable" doesn't necessarily mean "put the code in DLL's". << I agree to an extent. Lately I have liked having ALL the code in a single project. I manage huge amounts of code by sticking them in folders in the IDE...Ill create folders with useful names like: Views (Contains all view code) Misc (contains things which dont fall into any category)
-
>> "More managable" doesn't necessarily mean "put the code in DLL's". << I agree to an extent. Lately I have liked having ALL the code in a single project. I manage huge amounts of code by sticking them in folders in the IDE...Ill create folders with useful names like: Views (Contains all view code) Misc (contains things which dont fall into any category)
I'd much rather use embedded code than DLL's. There's only a couple of instances where I can think of that using a DLL is justified: a) The DLL serves as a sort of plug-in (features that the user can purchase and/or optionally install, but whose adsence does not prevent the program from running. b) Code that is shared between applications I've also found that generally speaking, static libs are a pain in the butt (and generally more of a pain than they are often worth. As for sub-projects, they can be useful if you have a LOT of components that have dependancies on each other (early-stage developement of COM objects where the interface could change on a day to day basis), or if you simply want to compile ALL modules/components of a program at the same time. Generally, the more sub-projects you have, the slower the IDE gets. Most of the programs I work on have no more than a single "project", but lately I've been in multi-project hell.
-
I'd much rather use embedded code than DLL's. There's only a couple of instances where I can think of that using a DLL is justified: a) The DLL serves as a sort of plug-in (features that the user can purchase and/or optionally install, but whose adsence does not prevent the program from running. b) Code that is shared between applications I've also found that generally speaking, static libs are a pain in the butt (and generally more of a pain than they are often worth. As for sub-projects, they can be useful if you have a LOT of components that have dependancies on each other (early-stage developement of COM objects where the interface could change on a day to day basis), or if you simply want to compile ALL modules/components of a program at the same time. Generally, the more sub-projects you have, the slower the IDE gets. Most of the programs I work on have no more than a single "project", but lately I've been in multi-project hell.
Agreed >>b) Code that is shared between applications<< I am really bad about not doing this...Since I usually am working on one project at a time I copy the classes I need into the appropriate project folder... Later if I fix/update I copy the updated code the the other projects that use it (if applicable)... I think I started doing this so that when I archived a project onto CD - I knew that all I had to do was load it up and build..Even if it was a couple years old...I reasoned that if a set of classes was shared, the interfaces may have changed to such a degree that other projects based on them would not build correctly....
-
A one-person project? Cool :cool:! What's the project about? -- See me: www.magerquark.de Want a job? www.zeta-software.de/jobs
A building management and alarming system based on LON Networks and LNS (A COM network management component for LON Networks (www.echelon.com)). There is also code on the devices in the LON network (embedded stuff on Neuron Chips). This is maintained and created by another 2 persons. The PC is basically a configuration and display station. There are multiple PCs possible, connected via LON or TCPIP. One PC is working as Server, the others are using its data and events. Connection is possible via Internet, but does not scale to hundreds of client PCs. But this has not been a requirement until now. :)
-
Agreed >>b) Code that is shared between applications<< I am really bad about not doing this...Since I usually am working on one project at a time I copy the classes I need into the appropriate project folder... Later if I fix/update I copy the updated code the the other projects that use it (if applicable)... I think I started doing this so that when I archived a project onto CD - I knew that all I had to do was load it up and build..Even if it was a couple years old...I reasoned that if a set of classes was shared, the interfaces may have changed to such a degree that other projects based on them would not build correctly....
I approach it from a different standpoint. If the class is needed somewhere else but it needs to be a tad bit different, I try to abstract out a base class and derive new classes for the desired functionality. I used to initially consider DLL's, but the VB punks can't/won't learn how to use a DLL correctly, and they insist on getting Active Xcrement or COMplicated DLL's to make *their* lives easier. Well, screw them. If I had to suffer through writing the damn DLL (so that it can be used by programs written in other languages), they can suffer through making it work with a VB app. They wanted to be programmers, so if they can't stand the heat, they can get the hell outa my kitchen. :)
-
I approach it from a different standpoint. If the class is needed somewhere else but it needs to be a tad bit different, I try to abstract out a base class and derive new classes for the desired functionality. I used to initially consider DLL's, but the VB punks can't/won't learn how to use a DLL correctly, and they insist on getting Active Xcrement or COMplicated DLL's to make *their* lives easier. Well, screw them. If I had to suffer through writing the damn DLL (so that it can be used by programs written in other languages), they can suffer through making it work with a VB app. They wanted to be programmers, so if they can't stand the heat, they can get the hell outa my kitchen. :)
-
LOL, that statement has 'Old Fart' written ALL over it. Tim Smith Descartes Systems Sciences, Inc.
