Sign in to follow this  

Simple C# inheriting question

This topic is 3662 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have an options class with an option of showing the frame rate per second (FPS). How can I make this boolean type available in a separate class if that class is already inheriting a different class... since C# only supports single inheritance. Thanks, I figured that I would find out quicker by asking here.

Share this post


Link to post
Share on other sites
It sounds like you should be using aggregation not inheritance. At a basic level, only use inheritance when you want polymorphism i.e. to provide specialised behaviour like the strategy pattern (google it if unfamiliar).

Aggregation/composition is essentially the use of member variables e.g.


public class myclass : myparent
{
public Options options;
}


Share this post


Link to post
Share on other sites
Quote:
Original post by Zukix
It sounds like you should be using aggregation not inheritance. At a basic level, only use inheritance when you want polymorphism i.e. to provide specialised behaviour like the strategy pattern (google it if unfamiliar).

Aggregation/composition is essentially the use of member variables e.g.

*** Source Snippet Removed ***



OK, well I'm not sure how to implement aggregation. From your example, it was done the same way as inheritance with the colon after the class name and the inherited class after it.

Here's what I'm doing:


public class OptionsMenu : MenuScreen
// ^ its already inheriting
{
public bool showFPS = false;
}




public class Engine : Microsoft.Xna.Framework.Game
// also already inheriting ^
{
// need to use the boolean type from the previous class
if (showFPS == true)
{
// display FPS etc.
}

}

Share this post


Link to post
Share on other sites
Something like this:


public class Engine : Microsoft.Xna.Framework.Game
{
public void DoSomething()
{
// Access the member variable like this
if (myOptions.showFPS == true)
{
// display FPS etc.
}
}

// This is a member variable. Protected means it is not visible
// outside of this class
protected OptionsMenu myOptions = new OptionsMenu();
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Zukix
Something like this:

*** Source Snippet Removed ***


Thanks, I'm understanding now but I seem to be getting an error with the last line "protected OptionsMenu myOptions = new OptionsMenu();" stating that OptionsMenu is less accessible than the field...

The bool is public in the other class if that helps.

Share this post


Link to post
Share on other sites
If you have removed the 'public' from OptionMenu's class definition you might get this error because it will default to private.

Class declarations
public = visible outside of assembly (.dll\.exe)
private = only visible to classes inside the assembly


Member variable declarations
public = visible outside of class
private = only visible within the class's methods
protected = as private by also visible within sub-classes


The inconsistency would be that the OptionsMenu definition is not visible outside of the assembly but that someone could inherit from your Engine class and be able to access a member variable of this unknown type.

Class and member privacy is an OO concept called Encapsulation. Generally try to hide as many details about a class as possible so aim for private\protected. If just learning then keep all your classes public and keep member variables private. If you need to access them outside of the class then use properties (a C# way of accessing data often called accessor\mutator or get\set methods in other languages). Ignore the protected qualifier until having built up a bit more experience.

I hope this helps.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zukix
If you have removed the 'public' from OptionMenu's class definition you might get this error because it will default to private.

Class declarations
public = visible outside of assembly (.dll\.exe)
private = only visible to classes inside the assembly


Member variable declarations
public = visible outside of class
private = only visible within the class's methods
protected = as private by also visible within sub-classes


The inconsistency would be that the OptionsMenu definition is not visible outside of the assembly but that someone could inherit from your Engine class and be able to access a member variable of this unknown type.

Class and member privacy is an OO concept called Encapsulation. Generally try to hide as many details about a class as possible so aim for private\protected. If just learning then keep all your classes public and keep member variables private. If you need to access them outside of the class then use properties (a C# way of accessing data often called accessor\mutator or get\set methods in other languages). Ignore the protected qualifier until having built up a bit more experience.

I hope this helps.


Ah, I found the problem. The base class of OptionsMenu, MenuScreen, was set to abstract. However, due to how the class itself is coded, I cannot change it from abstract. Is there a way to do this without recoding the class so that I can change it from abstract to private?

The main question is, can I just change everything that is "abstract" to "private"? I am basing this code on someone else's sample.


Also, as a side question, what is the purpose of encapsulation? Memory conservation? Or is it it simply to limit what is available?

Thanks, you've been a lot of help!

Share this post


Link to post
Share on other sites
Abstractness shouldn't cause an accessibility inconsistency. Is it also private? You can just change protected to private in the example above.

The biggest enemy of software engineering is complexity. Complexity is a combination of the size of the program and the dependencies and relationships between its parts.

It won't take you long to find you are hitting brick walls with your programming where you are changing one thing and breaking ten others. To tackle this issue we attempt to reduce dependencies by hiding as much as we can from one part of a program from the others. This allows them to evolve independently so long as each part keeps the same interface i.e. the public methods.

This problem is magnified many fold when multiple people work on a project so its important to learn these things early.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zukix
Abstractness shouldn't cause an accessibility inconsistency. Is it also private? You can just change protected to private in the example above.

The biggest enemy of software engineering is complexity. Complexity is a combination of the size of the program and the dependencies and relationships between its parts.

It won't take you long to find you are hitting brick walls with your programming where you are changing one thing and breaking ten others. To tackle this issue we attempt to reduce dependencies by hiding as much as we can from one part of a program from the others. This allows them to evolve independently so long as each part keeps the same interface i.e. the public methods.

This problem is magnified many fold when multiple people work on a project so its important to learn these things early.

OK, so now I understand the motive behind encapsulation. Thanks!

The class, however, is not also private so I'm not sure what is causing the accessibility error.

OK, I'll write it out a bit to make things more clear:


public class Engine : Microsoft.Xna.Framework.Game
{
if (myOptions.showFPS == true)
{
// show FPS etc.
}
private OptionsMenuScreen myOptions = new OptionsMenuScreen();
}





public class OptionsMenuScreen : MenuScreen

//OptionsMenuScreen is underlined in error
//The error is:
//Inconsistent accessibility: base class MenuScreen is less accessible than class OptionsMenuScreen.
{
public bool showFPS = false;
}





abstract class MenuScreen : GameScreen
{

// contains various abstract methods that result in errors if changed from abstract

}





public abstract class GameScreen
{
}




Thanks again!

Share this post


Link to post
Share on other sites
If nothing is specified then it will default to private so change:


abstract class MenuScreen : GameScreen
{
}



to



public abstract class MenuScreen : GameScreen
{
}

Share this post


Link to post
Share on other sites

This topic is 3662 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this