We Keep Coding

(ASP.Net Core API, EF Core) Issue Registering Interface Attached to Class with 2 Children

I've tried quite a few different things and have tried every magic Google search word I could think of. If I missed something, feel free to virtually slap me and point out what is probably obvious.
Anyways, I am building an API that, without getting into too many details, will handle a couple different types of order submission. Let's call them type A and B. There are quite a few similarities between those two types, so I made one interface and a parent class to handle them both. I then made two children classes that inherit from the parent class and those children handle all the stuff specific to their respective type. The controller calls the thing that gets the order type, calls something from the parent class, and then calls the appropriate child class. So the idea is:
Interface IOrderSub
Parent class OrderSub - inherits from IOrderSub
Child class OrderSubTypeA - inherits from OrderSub
Child class OrderSubTypeB - inherits from OrderSub
This is where it all breaks down. I am having a rather "fun" time trying to register IOrderSub and those classes. I keep getting an error that I am trying to convert IOrderSub to OrderSub once the code hits:
var app = builder.Build();
in Program.cs.
Things I have tried:
Having the child classes inherit from IOrderSub.
Having the child classes inherit from IOrderSub and OrderSub.
Creating an enum of the order types and using AddTransient<>, Func<>, and a case-switch to determine the order type to register in Program.cs. Visual Studio skips over this whole line when I step through.
public enum ServiceType
{
TypeA,
TypeB,
Parent
}
builder.Services.AddScoped<TypeA>();
builder.Services.AddScoped<TypeB>();
builder.Services.AddScoped<Parent>();
builder.Services.AddTransient<Func<ServiceType, IOrderSub>>
(serviceTypeProvider => key =>
{
switch (key)
{
case ServiceType.TypeA:
return serviceTypeProvider.GetService<OrderSubTypeA>();
case ServiceType.TypeB:
return serviceTypeProvider.GetService<OrderSubTypeB>();
case ServiceType.Parent:
return serviceTypeProvider.GetService<OrderSub>();
default:
return null;
}
});
All different manners of things inside AddScoped<> for the interface and classes.
Having child interfaces that inherit from the parent IOrderSub and having each of the child classes inherit from their respective child interface.
Combinations of the above things.
Various other things I can't remember. The above 6 are what are coming to mind. I've been at this at least a couple days.
I would prefer to keep the class inheritance as I think it just makes sense in this situation due to how similar yet different the two order types are. I did get everything to a point where there are no syntax errors, but I still run into that runtime error.
Anyone have any ideas on how to get this to work, please? I tried to provide as much information as I could, but I'll keep an eye out to see if more is needed.
Thank you!

Thanks to someone asking for the code and my having to go through it with a very fine-toothed comb to remove all references to DB tables and what-not, I realized the issue described above existed between my keyboard and my chair.
I had forgot I had made OrderSub abstract in an attempt to get Visual Studio to stop yelling at me that a method defined in IOrderSub was not in OrderSub (abstract class, defined that method abstract in OrderSub).
I removed any reference to abstract and method overrides and just defined the method as normal. Apparently I had never tried this rather simple solution, as I could just put "new" on the methods in the two child classes and the OrderSub method declaration was effectively "hidden". Not that that is relevant to this. Maybe I'll make a separate question and answer it myself for this issue.
Have a good day all!

Understanding Interfaces in OOP

I am trying to learn OOP concept at an advance level. I was reading through the topic interfaces and have a confusion. But first, let me show you what exactly caused this confusion.
I tested this Code Sample. but I am confused with the use of interfaces. After implementing that code, it seems to me that I can call the method DoFirst from class A by simply creating an instance of it. so why use an interface at first place?
Something like this:
A myA = new A();
myA.DoFirst();
and similiarly,
B myB = new B();
myB.DoFirst();
In both the classes, i have to implement a method called 'DoFirst', so what good does interface provided to me?
Can't I just write these methods in different classes myself?
my Second question, say I have an interface that has 5 methods. If a class implements it, and only wants to provide implementation of 3 methods instead of writing code of all 5 methods supplied by the interface. Isn't this useless? why have access methods that i don't want?
can somebody answer these with example (Highly appreciated) please?

The advantage was already pointed out in the link you provided...
Basically you can also write
void DoSomething(IMyInterface obj)
{
obj.DoFirst();
}
And then send any type of object which implements that interface as a parameter.
A myA = new A();
DoSomething(myA);
B myB = new B();
DoSomething(myB);
The method DoSomethig doesn't care about the object's type, as long as it exposes an interface called IMyInterface.

Some Real Life examples - also, another way/reason to use interfaces.
In my own code I have an Engine which processes code to produce reports in Excel. In this engine, i had to write the code two different ways, one using the Microsoft Excel Interop, the other using the Open Office Interop. Rather than duplicate my entire engine to work two different ways, or write a lot of if statements in all the actual interop functions, I implemented an interface. Then I declared two classes, each one implementing the interface, but one uses Excel and the other uses open office. Then, in my code, I simple reference the interface and its functions and use a single if statement at the very beginning of the function to tell the interface which class to implement.
public class ExcelEngineInterop : ISSinterface
{ ... }
public class OOEngineInterop : ISSinterface
{ ... }
//cant use two variables with the same name, so use 1 interface reference instead
ISSinterface ssInt;
if(ExcelFlag)
ssInt = new ExcelEngineInterop();
else
ssInt = new OOEngineInterop();
//two VERY different functions between Excel and OpenOffice.
ssInt.OpenApp();
ssInt.OpenFile(fileName);
//etc etc and so on
This is the other reason to use an interface. When you need one block of code to act two (or more) different ways depending on some external flag.
Another Example.
There is a top level form with lots of custom user controls under it. The user fires a form level event, like a button click, but depending on which user controls are active and what settings are on them at the time the click happens, the controls themselves need to do something different. Rather than writing what could be a rediculously large number of if statements to make sure each one acts correctly from the top level, just implement an interface on each control, then do something like this:
public ButtonClick(object sender, EventArgs e)
{
//note: I dont know which of my classes currentrightcontrol belongs to at the moment.
// it could be any one of 22 different controls. It must be cast to something
// in order to call the ButtonClick method (its actual type is generic "UserControl"
IMyRunControl ctrl = CurrentRightControl as IMyRunControl;
ctrl.FormButtonClicked();
}

C# is a statically typed language (at least unless you explicitly tell it not to be). This means that the compiler uses the type of the variable to know whether the referenced object has the members you are about to use.
The interface, therefore, provides a contract to the compiler (and to other programmers, too) that this class implements that interface. Because interfaces can be shared across classes that don't have a hierarchical relationship, this means that you can define a method that can take an object as an argument by defining that interface in the parameter type.

What is better -to call empty methods or to use many interfaces

I'm having a few classes that have one base class named Tool.
In form i have one Tool reference that contains one of the instaces of mentioned classes.
When a MouseDown event occurs on the form i call the current Tool Method ex. "CurrentTool.MethodWhenMouseDown()".
Most of Tools are having 3 methods:
MethodWhenMouseDown()
MethodWhenMouseUp()
MethodWhenMouseMove()
But one or two classes are having just:
MethodWhenMouseDown()
Now which is better:
1.To have all three methods in Tool and the the classes that don't need them just call empty methods.
2.To implement interfaces ex. IMouseMoveListener that would be implemented just by the classes that need to act when MouseMove event occurs. This way if MouseMove event occurs we would ask:
if(CurrentTool is MouseMoveListener)
{
(CurrentTool as IMouseMoveListener).MethodWhenMouseMove();
}
Additional information:
The program is like Ms Paint - the tools are Brush,Bucket(the one that don't need MethodWhenMouseMove),LineTool etc.
In my PaintForm i have one reference of abstrac base class Tool that stores instace one of derived class. The thing that fires event is pictureBox.
Have you considered events to which the tools subscribes? – CodesInChaos
I thougth it would be good practice to have a method in form, that would be called after an evet occurs and the method is calling the siutable method of CurrentTool. ex:
void MouseMoveSubscriber(object sender, MouseEventArgs e)
{
CurrentTool.MethodWhenMouseMove(e);
}
I assume subscribing and unsubscribing the method of CurrentTool each time the CurrentTool was changed a bad practice? I also thought about having all tool refereces in Form and the event would be subscribed by each tool and there would be no need of unsubscrinig. The big drawback in my opinion is that each tool needs to check if it is the CurrentTool.
What you think about it? Thanks for help given.

Performance is not an issue (when the user clicks, the overhead of calling an empty function unnecessarily is of no significance), so this is really about coding ease and code clarity/complexity/maintainability.
So I'd keep it as simple as possible.
I would implement a base class with empty implementations, as this is clean and simple. It requires minimal code in a derived class to get the results you need. It also makes sense (If you don't override the click upcall, you are essentially saying "when a mouse is clicked I wish to do nothing about it").
The next option would be to provide events for mouse up/down/click, and have derived classes subscribe to the events if they wish to. Using events is a standard pattern, but it has the drawback that you have to mess around with the ugly subscription and unsubscription calls. The benefit of this is that if you make them public, these events can be handled by anybody, not just derived classes.
I'd avoid using interfaces and casting - to me this feels like a clunky approach - all it really achieves is fragmenting the "empty functions" approach across a number of different types instead of a simple set of 3 virtual methods. And instead of just calling the methods and knowing they will work, you have to do a lot of type casting and checks first - it just seems messy.
edit
Since you've added some more to the question, I've re-read it and another possibility springs to mind: Create a base Tool class that provides the virtual MouseDown handler that all derived classes need to override. All the normal tools would derive form this.
An additional DragTool class could the derived as an intermediate class that adds the MouseMove and MouseUp handlers that are needed for your special couple of dragging tools.
i.e.
ToolBase (abstract MouseDown)
|
+- ClickTool1
+- ClickTool2
+- DragToolBase (abstract MouseMove + MouseUp)
|
+- DragTool1
+- DragTool2
This would meant there would be no empty implementations in any of your tools.

Without knowing your scenario, I would go with a combination of interfaces and base class:
The base class implements all interfaces with empty virtual methods. The base class is a pure convenience construct. If a tool class wants to inherit from the base class but doesn't need the method it doesn't override it.
In the code that consumes the tools you would work soley with the interfaces. Like this other classes are free to directly implement your interfaces. You gain maximum flexibility like this without any sacrifices.
var mouseMoveListener = CurrentTool as IMouseMoveListener;
var mouseDownListener = CurrentTool as IMouseDownListener;
// ...
if(mouseMoveListener != null)
mouseMoveListener.MethodWhenMouseMove();
if(mouseDownListener != null)
mouseDownListener.MethodWhenMouseDown();
Please note: I used as only instead of is in combination with as.

It depends on actual case. But in your specific case (UI events) I think that have base class with empty handlers (virtual methods) is better than a lot of interfaces. Actually all your tools will inherit from some ToolBase. And invocation code will be smaller and simplier without casting to interfaces.

Reusable Class Library Implementation

I've built a reusable Class Library to encapsulate my Authentication logic. I want to be able to reuse the compiled *.dll across multiple projects.
What I've got works. But, something about how I'm making the reference, or how my Class Library is structured isn't quite right. And I need your help to figure out what I'm doing-wrong/not-understanding...
I've got a Class Library (Authentication.dll) which is structured like this:
namespace AUTHENTICATION
{
public static class authentication
{
public static Boolean Authenticate(long UserID, long AppID) {...}
//...More Static Methods...//
}
}
In my dependent project I've added a reference to Authentication.dll, and I've added a using directive...
using AUTHENTICATION;
With this structure I can call my Authenticate method, from my dependent project, like so...
authentication.Authenticate(1,1)
I'd like to be able to not have to include that "authentication." before all calls to methods from this Class Library. Is that possible? If so, what changes do I need to make to my Class Library, or how I'm implementing it in my dependent project?

In C# a function cannot exist without a class. So you always need to define something for it, being a class for a static method or an object for an object method.

The only option to achieve that would be to declare a base class in the Authentication assembly from which you inherit in the dependent projects.
You could expose Authenticate as a protected method (or public works too), and call it without specifying the class name.
public class MyClassInDependentProject : authentication
{
public void DoSomething(int userId, long appId)
{
var success = Authenticate(userId, appId);
…
}
}
That said, you'll quickly find this to be a bad design. It conflates a cross-cutting concern with all sorts of other classes, and those classes are now precluded from inheriting from any other class.
Composition is a core principle of object-oriented programming, and we have the idiom "Favor composition over inheritance." This simply means that we break down complexity into manageable chunks (classes, which become instantiated as objects), and then compose those objects together to handle complex processing. So, you have encapsulated some aspect of authentication in your class, and you provide that to other classes compositionally so they can use it for authentication. Thinking about it as an object with which you can do something helps, conceptually.
As an analogy, think about needing to drill a hole in the top of your desk. You bring a drill (object) into your office (class). At that point, it wouldn't make sense to simply say "On," because "On" could be handled by your fan, your lamp, your PC, etc. (other objects in your class). You need to specify, "Drill On."

If you are making a class library in C# you should learn to use the naming conventions that exists: Design Guidelines for Developing Class Libraries
Here is how you should name namespaces: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/interface
C# is also an object oriented language, hence the need of classes (using Authentication as you should name your class).
It also seems like the data source is hard coded. Your class library users (even if it's just you) might want to configure the data source.
Google about singleton and why it's considered to be an anti pattern today (in most cases).

You are obliged to use Class in order to invoke your method, just
When is static class just NameClass.Method
When is not static, you must create instance, ClassName ob = new ClassName(); ob.Method();

The format of a call like this is class.method, and you really can't escape using the "class" moniker even with the "using" designation. Something has to "host" the function.

I don't think what you are asking for is possible without using the base class method Jay mentioned. If all you want is to simplify the syntax whenever you call Authenticate() however, this silly solution (adding an extra method in each class that needs to do authentication) may be just what you want:
private static void DoAuth(long UserID, long AppID){
authentication.Authenticate(UserID, AppID)
}
If the ID's are always the same within some context, you could also overload it:
private static void DoAuth(){
DoAuth(1,1)
}
Yes, this does mean you have to add more code wherever you want to do the authentication (that's why it's silly! ;) ). It does also however, also reduce this:
authentication.Authenticate(1,1);
...into this:
DoAuth();
I leave the cost / benefit analysis of this up to you..

I know I am some 3 years late but here goes nothing.
To keep your code cleaner and more readable you should create a new namespace for all the re-usable code that you want to have. Then in that namespace have the Authentication Class and Authenticate Function.
To use this you can easily set a using on your namespace and use the function as you are doing like
Authentication.Authenticate()
But to use
Authenticate()
by itself you can always do
using MyNamespace.Authentication;
and in your code use Authenticate Function directly.

Best Practices on Code Duplication c#

I am trying to structure my code in such a way to reduce/avoid code duplication and I have encountered an interesting problem. Every time my code invokes a stored proc, I need to pass few variables that are common to the stored proc: such as username, domain, server_ip and client_ip. These all come from either HttpRequest object or a system.environment object.
Since these are passed to every stored proc, my initial thought was to create a utility class that is a database wrapper and will initialize and pass these every time, so I don't have to do it in my code.
The problem is though that c# class (inside App_Code folder) doesn't see Httprequest object. Of course, I could pass this as an argument to the wrapper, but that would defeat the whole purpose of creating the wrapper. Am I missing something here?
I realize it's not such a huge deal to repeat 4 lines of code each time I call a stored proc, but I would rather eliminate the code duplication at the very early stages.

Set up your data layer to inherit from a base class which contains 4 properties for those values. Make the public constructor require those 4 properties.
Then do something similar in the business layer - base class with those 4 properties in the constructor.
Then the UI does new BusObj( Request["username"], ... ).method()
Within the data layer you can have a method that builds a SQLParameter array with those 4 properties, then each method can add additional parameters to the array.

As a general rule regardless of programming language, if you can squint your eyes and the code looks the same you should make a function/method/message out of it and pass the parameters.
Another thing to look at once you have methods that take a large number of parameters (4 is a good rule of thumb, but it is definatly a case-by-case basis) it is time to make that method take an object as a parameter instead of individual parameters. 99.99999999999999999999% of the time such an object should be immutable (no writeable instance variables).

HttpContext.Current has similar information to what you find in HttpRequest and more importantly is available inside App_Code.

Here's a weird idea you may or may not like: define a 'profile' class and a function that expands the profile into the arguments of functions taking the common arguments.
class P {
readonly string name;
readonly string domain;
public P(string name, string domain) {
this.name = name; this.domain = domain;
}
public void inject(Action<string, string> f) {
f(p.arg1, p.arg2);
}
public T inject<T>(Func<string, string, T> f) {
return f(p.arg1, p.arg2);
}
}
It might work better in VB.net where you have the AddressOf operator. I would be really cautious using this type of thing, because you could easily damage readability and encapsulation.

I would keep it the way you have it now. It's cleaner, easier to extend/modify, and easier to unit test.
As for using HttpContext instead as some others have suggested, I would say that it is a bad idea. Once you start introduce dependencies in your domain on HttpContext, it's very difficult to take it out. What if later on you wanted to use your module without an HttpContext? What about unit testing it?

Try System.Web.HttpContext.Current.Request to get the current request.

You are possibly headed down a slippery slope. The point to DRY is to not repeat business logic in multiple places where a change in requirement creates the need to change code in multiple similar places. You don't necessarily refactor just because 4 lines are the same if those 4 lines are context dependent. You have also broken encapsulation by referencing the httprequest in that you are using a global variable. As a consumer of you class I would have to know the implementation detail that I could only call you from a web application.
That being said, if you take that into account and still want to proceed, here is another option for information like this. Create a custom SecurityPrincipal (Implement IPrincipal) that contains the properties you need and attach it to the thread. Fill them when the user logs in and then you can access it anywhere during the request. Your caller would still need to make sure this was done but at least it isn't platform specific.
Otherwise for the best encapsulation, pass in a class with the properties you need into the constructor for each object that needs to consume those properties.