Can a child class instantiate a parent class?! 1

[Coolstep]

Dear Members,
After designing a CLIENT class and i have 2 types of clients (AGENT & AIRLINE) so i thought of 2 inherited classes of this parent class. The AGENT class is identical to the parent class, so is it right to have such identical child class? knowing that the 2 child classes are related to each other ' An AGENT handles a group of airlines in a certain time interval and an AGENT may be a billable customer(Recieves bills generated) and other times an AIRLINE is billable.
I'm in a mess, can a child class instantiate its parent class?!

 

[TrojanWarBlade]

A class is a class is a class.
There is no reason why an AGENT can't have an array of AIRLINES and vice versa.
As to whether you should even have the AGENT class, there is value in it if it makes things clearer and more readable.
I wonder though if the parent class couldn't just be the AGENT class.


Trojan.

 

[Coolstep]

Thank you Trojan for your concern, I'll try to make things clearer.
I have tables:
Agent(id,name,numeric_code,alpha_code)
Airline(id,name,iata,icao,numeric_code,alpha_code)
AirlineAgent(airline_id,agent_id,from_date,to_date)

Suggested classes
Agent (id,name,numericCode,alphaCode, airlineAgent[])
Airline:Agent (iata,icao) <--Inheritance
AirlineAgent (airline, agent, from, to)

Do u think it's ok like this?

 

[BobRodes]

Two questions: If the agent class is identical to the client class, then what's the function of the client class? Also, is the airline an agent? In other words, does an airline also handle a group of airlines in a certain time interval?

Bob

 

[Coolstep]

Bob,
A1: In my system i generate invoices for billable customers, sometimes they are agents and other times they are airlines. So in design time i'll have to pass a parent class which i thought it to be CLIENT class. That's the only function for a CLIENT class.

A2: Actually an agent only can handle airlines and no agents can be handled and no airlines can handle any other airlines.

I hope i could clearify it, Thank you Bob for your concern

 

[TrojanWarBlade]

It sounds to me like you need three classes here, not two.
The parent I guess should be "BILLING". The AGENT and AIRLINE then inherit from that.
The general billing functionality should be in BILLING but any specifics live in AGENT or AIRLINE.
Although the AIRLINE might be a superset of AGENT, if you break it up like this it might make more sense.



Trojan.

 

[Coolstep]

Trojan,
You'r right, but if you revise the DB Tables, u'll find that there's nothing specific for billing issue, just every AGENT/AIRLINE will have its list of billings. Even if i have a billing class u'll find that many attirbutes are common between an AGENT and AIRLINE which is more sence to be specified i the parent class, but it can't. Till now I can't find other way than having AGENT as a parent and AIRLINE as its child. Is there any problem with such structure?
waiting your feedback
Thank you for your concern,

 

[TrojanWarBlade]

I was not suggesting for one second that your change your database. I was assuming that you were writing code to access it and therefore simply suggesting a structure that might make the code more sensible.
Maybe I'm being short sighted here cos it just occurred to me that you might be talking about database objects about which I know nothing so sorry if I'm confusing you.

Can you clarify please? What objects are you talking about?
Database objects? C++ objects? Java objects?

Trojan.

 

[grooke]

I believe that you ar building classes without having done the analysis.
Reading what you say, you have a domain of:
Airline, Agent, Customer, 'Billable Customer',
Bills (Sometimes called 'invoices'), 'AirlineAgent', Client,
you have a use case of
'Issue Bill'
You have rleationships from the table that
There is a many-to-many relationship between agent and airline, with a 'link' class, 'AirlineAgent' that identifies the period of time when the agent was an agent for that airline.

In your answer 'A1', who/what generates invoices? You say 'i', but it will be an object from a class. If it is an actor, then there will be some form of recognition of this in the classes. Bills dont just spin down out of the sky.

I would have guessed that the agents and the airlines generate bills, but your wording all implies that they receive them???? Are they bills for fuel or landing fees etc?

Bills are generated somewhere and passed to 'Billable Customers' who may be either an airline or an agent. 'CLIENT' seems to be another name for 'Billable Customer'. You should be aware of just using different words to mean the same thing (Bill = invoice), (Client =Billable Customer=Customer.) Draw little class diagrams. Name the classes and DO NOT deviate from that. If you cant describe something, then maybe you need another class. Draw it. Then make it fit into you story.

Your answer A2 now gives some more association rules.
Agents can handle (many) airlines; your table fits that.
Agents cannot handle agents; if agents and airlines are specialisations of 'Billable Customer, then this says that the agent-airline association MUST go between the two speciaised classes, and NOT from the agent to 'Billable Class' or indeed recursively from agent to agent.
This misses out one possibility. Can airlines handle one or more agents?

Then I come across the Class 'Billing' introduced by someone. NEVER give a class a name that is a verb as a name; somtimes application controllers can have such thing, but then be careful. Keep thinking about objects. I have never seen a 'Billing'. If you keep to objects and use cases until you get the basic analysis right, it will all come straight in the end. (Sorry to criticise someone trying to help. What they were saying is generally good advice, but that bit is wrong.)

----------------------
Summing up.
You have a parent class - BillableCustomer (id, name, numericCode, alphaCode)
Inheriting from this is - BillableCustomer::Agent()
Also inheriting is - BillableCustomer::Airline(iata, icoa)
The 'Agent' class is needed because you seem to have asymetric associations between the two children:
Agents (1..handle..*) Airlines
??? Airlines (1..handle..*) Agents ??? But you dont actually say this one does NOT exist.
If the second relationship exists, then you need a link class to resolve the (many..many) relationship.
If it does NOT exist, then the link class just becomes the lists of airlines that each agent had during the stated timescale. It houses the time periods appropriate to the agency-airline association, so it is still needed.

Now you also have a class of 'Bill', which is what is passed to the Billable Customer. Because it can be passed to one or the other of Agency or Airline, then it can be passed to the BillableCustomer without caring which specialisation is being developed. With this must be some form of 'Bill Generator'.

So there are 5 classes in that scenario. I suggest you try to draw the sequence diagram to sort these associations in you head; draw one for 'pass bill to agency' and one for 'pass bill to airline'. They should be identical to the one 'pass bill to BillableCustomer'. However, 'trace bill to airline' will give you two paths (or use cases).

Identify your classes and use cases and then design your classes. Finally code. Dont break this rule, but do practice getting so slick that some of these steps ar just done in you head as you 'hack' code.

Good luck. Gil

 

[BobRodes]

Like he says.

 

[Coolstep]

Dear Grooke,
Thank you very much for making me understand it and understand my mistake, I'v studied OO A&D and it's my first professional practice, my problem is i don't have someone to hand over what i'm doing, i'm doing it all by my own!. Do u think i can do it all by my own, or i should be lead by a professional OO Developer?
I appreciate all the participants ideas and advice

 

[grooke]

It is hard doing it on your own. It is useful to have someone to at least listen to your ideas.

You are designing these things for someone to use, and so I suggest that you at least do an occasional walk through what you have designed. The others may not be able to contribute a lot, but if you have trouble explaining your ideas, then maybe you should stand back and look at the work again. A walkthrough always helps the presenter more than any one else.

You have already done one walk through in this forum and I expect have changed you knowledge and approach by more than to total replies you got, because you will have added your own ideas and concerns to our replies.

Dont be frightened to have a go and dont be frightened to ask.

Keep going

Gil

 

[BobRodes]

Like he says.