Is it possible to hide methods to certain classes?

[GroZZleR]

Hey all,

I have 3 classes. Let's call them Plane, Pilot and Passenger.

I'm trying to restrict Passenger's access to Plane's more intimate
methods, but allow Pilot to use 'em.

Right now I have this "useless" interface that creates basic methods,
then Plane implements that interface to add more.

For example:

PlaneInterface
- Enter()
- Exit()

Plane : PlaneInterface
- TakeOff()
- Land()

When the passenger needs to use the Plane, I downcast the object to a
PlaneInterface so that Passenger only sees the Enter and Exit methods.

Is there a better method to restricting access of certain methods to
certain classes?

 

[Peter Thornqvist]

AFAIK, you can't hide methods to specific classes/interfaces. There is two
ways of handling this tha I can think of:

Option 1: supply the pilot as a required parameter:

void TakeOff(PilotInterface Pilot);
void Land(PilotInterface Pilot);

Option 2: control access with a property:

Plane: PlaneInterface
{
PilotInterface Pilot { get; set; }
void TakeOff(); // will only take off if Pilot is assigned
void Land(); // will only land if Pilot is assigned
}

 

[Guest]

Hi,
you can't hide methods based on the caller but a way around it would be to
move the passenger into a different project than plane and mark metgos
internal, kind of a yucky way.

Mark.

 

[Bruce Wood]

Hey all,

I have 3 classes. Let's call them Plane, Pilot and Passenger.

I'm trying to restrict Passenger's access to Plane's more intimate
methods, but allow Pilot to use 'em.

Right now I have this "useless" interface that creates basic methods,
then Plane implements that interface to add more.

For example:

PlaneInterface
- Enter()
- Exit()

Plane : PlaneInterface
- TakeOff()
- Land()

When the passenger needs to use the Plane, I downcast the object to a
PlaneInterface so that Passenger only sees the Enter and Exit methods.

Is there a better method to restricting access of certain methods to
certain classes?

No... you found the best way to do that.

The interface isn't useless. It represents a subset of functionality of
interest to some consumers of the class but not others. In fact, yours
is a very good design.

 

[Fabio]

Hey all,

I have 3 classes. Let's call them Plane, Pilot and Passenger.

I'm trying to restrict Passenger's access to Plane's more intimate
methods, but allow Pilot to use 'em.

Right now I have this "useless" interface that creates basic methods,
then Plane implements that interface to add more.

For example:

PlaneInterface
- Enter()
- Exit()

Plane : PlaneInterface
- TakeOff()
- Land()

When the passenger needs to use the Plane, I downcast the object to a
PlaneInterface so that Passenger only sees the Enter and Exit methods.

Is there a better method to restricting access of certain methods to
certain classes?

If you cannot join the puzzle pieces means that... they don't have joinable
shapes.

Is the subject that do actions, not the object:

class FlyingPerson
void EnterIn(Plane)
void Exit()

class Passenger : FlayingPerson
void LockTheBelt()

class Pilot
void BeginPilot()
void EndPilot()

class Plane
List<Passenger> Passengers
List<Pilot> Pilots
void TakeOff()
void Land()

In this way your pieces can interact with each others without strange
workarounds.

 

[Bruce Wood]

If you cannot join the puzzle pieces means that... they don't have joinable
shapes.

Is the subject that do actions, not the object:

class FlyingPerson
void EnterIn(Plane)
void Exit()

class Passenger : FlayingPerson
void LockTheBelt()

class Pilot
void BeginPilot()
void EndPilot()

class Plane
List<Passenger> Passengers
List<Pilot> Pilots
void TakeOff()
void Land()

In this way your pieces can interact with each others without strange
workarounds.

I can see this design getting into a lot of trouble later on.

From the context of regular life, a person is a passenger only some of

the time... only while they're on a plane. Therefore, making a
passenger a whole separate class doesn't make much sense. Besides, what
do you do when a pilot flies as a passenger? Do you record them as two
separate entities: person-as-pilot being different from
person-as-passenger? You might, or you might not.

If, however, your system only ever sees passengers and doesn't see them
in any other context, then this sort of design will work.

I prefer the original design: just use interfaces to implement the
various capabilities of Person, and then you can write code that deals
with people in their different aspects and roles, while having only one
object representing one person.

 

[Fabio]

I can see this design getting into a lot of trouble later on.

the time... only while they're on a plane. Therefore, making a
passenger a whole separate class doesn't make much sense. Besides, what
do you do when a pilot flies as a passenger? Do you record them as two
separate entities: person-as-pilot being different from
person-as-passenger? You might, or you might not.

It depends on what GroZZleR want to do.
He can also get troubles in the way he started with.

I just don't like objects that act as subjects.

 

[Bruce Wood]

It depends on what GroZZleR want to do.
He can also get troubles in the way he started with.

I just don't like objects that act as subjects.

Well, there's always an easy way around that: just invert the verb.
Instead of having an Enter method on the Plane interface that accepts
an IPassenger argument, you could have an AcceptPassenger method
instead. Subject-object relationships are often invertible: it just
depends upon how you look at it.

(That is to say, often subject-verb-object relationships represent
establishing, modifying, or breaking a relationship, and that
relationship can be seen from either point of view.)

 

[Fabio]

Well, there's always an easy way around that: just invert the verb.

Yes, you're right