Proper OO design for app; expert advice needed, please

[RebLazer]

I have been writing a VB.net Windows application for a while and it has grown considerably. Whether this was proper OO design or not, all the code is in a single class. Graphically speaking, the program consists of a single form which contains a single TabControl. The TabControl has three TabPages in it. Like I said, all of the code for these three TabPages is in one, main class.

Another developer is now coming in on the project. I strongly prefer that the new code written by this developer be written in a new TabPage within the same TabControl.

Here's the problem: for source-code control considerations, the other developer's code must be in a new class. Is it possible for the new developer to write their new TabPage code in a new class and still have it function as part of the TabControl in the main class? Would it work to make a constructor for the new class that accepts and argument of a TabControl?

Like I said, I'd prefer that the new code function as part of the same TabControl, but I need the new code to be in a new class.

Any ideas, please?


Thanks so much,
Lazer

 

[Socrates877]

I'd say if your program is large enough to warrant two people working on it, it's probably too big to be in one class. Even if technically you aren't breaking any OO rules, for all practical purposes you are because the code is too bulky and unmanageable!

Also, breaking code into different classes, or better yet, different namespaces, really helps structure the code. It's easy to drop a lot of lines of code when you're forced to get structure. Even for relatively small programs like ASP.NET pages I usually have three files: an .aspx page, a code behind and an assembly of primarily static "helper" tools. That means that at least 2 out of my 3 files always compile!

That's my opinion anyway.

 

[jfrost10]

It depends what you mean by "its all in one class".

Do you mean the UI events and methods are all in one class , that being the code behind? If so, since the class represents the UI, I'd suggest breaking up the different tabs into REGIONS, and keeping hte code in there.

Now, if you're talking about different entities within the various tabs, then its a different story.

Objects should only be responsibile for themselves, not for everything under the sun. So if you have a customer on your first panel, then the class for customer should only handle events and methods for the customer, not for the user interface (thats what the code behind of the web form is for).

Once you get your head around that, the coding will be much easier to manage. Socrates brings up some good points from his post too. Hopefully we were helpful.


D'Arcy

 

[RebLazer]

Yes, thank you both!