Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I m implementing interface which is in other assembly as projected. I have added assembly reference and name space but cannot access it ? I want to implement it in my class and of course interface and class are in different assemblies. I m getting compile time error "cant access due to protection level.."
to me it looks weried. Can't I access this interface without making it public ?
Code:
namespace DAL
{
interface IStdService
{
}
}
You cannot have anything in a namespace marked protected. Only internal and public are possible.
It is only possible to do these since the others won't make sense. As O.R. Mapper already said, this only makes sense if they are part of an class already.
If you write this code:
protected interface IInterface
{
}
It gives the error at compile time:
Elements defined in a namespace cannot be explicitly declared as private, protected, or protected internal
This does compile:
internal interface IInterface
{
}
and it will make the interface available only inside the assembly, unless you make it available through the InternalsVisibleTo attribute.
The code in your latest sample:
interface IInterface
{
}
marks the interface internal which is the default for classes, interfaces, etc, but with interfaces this means they are only available inside the assembly, as explained before.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am confused with these implementations .In an interview,interviewer asked me what is composition and I gave him typical definition then I wrote this part of code for him.
public class Foo {
private Bar bar = new Bar();
}
But he claimed this implementation is correct
interface IFoo
{
int DoSomthing();
}
class Bar : IFoo
{
public int DoSomthing()
{
throw new NotImplementedException();
}
}
Which one is correct?
Edit: I realize now that both you and your interviewer were correct; answer updated accordingly.
From the wikipedia page on Composition over inheritance:
Composition over inheritance...is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.
Polymorphism is
the provision of a single interface to entities of different types.
So what you did (having Bar be a property of Foo) is Composition because Bar has an instance of Foo through having it as a property.
What your interviewer did was also Composition because, through the interface IFoo, Bar implements the same functionality, and it didn't use inheritance to do so. This appears to be the way it's documented on the linked wiki page but doesn't mean your way is wrong either.
Which method you use for implementing the same functionality in different places would depend on whether it makes sense for Bar to be a property of Foo or not.
Composition denotes a "is-a-part-of" relationship between objects. For example,
class Engine
{
//....
}
class Car
{
Engine engine = new Engine();
//.....
}
we can see, Engine is-a-part-of Car. Composition and inheritance are two different concepts and you probably shouldn't accept a job offer where he would be your boss. :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Imagine we have an interface like below:
public interface ISome
{
void MethodOne();
int MethodTwo();
string MethodThree();
}
A class implements the interface:
public class Some : ISome
{
// Implementation...
}
Here is how it may be used:
public class App
{
public App(ISome)
{
// This class needs the whole interface: All three methods
}
}
I have a new requirement and it only needs one method from it: MethodThree and it can use the implementation provided by Some. Now I have 2 options:
Use ISome in the new class, like App uses it. The problem with this is that the new class does not really depend on the whole interface but only one method.
Split the interface like this using inheritance:
public interface INewSome
{
string MethodThree();
}
public interface ISome : INewSome
{
void MethodOne();
int MethodTwo();
}
The benefits of the 2nd option are:
The new class will depend on INewSome
Some still implements the whole interface so existing code will not break.
Unit testing will be much clearer since we know we just need to mock/stub one method in INewSome
Questions
I cannot think of a benefit for option 1 aside from not having to introduce a new interface. Do you know of a benefit with option 1?
Do you have another suggestion?
Am I overlooking anything and is this good/bad design?
what you have done in the option 2 is correct and goes perfectly with the fourth goal which is Interface Segregation Principle
From Wikipedia many client-specific interfaces are better than one general-purpose interface
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I want to dynamically access classes in c# in the way like Java class.forName(). I have only found things like Class.forName() equivalent in .NET? but I don't want to create instances.
In detail: I have got a simple text file containing a list of classes. I read them using file.ReadLine() (so I have got all class names as strings) and then I want to execute the same static method on each class: class1.method(); class2.method; and so on. The classes all exist and I need to access them. How can I do that?
C# doesn't support static interfaces (or static members in interfaces), so unless you want to use factory classes (the usual approach), you'll need to use reflection to invoke the static method directly.
void Main()
{
Console.WriteLine(Type.GetType("A").GetMethod("Hi").Invoke(null, new object[] {}));
}
class A
{
public static string Hi() { return "Hi!"; }
}
You might want to use a fully-qualified name for the type to make this work really well. Using just the name of the type is tricky, especially when you're trying to invoke types from other assemblies (which you probably are, otherwise there'd be no reason to use reflection - just use a dictionary of delegates or whatever).
You can use System.Reflection to load the Assembly into memory and then drill down to the type followed by getting the required method and invoke.
Refer to the documentation
GetMethod
If you have names of your desired Type then you can use Type.GetType(string) method.
Example if you have a class like this :
namespace MeProgram.BusinessLogic
{
public class MeObject {}
}
Full class name of that object should be "MeProgram.BusinessLogic.MeObject".
Now you can use that name inside of Type.GetType(string) method like such :
string className = "MeProgram.BusinessLogic.MeObject";
Type classType = Type.GetType(className);
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I've got a class that implements an interface:
public class SQLiteHHSDBUtils : IHHSDBUtils
{
void IHHSDBUtils.SetupDB()
{
. . .
if (!TableExists("AppSettings"))
. . .
bool IHHSDBUtils.TableExists(string tableName)
{
. . .
It can't find its own brother sitting right below it (the if (!TableExists()):
The name 'TableExists' does not exist in the current context
How can it / why does it not see it?
You have an explicit interface implementation. You can't access your interface methods directly unless you cast current instance to interface type:
if (!((IHHSDBUtils)this).TableExists("AppSettings"))
From 13.4.1 Explicit interface member implementations
It is not possible to access an explicit interface member implementation through its fully qualified name in a method invocation, property access, or indexer access. An explicit interface member implementation can only be accessed through an interface instance, and is in that case referenced simply by its member name.
When you explicitly implement an interface, you need to access the interface member from a variable whose type is exactly the interface (not an implementing type).
if (!TableExists("AppSettings")) is calling TableExists via the this object, whose type is SQLiteHHSDBUtils, not IHHSDBUtils.
Try:
if (!((IHHSDBUtils)this).TableExists("AppSettings"))
Alternatively, don't explicitly implement the interface:
public class SQLiteHHSDBUtils : IHHSDBUtils
{
// ..
bool TableExists(string tableName)
{
// ..
TableExists is an explicit implementation. If you want to access it, you have to cast this to IHHSDBUtils:
void IHHSDBUtils.SetupDB()
{
. . .
if (!((IHHSDBUtils)this).TableExists("AppSettings"))
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have an interface:
public interface IMyObject
{
}
I have an abstract class:
public abstract class MyObject : IMyObject
{
}
And I have a class:
public class MyExtendedObject : MyObject
{
}
There are many interfaces, abstracts and concretes like this in my project. I wonder what is the best scenario to organize the code in namespace (folders in project) point of view. Should I put all related stuff under the same folder or should create, for example a Base namespace for abstract classes, Interfaces namespace for interfaces and another namespace for extended objects?
The best way is subjective and poject dependent.
Like a suggession I would say:
move in separate folder interfaces and abstract classes, so separate them from concrete implementation classes.
+ Absrtacts
-> IMyObject.cs
-> MyObject.cs
+ Concrete
-> MyExtendedObject.cs
Robert C. Martin (one of the founding fathers of Agile and now the Software Craftmanship movement) has a whole talk on that that is really worth watching
It's based on Ivar Jacobson's Object Oriented Software Engineering: A Use Case Driven Approach.
To summarize it in a few sentences, your project structure should reflect what it models and not the technology or particular language constructs you use. In the case of your abstract/interface/concrete classes this means that using a structure where you put all your abstract classes in a folder/namspace/assembly, your concrete classes in another folder/namespace/assembly is not the way to go (even though it is very common to find projects where this approach is taken).