Multi level class implementation

  • Thread starter Thread starter kids_pro
  • Start date Start date
K

kids_pro

What is the correct way to implement this real world problem?

Planning Process:
----------------------------------------------------------
--+ Plan: (name, GetCost, GetPaidAmount)
----+ Activities: The plan has many activities (name, GetCost,
GetPaidAmount)
------+ Budget Items: again each activity has many budget item. (name,
smallCost)
--------+ Payment: There is more than one payment for each Budget Items
(month,amount)

Use case:
If we plan for 12 months (1-12) then the payment can be made again the
budget item within any month from 1 -12.

I feel this problem can be implement in C# in OOP way.
But when I try I was get lost.
I am not sure to to related each class to gether.

Please advise me with some implementation prototype.
Many thanks
 
...
What is the correct way to implement
this real world problem?

[snip]

There are *many* correct ways, but probably also many *incorrect* ways...

It all really depends on how these classes then are supposed to *work
together*, so...
I feel this problem can be implement in C# in OOP way.

....before you go further on OOP, you should try some OOA&D (analysis and
design), to check what requirements the classes have for each other.
Use case:
If we plan for 12 months (1-12) then the
payment can be made again the
budget item within any month from 1 -12.

Well, that's a "use case" only at a brief level...

You need to know also what is expected as *outcome* of the system, and then
work your way backwards...

If you know anything about UML, you can e.g. use sequence diagrams, to model
this behavior, and from that much of the design of the classes will emerge.

// Bjorn A
 
Bjorn,

Thank for your input I have attach a sample code that I try to implement.
(I know I am still beginner in OOP) but please let me know how is my
implementation.

Regards,

Bjorn Abelli said:
...
What is the correct way to implement
this real world problem?

[snip]

There are *many* correct ways, but probably also many *incorrect* ways...

It all really depends on how these classes then are supposed to *work
together*, so...
I feel this problem can be implement in C# in OOP way.

...before you go further on OOP, you should try some OOA&D (analysis and
design), to check what requirements the classes have for each other.
Use case:
If we plan for 12 months (1-12) then the
payment can be made again the
budget item within any month from 1 -12.

Well, that's a "use case" only at a brief level...

You need to know also what is expected as *outcome* of the system, and then
work your way backwards...

If you know anything about UML, you can e.g. use sequence diagrams, to model
this behavior, and from that much of the design of the classes will emerge.

// Bjorn A
 
...
I have attach a sample code that I try to implement.
(I know I am still beginner in OOP) but please let
me know how is my implementation.

Well, it's a start...

You'll probably need some collection to keep track of the activities within
a Plan (and likewise for budgets in Activities, etc).

If an Activity really needs to know its Plan is one of the questions that
only can be answered when you get further with the OOA&D (e.g. through
sequence diagrams). If it does, you'll have a bidirectional association
between Activity and Plan, which always is more difficult to maintain than a
unidirectional association.

I'll just give some examples on improvements that *can* be made on your
present code, but even those can be questioned, as one has to know more
about how these classes will be used in *practice*, i.e. within an
application.

I have in the example focused only on the *relation* between Plan and
Activity, the rest is up to you... :-)

=======================================================

using System;
using System.Collections;

namespace ConsoleApplication1
{
// To facilitate the possibility to enumerate through
// the activities within the Plan, we can implement
// IEnumerable

public class Plan : IEnumerable
{
string name;
int nMonth;

// We need some collection for our activities.
// Whether it's to be a Hashtable, an ArrayList,
// or another type, is to be answered of the
// analysis and design

Hashtable activities = new Hashtable();

public Plan(string planName, int nmonth)
{
this.name = planName;
this.nMonth = nmonth;
}

public int NumberOfMonth
{
get{return nMonth;}
set{nMonth = value;}
}

public string Name
{
get{return name;}
set{name = value;}
}

// Now, here's really a big question!
// If an activity is created "outside" the Plan,
// there's the possibility that it can end up in
// another Plan as well...

// public void AddActivity(Activity newAct) { }

// ...so I suggest another approach...

public void CreateActivity(string actName, int cost)
{
Activity a = new Activity(this, actName, cost);
activities.Add(actName, a);
}

// To get hold of a specific Activity within the
// plan, we can use an indexer...

public Activity this[string actName]
{
get { return (Activity) activities[actName]; }
}

// As we wanted to be able to iterate
// through the activites (e.g. with foreach)
// we simply borrow the one from our
// collection...

public IEnumerator GetEnumerator()
{
return activities.Values.GetEnumerator();
}
}

public class Activity
{
string name;
int cost;

// It's good practice to be consequential
// when naming fields.

Plan masterPlan;

public Activity(Plan mp, string actName, int cost)
{
this.masterPlan = mp;
this.name = actName;
this.cost = cost;
}
}
}

=====================================


Happy coding! :-)

// Bjorn A
 
Back
Top