-1

So i'm trying to organize my functions into nested classes so i can call them like: "Player.Trigger_Functions.TakeDamage()" rather than calling it as such: "Player.TakeDamage()". I suppose it is a less efficient way to call the functions the way I'm suggesting but it would help separate the functions into distinct categories while remaining on the same file.

Here is some test code but i can't get it to compile online to see if it works. (some of the functions need to be able to interact with each-other despite being in separate containers which i think is a problem)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;


public class Program
{
    public class meme{

        public int thicc = 0;

        public oof nest1 = new oof();
        public watermelone nest2 = new watermelone();

        public class oof : meme
        {

            public void here(){
            thicc++;
            }
            public void call(){
                 nest2.here();
                 System.Console.WriteLine("oof" + thicc);
            }

        }

        public class watermelone : meme
        {

            public void here(){
                thicc++;
            }
            public void call(){
                 nest1.here();
                 System.Console.WriteLine("watermelone" + thicc);
            }

        }



}



public static void Main(){
            meme me = new meme();

            me.nest1.call();//adding 1
            me.nest2.call();//adding 1
            System.Console.WriteLine("here is the current thicc value of the me class:" + me.thicc);


    }
}

Ok yeah so this code wouldn't work at all, i didn't put that much thought into it but you get the idea of what i'm trying to accomplish.

DED
  • 391
  • 2
  • 12
  • 2
    Unrelated: Better stick to commonly used Naming conventions. – Fildor Sep 04 '18 at 13:58
  • Do you means same Line (not Same File)? Use Write instead of Writeline(). Only use one WriteLine() after last item on the line. – jdweng Sep 04 '18 at 13:59
  • Why do you need this? – Samvel Petrosov Sep 04 '18 at 13:59
  • 1
    Why do want to do that? Do your classes have too many public functions? Maybe you can use Interfaces to group them rather than nested classes? – Fildor Sep 04 '18 at 13:59
  • Remember to [prefer composition over inheritance](https://stackoverflow.com/questions/49002/prefer-composition-over-inheritance) – Liam Sep 04 '18 at 14:01
  • `it would help separate the functions into distinct categories while remaining on the same file` There's nothing preventing you from keeping separate classes in the same file, without nesting. That's a Java rule not applicable to C#. Also, just use namespaces and make your life easier. – 3Dave Sep 04 '18 at 14:01
  • yeah i have too many public functions, what interfaces do you speak of? – DED Sep 04 '18 at 14:02
  • Your class structure is all over the place. You have a base class that contains the child classes that then implement the child classes... This is pretty crazy. I'm actually surprised the compiler lets you do this. All of that just to implement a `int`?! – Liam Sep 04 '18 at 14:02
  • 4
    Also, I'd be very surprised if this compiles, at all. `oof` inherits `meme`, so when `oof` is constructed, it will call `meme`'s constructor. Which creates an `oof`. Which creates `meme`. Which creates `oof`... see where this is going? – 3Dave Sep 04 '18 at 14:04
  • I'd get rid of `meme` altogether it's adding nothing here. Put your classes in separate files too. It's generally a bad idea to put everything in one class like this. – Liam Sep 04 '18 at 14:04
  • I don't get any idea to implement exactly what you want but you could use a static PlayerUtils class with a TakeDamage(Player player) in it – Mebius Sep 04 '18 at 14:06
  • "what interfaces do you speak of" - You can "mask" your methods from clients by providing interfaces, that your class implements. For example a client could take a "IDamageTaker" type argument. It defines the method "TakeDamage". Your client will only see this method. If your Player class implements that interface it can have many more methods and you can pass it as an "IDamageTaker" and the client will still only see the relevant methods. – Fildor Sep 04 '18 at 14:07
  • But actually ... I am suspicious your class does way too much ("separation of concerns"). Maybe it's a good idea to reconsider the architecture on the whole? – Fildor Sep 04 '18 at 14:09
  • 2
    I started writing an answer but then I noticed your `thicc` variable...my best advice I think is throw all this away. Read more on inheritance then try again. This is very wrong. – Liam Sep 04 '18 at 14:10
  • What do I mean by "your class does way too much" - For example "Player.TakeDamage()" - is it the Player's responsibility to compute damage taken? - I'd say no. Perhaps it is its responsibility to "know" its current health. How much damage is to be taken and when should be the concern of the game engine (and there probably a subsystem). – Fildor Sep 04 '18 at 14:15
  • Suppose i'll just have separate partial class files for the functions since there isn't really a way to easily identify each category of functions without separating them into static classes and constantly needing to pass the player class to every function. – DED Sep 04 '18 at 14:28

1 Answers1

1

You can use interfaces to break up the functionality of your class into related groups.

From this:

class Person
{
    void sayHello() { }
    void sayGoodbye() { }
    void walkForward() { }
    void walkBackward() { }
}

Refactor into this:

interface ISpeak
{
    void sayHello();
    void sayGoodbye();
}

interface IWalk
{
    void walkForward();
    void walkBackward();
}

class Person : ISpeak, IWalk
{
    void ISpeak.sayHello() { }
    void ISpeak.sayGoodbye() { }
    void IWalk.walkForward() { }
    void IWalk.walkBackward() { }
}

class Program
{
    static void Main(string[] args)
    {
        Person person = new Person();
        IWalk walk = person;
        ISpeak speak = person;
        speak.sayHello();
        walk.walkForward();
    }
}
Wyck
  • 10,311
  • 6
  • 39
  • 60