[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 328
  • Last Modified:

Patterns and my program

Hi there,

I am working on a project and am learning VB.NET at the same time. I decided to do a simple accounting system.

The first thing I did was to create a form that would load clients. Double click on a client and you could edit the client. Basic information for the client like name address etc. A client might be a particluar type eg company or private - difference would be a tax number.

I also have a form that shows all the accounts in the chart of accounts.

Each form has code behind it but I have completely separated all the code and moved it to a helper class. So all thats in the form code is the event handlers and a function call to the helper class.

So two classes for each form. The client is completely self contained. All I require out of this is a client number. I used LINQ to obtain all the clients.

MY QUESTIONS: I have been reading about patterns. Given I select a client and an account for a journal... is there a pattern that I might follow?

Is creating a helper class for each form a good way to go given that there is some reused code?

Simon
0
si2030
Asked:
si2030
1 Solution
 
obrienslalomCommented:
Since you have event handlers in .NET, you get to avoid a lot of the behavioral patterns that tend to show up frequently in GUI applications.  When starting out with design patterns, be careful not to create classes just because it can.  Using design patterns will help you maintaining and extending an application.  If you want to add functionality, you can add them without modifying code everywhere.

The obvious application of design patterns here is the abstract factory pattern in the definition of your client.  All the common code between every type of client in the system go in the abstract class.  This includes public and private (maybe common LINQ queries).  Anything specific to a company/private client will go in their respective classes.

An example could be a method that applies interest to all client accounts, assuming a different interest rate is used for a private and a company account.  A virtual applyInterest method in the abstract class will allow you to calculate the new balance (held in a protected member variable in the abstract class).

My point is that most of the functionality that your after can be contained in this type of an abstraction.  Designing separate classes for each form isn't necessary if they don't contain state.  You right in trying to abstract out common functionality between actions, but I think that pulling all the logic out of every form isn't necessary.

As general advise, try to abstract out parts of your code that can represent a real object, and create a hierarchy.  After you realize what objects your system will use, use necessary design patterns to define the ways they will communicate with each other.
0
 
si2030Author Commented:
I have been thinking on this alot. In this project the only thing that the rest of the program will ever see or want regarding the client is the client number. The form that displays clients is fully self contained and has no other functionality except to add new clients or edit... or select. This section of the project could be used as a block in other projects that need to select the client. I can see where your suggestion comes to the fore where I might have it working for tax in one application and no tax in another...

Thanks for the direction

Simon
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now