We Keep Coding

Calling abstract method in constructor of abstract class

As CA2214 states, one should not call an overridable method in a constructor. However, I've come across a case where I can't see another way to do what I'm trying to achieve and I can't see potential problems arising from breaking this rule:
I have an abstract base class for configurations. In this class, there is logic for how to fetch the values.
My applications have configs that can be made up of certain components. So my SpecificConfig would inherit from ConfigBase and be made up of ConfigComponentA and ConfigComponentB:
public abstract class ConfigBase
{
protected ConfigBase()
{
this.InitializeMembers();
this.SetConfigValues();
}
protected abstract void InitializeMembers();
private void SetConfigValues() {
// Set the config values
// Depends on members initialized in InitializeMembers
}
}
public class ConfigComponentA
{
public string FieldA1;
public string FieldA2;
}
public class ConfigComponentB
{
public string FieldB1;
public string FieldB2;
}
public sealed class SpecificConfig : ConfigBase
public SpecificConfig() : base() {}
public ConfigComponentA ConfigA;
public ConfigComponentB ConfigB;
protected override void InitializeMembers()
{
this.ConfigA = new ConfigComponentA();
this.ConfigB = new ConfigComponentB();
}
}
The main point is that the configs could be made up of different components, and I want to avoid code duplication by having the logic for fetching and setting the config values in SetConfigValues() in the base class.
I have a feeling there may be a better way of going about this altogether, but I don't really see any unexpected behaviour that could come of this. Is there a better approach?

Is it a good practice to cast from an interface to some concrete class when needed?

I'am developing a small system and i developed the classic generic repository. For now, i have the following architecture for my DAL.
public interface IRepositorio<T> where T : class
{
T Get(long id);
long Insert(T obj);
bool Update(T obj);
bool Delete(T obj);
}
public abstract class Repositorio<T> : IRepositorio<T> where T : class
{
public IDbConnection Connection
{
get
{
return new SqlConnection(ConfigurationManager.ConnectionStrings["DBFila"].ConnectionString);
}
}
public T Get(long id)
{
//...
}
public long Insert(T obj)
{
//...
}
public bool Update(T obj)
{
//...
}
public bool Delete(T obj)
{
//...
}
}
My concrete repository looks like this:
public class FilaRepositorio : Repositorio<FilaRepositorio>
{
public FilaRepositorio()
{
}
public void SomeCustomMethod()
{
// Some custom method
}
}
I am also using Simple Injector to follow the IoC and DI patterns, for this reason, when i try to call "SomeCustomMethod()" i dont have access to it (obviously). Look:
public class Processador
{
private IRepositorio<FilaModel> _repoFila;
public Processador(IRepositorio<FilaModel> repoFila)
{
_repoFila = repoFila;
}
public void Processar()
{
_repoFila.SomeCustomMethod(); // <-- wrong
((FilaRepositorio)_repoFila).SomeCustomMethod();// <-- works
}
}
Given this i have some questions:
Is a good or acceptable practice to make that cast (FilaRepositorio)?
If its not a good practice, how to write good code for this case?

There are a few options available. The main problem with making the cast is that it is an implementation concern.
What would happen if the injected object was not a FilaRepositorio?
By making the cast you are tightly coupling the class to an implementation concern that is not guaranteed to be the inject dependency. Thus the constructor is not being entirely truthful about what it needs to perform its function.
This demonstrates the need to practice Explicit Dependencies Principle
The Explicit Dependencies Principle states:
Methods and classes should explicitly require (typically through
method parameters or constructor parameters) any collaborating objects
they need in order to function correctly.
One way to avoid it would be to make a derived interface that explicitly exposes the desired functionality of its dependents.
public interface IFilaRepositorio : IRepositorio<FilaModel> {
void SomeCustomMethod();
}
public class FilaRepositorio : Repositorio<FilaModel>, IFilaRepositorio {
public void SomeCustomMethod() {
//...other code removed for brevity.
}
}
and have the Processador depend on that more targeted abstraction.
Now there is no need for the cast at all and the class explicitly expresses what it needs.
public class Processador {
private readonly IFilaRepositorio _repoFila;
public Processador(IFilaRepositorio repoFila) {
_repoFila = repoFila;
}
public void Processar() {
_repoFila.SomeCustomMethod(); // <-- works
}
}

If you need to access a specific method from any part of your application, then that specific method must be part of your abstraction, or else there is no guarantee that you may use it when changing the concrete class.
I do not believe that your use of casting is a good idea at all, what is usually done in this case is to create a specific interface which defines any other method you could need to use:
public interface IFilaRepositorio : IRepositorio<Fila>
{
void SomeCustomMethod();
}
And than use and declare that specific interface in any part of your code where you believe you need to use it:
public class Processador
{
private IFilaRepositorio _repoFila;
public Processador(IFilaRepositorio repoFila)
{
_repoFila = repoFila;
}
public void Processar()
{
_repoFila.SomeCustomMethod();
}
}

Looking for approach to design two classes and one interface

public interface ISaveData
{
void DeleteFile(); // this is common method
//void ChangeBucket(); I don't need this method in GoogleCloudSaveFile. Should I remove this from here
// void AssignPermission(); // I don't need of this method in AzureSaveData. Should I remove this from here?
}
public class AzureSaveData : ISaveData
{
void ChangeBucket()
{...}
void DeleteFile()
{...}
}
public class GoogleCloudSaveFile() : ISaveData
{
void AssignPermission()
{...}
void DeleteFile()
{...}
}
I want to expose Interface to my presentation layer.
How can I design above three classes (2 classes and 1 interface) to expose all methods to my presentation layer.
All methods means:
Delete()
ChangeBucket()
AssignPermission()
Please ask me if you need more explanation
Presentation layer could be like
void Main()
{
ISaveData saveFiles = new GoogleCloudSaveFile(); // This is just example. I will inject this via Dependency Injection framework
saveFiles.Delete();
}
ChangeBucket() and AssignPermission() are just example methods. I wanted to say, our child classes could have different methods like these two.
One solution is I can define these two methods in interface and can leave method body empty of one method but I don't think it will be good approach

As far as I can think based on the information provided by you without getting into the nitty-gritty of what method would lie in which interface, this is the easiest I can think of:
public interface ISaveData
{
void DeleteFile(); // this is common method
}
public interface IPermission
{
void AssignPermission();
}
public interface IBucketOperation //or something else
{
void ChangeBucket();
}
public class AzureSaveData : ISaveData, IBucketOperation
{
public void ChangeBucket()
{
Console.WriteLine("AzureSaveData ChangeBucket");
}
public void DeleteFile()
{
Console.WriteLine("AzureSaveData DeleteFile");
}
}
public class GoogleCloudSaveFile : ISaveData, IPermission
{
public void AssignPermission()
{
Console.WriteLine("GoogleCloudSaveFile AssignPermission");
}
public void DeleteFile()
{
Console.WriteLine("GoogleCloudSaveFile DeleteFile");
}
}
You can use these as follows:
ISaveData x = new GoogleCloudSaveFile();
x.DeleteFile();
(x as IPermission).AssignPermission();
You can also check if the object you create is of the type before typecasting:
if(x is IPermission)
(x as IPermission).AssignPermission();
I am not sure if you are willing to take the following approach but I think this would be better:
public interface IGoogleCloudSaveFile : ISaveData, IPermission { }
public interface IAzureSaveData : ISaveData, IBucketOperation { }
It would be difficult for you to use a common interface and expect it to have different methods available for different type of objects based on the implementation unless you want to ignore design principals and put everything into one interface. In that case, just put everything in one interface, and while implementing it in the classes, just do a
throw new NotImplementedException();

Pass-through constructors from its base class

An external framework has the following classes:
public class Boatmaker
{
}
public class Wood
{
}
public class Axe
{
}
public class Lake
{
}
public class Boat
{
public Boat(Wood wood, Axe axe) {
}
public Boat (Boatmaker maker) {
}
public Boat (Lake lake) {}
}
I need to do a lot of subclassing of Boat. For each of my subclasses, I have to assume that the external framework may want to instantiate it via any of the above constructors. So my subclasses get pass-through constructors. Notice how they never go away:
public class SmallBoat: Boat
{
public void DoSmallBoatStuff() {
// some code here
}
private void Initialize() {
this.DoSmallBoatStuff();
}
public SmallBoat(Wood wood, Axe axe): base(wood, axe) {
this.Initialize();
}
public SmallBoat (Boatmaker maker): base(maker) {
this.Initialize();
}
public SmallBoat (Lake lake): base(lake) {
this.Initialize();
}
}
public class Canoe: SmallBoat
{
public void DoCanoeStuff() {
// some code here
}
private void Initialize() {
this.DoCanoeStuff();
}
public Canoe(Wood wood, Axe axe): base(wood, axe) {
this.Initialize();
}
public Canoe (Boatmaker maker): base(maker) {
this.Initialize();
}
public Canoe(Lake lake): base(lake) {
this.Initialize();
}
}
I am wondering if there is a way to simplify the appearance of the code. The only difference between the way the constructors are written in SmallBoat and Canoe is the word SmallBoat or Canoe. Everything else is the same.
So if there were a way to write a constructor without actually using the name of the class in the constructor, it would help a lot. I could use direct copy and paste without a .tt file (which is not really viable for me -- most of my work is not done in Visual Studio). Is there a way to do that?

No. There is not. You have to specify which constructors of the base class you want to make available from the current class. There is no way to write the constructor without mentioning the real class name.
It might be a simplification you are showing, but if Initialize is the only method called, you might want to move that call to the base class calling a protected Initialize method you can override from the implementing classes. (You have to take in consideration the order of calling that method and instantiating properties/fields. You can run into trouble there, so it might not be viable in your situation)

1. Automation of code typing
There is code snippet : ctor that helps create "only" default constructor.
To use it type ctor an tabulation twice.
The original code snippet can be copied to create your own.
In Visual Studio, go in Tools menu/Code snippet manager.
You can see here the directories of the snippet files.
You can copy a snippet ( ctor.snippet for instance ) to "My Code Snippets", rename it and edit.
2. Design of the boat hierarchy
The boat hierarchy can also be designed so there is only a default constructor in the base class, and you have public properties or public method(s) in the base class to provide Lake, Axe, BoatMaker, ...

If you can change the design, I highly recommend separate object instantiation from the object itself. This way, the Factory Method combining with Template Method design pattern comes very helpful:
public abstract class BoatFactory
{ protected abstract void Initialize();
protected Wood Wood;
protected Axe Axe
protected Boatmaker Boatmaker ;
public Boat MakeBoat(Wood wood, Axe axe)
{
this.Wood = wood;
this.Axe = axe;
Initialize();
}
public Boat MakeBoat(Boatmaker maker)
{
this.Boatmaker = Boatmaker ;
Initialize();
}
public Boat MakeBoat(Lake lake)
{
this.Lake = lake;
Initialize();
}
}
public class SmallBoatFactory : BoatFactory
{
protected override void Initialize()
{
// do customized init operations here
}
}

Intercepting object with deep inheritance tree

I'm having object structure with depth of inheritance of 3. Object is implementing single particular interface. The depth of inheritance for interface is 4. My final object is being constructed via unity IoC. I need to intercept every public method in this object (means no matter in which of interfaces it is defined), though whatever interceptor type I use (InterfaceInterceptor/TransparentProxyInterceptor/VirtualMethodInterceptor ) it always intercepts only methods defined in the final class of inheritance tree. Please see the illustration of object structure below:
public interface IDevice {
void Connect();
}
public interface ISerialDevice {
void WriteCommand();
}
public interface IProtocolSerialDevice {
void ExecuteProtocolCommand();
}
[MyHandler]
public interface ICustomSerialDevice {
void ExecuteMyCommand();
}
public abstract class AbstractSerialDevice {
public virtual void WriteCommand() {
//omitted
}
}
public abstract class AbstractProtocolSerialDevice : AbstractSerialDevice {
public virtual void ExecuteProtocolCommand() {
//omitted
}
}
public class CustomSerialDevice : AbstractProtocolSerialDevice, ICustomSerialDevice {
public virtual void ExecuteMyCommand() {
//omitted
}
}
public class MyHandlerAttribute : HandlerAttribute {
public override ICallHandler CreateHandler(IUnityContainer container) {
//omitted
}
}
Object is registered into unity container as follows:
container.RegisterType<ICustomSerialDevice, CustomSerialDevice>(
new ContainerControlledLifetimeManager(), new InjectionMethod(postConstructMethodName));
container.Configure<Interception>()
.SetInterceptorFor<ICustomSerialDevice>(new TransparentProxyInterceptor());
Unfortunately my interceptor always gets invoked only for ExecuteMyCommand() method. Is it possible to do such interception I'm striving for via unity container? I'm slowly thinking of trying to achieve it via Spring.NET AOP library.

First off, I would recommend you use the InterfaceInterceptor wherever possible. It will give you the best flexibility and performance. Fall back to using VirtualMethodInterceptor when you can't use InterfaceInterceptor. And as a last resort, use TransparentProxyInterceptor. See here.
For interfaces, the handler attribute only applies to the methods defined on that interface (not inherited). So you can achieve what you are after by decorating all 4 interfaces with the [MyHandler] attribute.
For concrete classes, the handler attribute applies to all inherited types. So you can achieve what you are after by decorating the top AbstractSerialDevice with the [MyHandler] attribute. You could also decorate individual methods on either the interface or the concrete class level.
Also, in my opinion, decorating a concrete method is a bit more discoverable than decorating a type. Though it is a bit more verbose.
Option 1
// No MyHandler on any of the concrete classes
[MyHandler]
public interface IDevice
{ /* omitted */ }
[MyHandler]
public interface ISerialDevice : IDevice
{ /* omitted */ }
[MyHandler]
public interface IProtocolSerialDevice : ISerialDevice
{ /* omitted */ }
[MyHandler]
public interface ICustomSerialDevice : IProtocolSerialDevice
{ /* omitted */ }
Option 2
// No MyHandler on any of the interfaces nor derived classes
[MyHandler]
public abstract class AbstractSerialDevice : ISerialDevice
{ /* omitted */ }
Option 3
// No MyHandler on any of the interfaces nor abstract classes
public class CustomSerialDevice : AbstractProtocolSerialDevice, ICustomSerialDevice
{
[MyHandler]
public override void Connect()
{ base.Connect(); }
[MyHandler]
public override void WriteCommand()
{ base.WriteCommand(); }
[MyHandler]
public override void ExecuteProtocolCommand()
{ base.ExecuteProtocolCommand(); }
[MyHandler]
public void ExecuteMyCommand()
{ /*omitted*/ }
}
Any of those options work for you?