Object Orientation

Moderators: None (Apply to moderate this forum)
Number of threads: 44
Number of posts: 76

This Forum Only
Post New Thread
Single Post View       Linear View       Threaded View      f

Report
Simple question Posted by c4scroller on 21 Aug 2003 at 2:49 PM
Hi there,

I have a simple question involving member inheritance in Java; I was wondering what the best way of tackling this sort of design issue is. I will describe an example.

There are two types of Gun, a simple one, used by Soldiers:

class Gun {}

and an advanced one, SilencedGun which only Commanders can use. SilencedGun is a subclass of Gun:

class SilencedGun extends Gun { }

Now, a Soldier is defined as:
class Soldier {
???? Gun gun; // see later

public void setGun(Gun g) {
gun = g;
}
public Gun getGun() {
return gun;
}
}

class Commander extends Soldier {
...
}

My question is this: How do we best code a Commander class, such that only SilencedGuns can be possessed by a commander, and never simply a Gun? If we leave the Commander class empty, then any client can call commander.setGun(new Gun()), which we don't want to happen. What access specifier should gun in the parent class have?

Should I overwrite gun in Commander to be of type SilencedGun, and then add new get/set of type SilencedGun? Will that stop clients calling the superclass methods?

What is the best solution to this sort of issue?

Thanks for suggestions.
GS
Report
Re: Simple question Posted by ytvsoftware on 16 Jan 2004 at 2:25 AM
: Hi there,
:
: I have a simple question involving member inheritance in Java; I was wondering what the best way of tackling this sort of design issue is. I will describe an example.
:
: There are two types of Gun, a simple one, used by Soldiers:
:
: class Gun {}
:
: and an advanced one, SilencedGun which only Commanders can use. SilencedGun is a subclass of Gun:
:
: class SilencedGun extends Gun { }
:
: Now, a Soldier is defined as:
: class Soldier {
: ???? Gun gun; // see later
:
: public void setGun(Gun g) {
: gun = g;
: }
: public Gun getGun() {
: return gun;
: }
: }
:
: class Commander extends Soldier {
: ...
: }
:
: My question is this: How do we best code a Commander class, such that only SilencedGuns can be possessed by a commander, and never simply a Gun? If we leave the Commander class empty, then any client can call commander.setGun(new Gun()), which we don't want to happen. What access specifier should gun in the parent class have?
:
: Should I overwrite gun in Commander to be of type SilencedGun, and then add new get/set of type SilencedGun? Will that stop clients calling the superclass methods?
:
: What is the best solution to this sort of issue?
:
: Thanks for suggestions.
: GS
:

Report
Re: Simple question Posted by ytvsoftware on 16 Jan 2004 at 3:06 AM
If you create the empty class that extends another class it will be full equvalent of the class from which it was derived. The derived class define a subset of the base class instances. So it need somehow define the differences for or it will be just another name of one. So both the silGun and commander has to have something additionaly defined to differenciate from their base classes. The main idea of OOP related to reuse and economizing effords of programmers is overwriting of functions in the extended/derived class. So the subroutines for processing of base class instances automatically are changed when processing elements/instances of the subset/derived/extended class.
In your example the main question is how you define the silence gun difference from gun in terms of class definition. I would not be surprised if actually it can happen that both sil gun and soldjer gun should be derived from a vase gun, or silence gun should be base for Gun. The comon mistake is to think that class design is something simple. Actually it is requres the highest level of programming skills to be eficient. I saw already projects when unskilled use of OOP made
the logic absolutely ununderstandable and large bad performing filled by errors programs.

: : Hi there,
: :
: : I have a simple question involving member inheritance in Java; I was wondering what the best way of tackling this sort of design issue is. I will describe an example.
: :
: : There are two types of Gun, a simple one, used by Soldiers:
: :
: : class Gun {}
: :
: : and an advanced one, SilencedGun which only Commanders can use. SilencedGun is a subclass of Gun:
: :
: : class SilencedGun extends Gun { }
: :
: : Now, a Soldier is defined as:
: : class Soldier {
: : ???? Gun gun; // see later
: :
: : public void setGun(Gun g) {
: : gun = g;
: : }
: : public Gun getGun() {
: : return gun;
: : }
: : }
: :
: : class Commander extends Soldier {
: : ...
: : }
: :
: : My question is this: How do we best code a Commander class, such that only SilencedGuns can be possessed by a commander, and never simply a Gun? If we leave the Commander class empty, then any client can call commander.setGun(new Gun()), which we don't want to happen. What access specifier should gun in the parent class have?
: :
: : Should I overwrite gun in Commander to be of type SilencedGun, and then add new get/set of type SilencedGun? Will that stop clients calling the superclass methods?
: :
: : What is the best solution to this sort of issue?
: :
: : Thanks for suggestions.
: : GS
: :
:
:

Report
This post has been deleted. Posted by isa6699 on 7 May 2009 at 11:49 PM
This post has been deleted.
Report
Re: Simple question Posted by mobman80 on 22 Aug 2009 at 12:34 PM
That's a text book perfect answer!

I'm looking for a full life cycle Software Development book.
Can you recommend one?

Cheers

Kris
http://www.kremsoft.com



 

Recent Jobs

Official Programmer's Heaven Blogs
Web Hosting | Browser and Social Games | Gadgets

Popular resources on Programmersheaven.com
Assembly | Basic | C | C# | C++ | Delphi | Flash | Java | JavaScript | Pascal | Perl | PHP | Python | Ruby | Visual Basic
© Copyright 2011 Programmersheaven.com - All rights reserved.
Reproduction in whole or in part, in any form or medium without express written permission is prohibited.
Violators of this policy may be subject to legal action. Please read our Terms Of Use and Privacy Statement for more information.
Operated by CommunityHeaven, a BootstrapLabs company.