koobas.hobune.stream
Should I do all interfaces in one script?
I've been wondering about what I should use for interfaces, separate interfaces for each script? Or would it be wiser to put all interfaces in one script and implement them from there?
I rather separate the scripts, because of the order of compilation.
I thought it'd be more of a preloading system so that I could keep all of the interfaces somewhere accessible, and load all of them at the beginning of the game.
In the meantime, I'm still confused on how to actually use an interface. I know how to make an interface, but whenever I try to actually implement it into another script, I get a compiler error saying: error CS0246: The type or namespace name `canTakeHostage' could not be found. Are you missing a using directive or an assembly reference?
An interface is simply a contract that says 'Anything that implements this interface will implement the following methods...'
Each interface should be in its own file, and each implementation of that interface should be in its own file as well. What does your interface look like?
What does your implementation look like?
Don't use scripts on other namespaces. Unity works only with the main namespace, that is why you don't see any namespace declaration in Unity scripts.
If you do use namespaces for your non-Unity classes and interfaces, be sure that you add the using clause for that namespace: using yourNameSpaceName;
Based on the code you posted in your comments, you've actually defined an interface within another class.
Code works with the idea of 'scope,' or levels of access. What you've done in made it so the TileInterfaces class is the only one that knows about the canPlantCharge interface.
canPlantCharge should be the top level scope in the file, meaning the entirety of the canPlantCharge.cs file should be
public interface canPlantCharge
{
void PlantCharge();
}
Alternatively, you could make your WallFunctions say:
public class WallFunctions: MonoBehaviour, TileInterfaces.canPlantCharge {
But that is all manner of strange, in my opinion.
More on scope:
public class ScopeExample: MonoBehavior
{
// Everything declared here is at 'class scope'
// which means they can interact with each other.
// This includes fields, methods, and properties.
// Using the 'public' keyword allows other entities
// outside of this class to access certain class scope items
public int a; // accessible from outside the script.
public void Method1()
{
// Everything declared in here is at 'method' or 'local' scope.
// Things here have access to other items defined in this method,
// as well as all things defined at class scope level
a = 10; // valid
int b;
if (true)
{
// variables declared here will 'fall out of scope'
// at the end of this if block. This means you can use
// them between these curly braces, but not after.
// You still have access to local and class scope variables here!
int c;
a = 11; // valid
b = 12; // valid
c = 13; // valid
}
a = 14; // still valid
b = 15; // still valid
c = 16; // NOT valid!
}
public void Method2()
{
// Even though we are at local scope again, we are in a different
// 'local' so things which are declared in Method1 are not accessible here!
int d;
a = 17; // still valid
b = 18; // NOT valid
d = 19; // valid
}
}
I already know exactly how scope and access modifiers work. I'm not a complete beginner.
That's great! You still messed up your scope there, though.
Exactly :) If you declare "canPlantCharge" inside the class "TileInterfaces", when implementing that interface you would have to use
public class WallFunctions : $$anonymous$$onoBehaviour, TileInterfaces.canPlantCharge
{
Its really up to you. One thing to consider is reusability of the interfaces/script file in other projects.
Unity will not care either way.
While I agree that technically you can define as many interfaces, classes, structs etc. as you want in any file, I strongly disagree that you should do so.
@Habitablaba you are correct. Hence why I called out reusability as a concern. Two unrelated classes/interfaces/structs have no business being in the same file.
On the other hand there is some benefit from including related classes in the same file. Say the IDamagable and the IDealsDamage interfaces.
When the interfaces and classes get complex you its also worth considering separate files inside a namespace.
When it comes to the final product however Unity does not care. The entire script files structure is compiled away. So there are no real efficiency gains to be had.
Another thing is: version control! When you have your project in a git / svn / ... repository it's always a good idea to have every class / interface / enum / ... inside it's own file, named like contained type. That way you see in the version history when you changed something on a particular enum / interface.
Sometimes it looks / feels a bit cumbersome, but for large projects it's a must. To organise elements you usually use namespaces and folders.
