Design a Charity Fundraising Platform Using Object-Oriented Design

Charity Fundraising Platform Design Using Object-Oriented Design (OOD)

Introduction

A charity fundraising platform enables organizations, individuals, and community groups to raise money for charitable causes. The platform can handle the creation of fundraising campaigns, donation tracking, user management, and financial reporting, ensuring transparency and fostering trust.

Using Object-Oriented Design (OOD) principles, we can break down the system into objects that reflect the real-world entities involved in charity fundraising. These entities can include users, campaigns, donations, and financial reports.

1. Key System Components and Objects

a. User
This object represents both donors and charity administrators. It holds details like name, contact information, role, and account status.

• Attributes:

  • User ID

  • Name

  • Email

  • Password (hashed)

  • Role (Donor/Administrator)

  • Account status (Active/Inactive)

• Methods:

  • Register()

  • Login()

  • UpdateProfile()

  • ChangePassword()

b. Campaign
A campaign represents a fundraising initiative. It holds details about the cause, target amount, timeline, and progress.

• Attributes:

  • Campaign ID

  • Title

  • Description

  • Target Amount

  • Current Amount Raised

  • Deadline

  • Organizer (User who created the campaign)

• Methods:

  • CreateCampaign()

  • UpdateCampaign()

  • ViewCampaign()

  • UpdateProgress()

c. Donation
The Donation object represents the donation made by a user to a campaign. It tracks the amount, date, and donation method.

• Attributes:

  • Donation ID

  • Donor (User who donated)

  • Campaign (Campaign to which donation was made)

  • Amount Donated

  • Payment Method

  • Donation Date

• Methods:

  • MakeDonation()

  • RefundDonation()

  • ViewDonationHistory()

d. PaymentGateway
This object integrates with external payment processors like Stripe or PayPal. It handles the financial transaction aspects of donations.

• Attributes:

  • Payment ID

  • Payment Method (Credit Card, PayPal, etc.)

  • Transaction Status

  • Amount

  • Transaction Date

• Methods:

  • ProcessPayment()

  • RefundPayment()

  • VerifyPayment()

e. Report
This object helps track the financial status of all campaigns, donations, and fund distribution.

• Attributes:

  • Report ID

  • Campaign ID

  • Total Funds Raised

  • Total Donations

  • Date Range

• Methods:

  • GenerateCampaignReport()

  • GenerateDonorReport()

2. Relationships Between Objects

• User to Donation: A one-to-many relationship. A user can make multiple donations.

• Campaign to Donation: A one-to-many relationship. A campaign can receive multiple donations.

• Campaign to User: A one-to-many relationship. A user can create multiple campaigns, but each campaign has one organizer.

• User to Report: A one-to-many relationship. A user (administrator) can generate multiple reports for different campaigns.

• Campaign to Report: A one-to-one relationship. Each campaign has a corresponding financial report.

3. Use Case Scenarios

a. Donor Creating a Donation

1. A donor registers on the platform and logs in.

2. The donor browses available campaigns and selects one to donate to.

3. The donor enters the donation amount and selects a payment method.

4. The platform processes the payment using the PaymentGateway object.

5. The system records the donation in the Donation object, updates the Campaign progress, and sends a receipt to the donor.

b. Admin Creating a Campaign

1. The administrator logs into the platform.

2. The admin creates a new campaign by providing details like title, description, target amount, and deadline.

3. The system stores the campaign information in the Campaign object, assigning the admin as the organizer.

4. Once created, the admin can monitor donations and track progress in real-time.

c. Generating Reports

1. The administrator requests a financial report for a specific campaign.

2. The system generates the report by aggregating the total funds raised and donations received.

3. The report is made available for the admin to download or view within the system.

4. Class Diagram (Simplified)

pgsql
CopyEdit
+-----------------+      +-----------------+      +-------------------+
|     User       |      |    Campaign     |      |     Donation      |
+-----------------+      +-----------------+      +-------------------+
| - userID       |<>----| - campaignID    |<>----| - donationID      |
| - name         |      | - title         |      | - donor (User)    |
| - email        |      | - description   |      | - amount          |
| - password     |      | - targetAmount  |      | - date            |
| - role         |      | - deadline      |      | - paymentMethod   |
+-----------------+      | - currentAmount |      +-------------------+
                         +-----------------+      
                                |                   
                          +------------+            
                          | Payment   |            
                          | Gateway   |            
                          +------------+            
                          | - paymentID|            
                          | - amount   |            
                          | - status   |            
                          +------------+            
                                  
+-----------------+      
|     Report     |      
+-----------------+      
| - reportID     |      
| - totalRaised  |      
| - totalDonors  |      
+-----------------+

5. Potential Design Patterns

1. Factory Pattern: To create different types of users (donor, admin) or donations (one-time, recurring).

2. Observer Pattern: To notify donors when a campaign reaches a funding milestone.

3. Singleton Pattern: For the PaymentGateway, ensuring that only one instance interacts with external payment services.

4. Strategy Pattern: To allow different donation strategies (e.g., one-time, monthly) based on user choice.

6. System Architecture

• Frontend: A web interface that allows donors to browse campaigns, make donations, and view reports.

• Backend: A server-side application that handles user authentication, campaign creation, donation processing, and report generation.

• Database: A relational database (e.g., MySQL, PostgreSQL) for storing users, campaigns, donations, and reports.

• Payment Gateway Integration: External services like Stripe or PayPal to handle donations securely.

7. Conclusion

By applying Object-Oriented Design principles, we can create a flexible, scalable charity fundraising platform. The use of objects such as users, campaigns, donations, and payment gateways allows for clear separation of concerns, making the system easier to maintain and extend. With careful attention to design patterns and system architecture, the platform can handle a variety of use cases, from donations to campaign management and reporting.