Currently, am working on architecture of application, I have many entities in my project i.e student teacher university, I was wondering about is it a good practice that all entity must implement interface. This will help me in dependency injection? What is the best practice from architecture point of view.
public interface IMyEntity
{
//an empty interface
}
public class Student:IMyEntity
{
}
public class Teacher:IMyEntity
{
}
//hi I can deal with every object which implement IMyEntity
void Display(IMyEntity entity) //this function can be in some class
{
// if IMyEntity is teacher behave like a teacher
// if IMyEntity is student behave like sutdent
}
I know interface is a contract, but from architecture point of view it is best practice? I know my IMyEntity interface is empty.
Not necessarily. If in this case Student and Teacher have some common functionality then a shared interface would be one approach to take.
public void Display(IUniPerson person)
{
var name = person.Name; // Everyone, student or teacher, has a name
...
}
However, the example you give seems to suggest that this is not the case, and the Display method will attempt to treat the passed in instance of IMyEntity differently depending on it's type. In that case, you may be better with 2 Display methods with different parameters.
public void Display(ITeacher teacher) { // teacher processing }
public void Display(IStudent student) { // student processing }
tl:dr version: implement an interface across multiple classes if it makes sense for those classes to implement related methods and functions, rather than just as a blanket rule.
I think that decoupling 2 or more classes is a good taste in terms of developing and it really helps maintaining the code in a long run.
Consider the follow scenario:
static void Main(string[] args)
{
var objA = new A();
var objB = new B(objA);
}
public class A {}
public class B
{
public B(A obj)
{
//Logic Here
}
}
The problem with this code it's that it's strongly coupled, class B needs class A to be instanced and do it's business.
This is not a problem if you are sure that B is never going to have some drammatic change.
Now if we want to decouple it we can make a first improvement implementing an interface like
static void Main(string[] args)
{
var objA = new A();
var objB = new B(objA);
}
public interface IA()
{
//TODO
}
public class A : IA {}
public class B
{
public B(IA obj)
{
//Logic Here
}
}
It looks quite better what we still have a couplation problem in the Main, so at this point we will have to implement a Dependency Injection with a IOC like Ninject, and our code will be like to something like:
static void Main(string[] args)
{
var objB = new B();
}
public interface IA()
{
//TODO
}
public class A : IA {}
public class B
{
public B(IA obj)
{
//Logic Here
}
}
Yes, that looks good. We have completely removed the couplation problem and it will be quite easy if in the future we just need to take A, delete it and replace it wich something new more cool.
Obviously overkilling it's a bad practice and I belive DI must be used only after carefuly planning to avoid useless implementations.
For example if I have a class C which has some basic operations, and I am sure that it will never change or have some drammatic need to update i can avoid DI.
So do you have to implement interfaces on every model in your project?
Well I don't think each model in your project needs to implements an interface or DI, just think about it and see where it can be useful and where it's just overkilling.
Looking at how .NET solved this, you can see some ambiguity.
For instance for every object has a function where you can ask for a string representation of the object: ToString(), even though for a string representation might not be a meaningful thing for a lot of classes
On the other hand, although it would be a useful function for every object to make a clone of itself they decided not to let every class implement ICloneable.
Whether it is wise for you to have (almost every) objects of your application a common interface depends on what you will do with this interface and the advantage of all objects implementing such an interface versus the burden of being obliged to implement the interface.
For example, if the entities you are talking about are database records, then it is very likely that every class will have some kind of ID. You could consider giving every class an interface with one get property that returns the value of the ID of the record.
public interface IID
{
long ID {get;}
}
The advantage are multifold:
You encourage every designer of database classes to implement the same type of primary key (in this case a long), and the same property name
Advantage: it is easier to spot the ID of a record
Advantage: it is easier to change the type of the ID
Advantage: you know if you have a database record, you know some of the functions the record must have, without really knowing the type of the record.
Even if the designer needs a different type, or different name, he can still create a special function to implement the interface:
public class Person : IID
{
public int ID {get; set;}
IID:ID {get {return this.ID;} }
}
However, I suggest not to force interfaces to object for which it is not natural to have them. This has the advantage that you can't use these strange functions for object that have no real usage for them.
For example, most classes that represent some ordered numerical value have some notion of addition. Not only for integers and real numbers, but also for classes that represent a time span: 4 days and 23 hours + 1 day and 7 ours = 6 days and 6 hours. So for a time span addition is a useful interface
However, for a date, addition is not meaningful: 4th of july + 14 juillet = ?
So: Yes, implement interfaces for items that are natural to them. They force common naming and enable reuse. No, don't implement them for items that do not have a natural meaning for the functions.
Yes do it like this, it is the best practise. This gives you the advantage of polymorphism. You should do it in better way in current context is not good, because Student is not a Teacher. If you want to share common interface you should define it as: IUniversityMember. Here an example for your case which I think will make it clear.
public interface IUniversityMember
{
//... here common fields between `Teacher` and `Student`
string Name{ get; set;}
string Gender { get; set;}
}
//after that
public interface IStudent
{
int GetGPA();
int CreditsToPass {get; private set;}
}
public interface ITeacher
{
int WorkedHours {get; set;}
decimal PayPerHour {get; private set;}
}
public class BiologicalStudent: IUniversityMember, IStudent
{
public int CreditsToPast {get; private set;}
public BiologicalStudent ()
{
CreditsToPast = 5;
}
//stuff
public int GetGPA()
{
return 3;
}
}
public class MathStudent: IUniversityMember, IStudent
{
public int CreditsToPast {get; private set;}
public BiologicalStudent ()
{
CreditsToPast = 9;
}
public int GetGPA()
{
return 2;
}
}
public class BiologicalTeacher: IUniversityMember, ITeacher
{
public int WorkedHours { get; set;}
public decimal PayPerHour {get; private set;}
public MathTeacher()
{
PayPerHour = 8;
}
}
public class MathTeacher: IUniversityMember, ITeacher
{
public int WorkedHours { get; set;}
public decimal PayPerHour {get; private set;}
public MathTeacher()
{
PayPerHour = 10;
}
}
//Now if you have a university class
public class OxfordUniversity:IUniversity //can inherit interface too
{
public int MinGAPForSchollarship {get; private set;}
public OxfordUniversity()
{
MinGAPForSchollarship = 3;
}
public decimal PaySallary(ITeacher teacher)
{
return teacher.WorkedHours*teacher.PayPerHour;
}
public bool CheckForSchollarship(IStudent student)
{
int gpa = student.GetGPA();
//do some checks
if(gpa >= MinGAPForSchollarship)
return true;
return false;
}
}
Related
I am not sure if this even makes sense hence asking it widely.
Is it possible for enforce that a set of classes always implements a function with a given name. The method in each class might have different signature - but should have the same name. Some like below:
public class ClassOne {
public int GetSomething (int a, int b, out int c) { }
}
public class ClassTwo {
public int GetSomething ( int a, out string b) {}
}
I want anyone who writes ClassThree or ClassFour as part of this library to implement the GetSomething method. Is there a C# construct that allows one to enforce this?
Not looking at design review of this - just want to know if its possible at all without manually enforcing via code reviews.
You can't do that with out-of-the-box C#. C# has abstract classes and interfaces, but they require a specific signature for a method, not just a name.
You could get this working by creating code analyzers in Roslyn, where you check your code if it has the required method.
However, I don't think you should all this. I think you are making a design flaw here in requiring a method with a specific name, without forcing the arguments of it.
You could always implement a method similar to the Main method found in every C# application. It uses a string[] as parameter where you can put a number of variables in. In your case I would opt for an object[]. However, this design has its flaws too obviously.
What is the purpose of a class with method of unknown arguments. It is just illogical in terms of OOP. How are you going to call this method? If arguments are homogeneous then you could just do something like:
public interface IBaseInterface
{
public int GetSomething(Dictionary<string, object> args); // keys matter
}
or
public interface IBaseInterface
{
public int GetSomething(params object[] args); // order matters
}
In some cases Func<> / Action<> high-order functions may be useful.
If you provide a usage case, we would be able to make a more precise answer.
Show how you are going to call such method and I will try to show how to make it better.
Answering your question only from technical side, you could do the following:
public abstract class BaseClass
{
protected BaseClass()
{
if (this.GetType().GetMethod("GetSomething") == null)
throw new InvalidOperationException("BaseClass subclasses should implement 'GetSomething' method");
}
}
public class ClassOne : BaseClass {
public int GetSomething (int a, int b, out int c) { }
}
public class ClassTwo : BaseClass {
public int GetSomething (int a, out string b) {}
}
It will not guarantee this behavior at design-time, but will ensure that such methods exists at run-time.
Add an interface with the method you want.
Set classes inherit from this interace
interface ISampleInterface
{
void SampleMethod();
}
class ImplementationClass1 : ISampleInterface
{
// Explicit interface member implementation:
void ISampleInterface.SampleMethod()
{
// Method implementation.
}
}
How about encapsulating parameters in a "Criteria" object?
public interface IGettable
{
int GetSomething (Criteria crit);
}
public class Criteria
{
public CriteriaType type {get; set;};
public int a {get; set;};
public int b {get; set;};
...
public static Criteria ClassOneCriteria(int a, int b)
{
return new Criteria
{
type = CriteriaType.ClassOneCriteria,
a = a,
b = b
}
}
...
}
public enum CriteriaType
{
ClassOneCriteria,
ClassTwoCriteria
}
public class ClassOne : IGettable
{
public int GetSomething (Criteria crit)
{
if (crit.type != CriteriaType.ClassOneCriteria)
throw new Exception("Invalid criteria type for Class One");
...
}
}
I used to be able to do this:
public class Something
{
public class SomethingElse
{
public static class ThisThing
{
public static string aoidj {get;set;}
}
}
}
But it no longer works.
My desired result (and what I've always been able to do) is:
Something.SomethingElse somethingElse = new Something.SomethingElse();
somethingElse.ThisThing.aoidj = "yay";
Console.WriteLine(somethingElse.ThisThing.aoidj);
But that no longer works. Instead of being able to access ThisThing from somethingElse, it's now appearing in SomethingElse.!
Has the C# language changed or something? The behaviour is definitely different and I don't know when it changed.
You need to do this:
Something.SomethingElse.ThisThing.aoidj = "yay";
Console.WriteLine(Something.SomethingElse.ThisThing.aoidj);
Or otherwise change your code to this:
public class Something
{
public class SomethingElse
{
public Whatever ThisThing = new Whatever();
public class Whatever
{
public string aoidj {get;set;}
}
}
}
And then you could do this (your desired result):
Something.SomethingElse somethingElse = new Something.SomethingElse();
somethingElse.ThisThing.aoidj = "yay";
Console.WriteLine(somethingElse.ThisThing.aoidj);
It has to appear in the SomethingElse., otherwise, how can you acces it, it is a Nested Type!
C# has not changed in this way. Nested Types have always been accessible through their parent types.
See my answer here: Cannot access nested classes or members of base class.
Besides, there is no point in having static classes as a Nested Type, since static classes are more commonly used as managers or providers, so they are mainly used elsewhere in your system.
Aside, if you want to access your static class members, you have to type in its name and access it once and for all.
Something.SomethingElse.ThisThing.aoidj
But I can't do that. It would be bad. I need to do it from somethingElse. Not SomethingElse.
Than make it a property rather than a class.
public class Something {
public class SomethingElse {
public OrEventSomethingElse ThisThing { get; set; }
}
}
public class OrEventSomethingElse {
public string aoidj { get; set; }
}
This way, you shall not be able to access it through your Nested Type SomethingElse, but rather through only an instance.
Some resources to help you understand OOP.
Object-Oriented Programming (C# and Visual Basic)
C# Tutorial - An Object Oriented Approach to Programming
Introduction to C# classes
C#.Net Tutorial 17-1 - Classes and Object-Oriented Programming (Part 1)
.NET Tutorial : Object Oriented Programming Using C# For Beginners - Part 1 - Introduction
Beginning C# Object-Oriented Programming
Object Oriented Programming using C# (DOWNLOAD FREE)
** I need it to be a class though, because there is more stuff to go inside of ThisThing**
Make it a class outside of SomethingElse so that you may access it as a simple instance member/property.
public class ThisThing {
public string Stuff { get; set; }
public int SomeMoreStuff { get; set; }
public DateTime EvenMoreStuff { get; set; }
// ...
public string ThisClassIsGettingHuge {
get {
return "Time to refactor because big classes tend to break SRP";
}
}
}
public class Something {
public class SomethingElse {
public ThisThing ThisThingAsAProperty { get; set; }
}
}
It is then, and only then that you shall only be able to access your instance.
var somethingElse = new Something.SomethingElse;
Console.WriteLine(somethingElse.ThisThingAsAProperty.ThisClassIsGettingHuge);
I have developed information and process for years, and I rarely use Nested Types. They generally cause more damage than they help.
Nothing is changed, but your code is wrong. And luckily I found answer too.
class Something
{
public class SomethingElse
{
public SomethingElse()
{
}
public static class sm
{
public static void set()
{
}
}
}
}
Use the class in this manner-
Something.SomethingElse.sm.set();
I have a question and am getting a little stumped on this one. It's probably easy but I'm just missing it.
If I have a class what contains necessary structures and the structures can inherit. I need a generic method what that an be passed to and then used. For example, let's say I have a structure Test, Test-A which inherits from Test. Then I have a MyTest and MyTest-B both which inherit from Test-A.
How can I create a method using T so that I can supply both MyTest and MyTest-B and I can use either of them in the method?
So:
public class Test
{
public int Hello {get; set; }
}
pubilc class Test-A : Test
{
public string Name { get; set; }
}
public class MyTest : Test-A
{
public string Last { get; set; }
}
public class MYTest-B : Test-A
{
public int Age {get; set; }
}
I need a method like:
private void MyList<T>(List<T> TestList) where T : **{not sure what this would be}**
{
TestList.Age = 10;
**OR**
TestList.Name = "Jane";
}
How or what am I missing (or not understanding) to be able to do that?
Any assistance would be greatly appreciated.
There is no constraint you could use which would match both of those conditions. The only way to handle this would be to use two, overloaded methods, as there is no shared contract.
Generic constraints only work if there is a base class or interface shared which all types implement, and use the same contract (ie: both have Name and Age properties).
How can I create a method using T so that I can supply both MyTest and
MyTest-B and I can use either of them in the method?
**TestList.Age = 10;**
...
How would this work if you passed in an object of type MyTest, given that MyTest doesn't have an Age property?
Consider the following class and interfaces:
public interface A { string Property { get; set; } }
public interface B { string Property { get; set; } }
public interface C : A, B { }
public class MyClass : C
{
public string Property { get; set; }
}
Looks simple, right? Now consider the following program:
static void Main(string[] args)
{
MyClass myClass = new MyClass();
myClass.Property = "Test";
A aTest = myClass;
B bTest = myClass;
C cTest = myClass;
aTest.Property = "aTest";
System.Console.WriteLine(aTest.Property);
bTest.Property = "bTest";
System.Console.WriteLine(bTest.Property);
cTest.Property = "cTest";
System.Console.WriteLine(cTest.Property);
System.Console.ReadKey();
}
Looks okay, but it will not compile. It gives me an Ambiguity exception:
Why isn't C# able to figure this out? Is what I'm doing crazy from an architectural point of view? I'm trying to understand the why (I know it can be solved with casting).
EDIT
The problems arose when I introduced interface C. When I use MyClass : A, B I've got no problems at all.
FINAL
Just finised a blog about the subject: Interface Ambiguity and Implicit Implementation.
In short because it's ambiguous indeed.
Now more detailed story. As you've already seen there is explicit interface implementation, so you can have two different implementations for A.Property and B.Property and when you have only C there is no way you can tell if implementations are the same or not. Since C# "philosophy" is not to guess what you meant, but make you state it more clear when necessary, compiler does not choose either A.Property or B.Property, but reports an error.
You need explicit interface implementation:
public interface A { string Property { get; set; } }
public interface B { string Property { get; set; } }
public interface C : A, B { }
public class MyClass : C
{
string B.Property { get; set; }
string A.Property { get; set; }
}
When it comes time to call them you are going to have to do:
MyClass c = new MyClass();
Console.WriteLine("Property A is ": ((A)c).Property);
Why don't you do:
public class MyClass : C
{
string B.Property { get; set; }
string A.Property { get; set; }
string B { get { return B.Property; } set { B.Property=value; } }
string A { get { return A.Property; } set { A.Property=value; } }
}
And it should be noted this is bad design, if you are going to expose an interface C, make sure you find a better way to expose A/B.Property.
What's to figure out? cTest is of type "C", and it inherits "Property" from two different classes; the compiler doesn't know which one you want. This sort of behavior is inherited from C++; it's the classic example of "why multiple inheritance is a Pandora's box."
Other object-oriented languages -- Java is a notable example -- avoid this problem by definition : like-named/like-signatured methods are fused in a common descendent.
When you inherit from a single interface the compiler can determine exactly which method you are interested in implementing when you add the new method.
However when multiple interfaces have the same method, the underlying (and correct) assumption is that each interface expects a DIFFERENT implementation for the method, due to the fact that those methods or properties are defined on different interfaces.
So the compiler tells you that these different interfaces require an explicit implementation for each of these properties.
The fact that two interfaces share the same NAME for a property or method is arbitrary - there is no reason to assume that they share anything OTHER then the name, so the compiler protects you from making the mistake of implicitly treating them in the same way.
It is not simple, and it doesn't look simple either. In case of a name collision between two interfaces, .NET needs to ask you which interface are you trying to implement. Its way to ask you this is via the ambiguity error.
If you didn't have this kind of errors, you would end up implementing interfaces by chance.
you need to explicity implement both properties from each interface:
public class MyClass : C
{
string A.Property { get; set; }
string B.Property { get; set; }
}
Because what you are doing is not right. A and B are clashing and have the same name for the property... you need to use Explicit implementation of interface.
Reference here.
There are a lot of answers, and all of them are right, as explicit interface implementation is the answer to your problem.
I'll try to clarify the motivation behind this design with a somewhat convoluted example:
Let's say I have an interface for people that run (with possible implementations like LongDistanceRunner, Jogger, MarathonMan, etc)
public interface IRunner
{
void Run();
}
and an interface for devices that can be turned on and ran (with possible implementations BathTub, Application, Dishwasher, etc)
public interface IRunnable
{
void Run();
}
Now I want to create and interface for a IMusicallJogger (implementations like JoggerWithIpod,BoomBoxJogger, etc)
public interface IMusicalJogger : IRunner, IRunnable {}
public class BoomBoxJogger : IMusicalJogger
{
// code here
}
BoomBoxJogger bbJogger = new BoomBoxJogger();
Now, when I say bbJogger.Run() what should my object do? Should it start running across the park, or should it turn on the boombox, or both, or something else entirely? If I implement both the class and the callsite, it might be obvious that I want my joggers to do both, but what if I control just the callsite? And what if there are other implementations of the interface that do something else? And what if my jogger starts running across the park, when it's used in a context where it is considered like a device (through casting).
That's where explicit interface implementation comes into play.
I have to define my class like this:
public class BoomBoxJogger : IMusicalJogger
{
void IRunner.Run() //implementation of the runner aspect
{
Console.WriteLine("Running through the park");
}
void IRunnable.Run() //implementation of the runnable aspect
{
Console.WriteLine("Blasting out Megadeth on my boombox");
}
public void Run() //a new method defined in the class itself
{
Console.WriteLine("Running while listening to music");
}
}
and then, when I call, I have to specify what aspect of my jogger I want to use:
BoomBoxJogger bbJogger = new BoomBoxJogger();
((IRunner).bbJogger).Run(); // start running
((IRunnable).bbJogger).Run(); // blast the boombox
//and of course you can now do
bbJogger.Run //running while listening
((IMusicalJogger)jogger).Run(); //compiler error here, as there is no way to resolve this.
Hope I helped clarify the concept.
I'm creating a series of Interfaces/Abstract classes that contain basic properties and I would like to have computed Properties and multiple inheritance.
public abstract class /interface Modifiable
{
public DateTime ModifiedDate {get; set;}
public boo ModifiedToday
{
get { return DateTime.Now.AddDays(-1).CompareTo(ModifiedDate) >= 0; }
}
public bool ModifiedInLastWeek
{
get { return DateTime.Now.AddDays(-7).CompareTo(ModifiedDate) >= 0; }
}
}
public abstract class /interface Deletable
{
public DateTime DeletionDate {get; set;}
public bool Deleted
{
get { return DeletionDate != default(DateTime) }
}
}
Then I have a class that inherits from these two Interfaces/Abstract classes.
public class Something : Modifiable, Deletable
{
//
}
But a class cannot inherit from two abstract classes. So I then need to use interfaces, but with interfaces I cannot have method bodies. I then have to define the same exact functions across multiple classes to implement these simple bool properties using interfaces.
I also don't want to have Modifiable inherit from Deletable because I might want something to be Modifiable but not Deletable. These specific classes aren't my problem, I'm simply using them to illustrate my problem.
Is there a design pattern that mimics an abstract class by allowing function bodies, but allows multiple inheritors like an interface?
It's not multiple inheritance, but something that comes to mind is Extension methods.
public interface IModifiable
{
DateTime ModifiedDate {get; set;}
}
public static class ModifiableExtensions
{
public bool ModifiedToday(this IModifiable m)
{
return DateTime.Now.AddDays(-1).CompareTo(m.ModifiedDate) >= 0;
}
public bool ModifiedInLastWeek(this IModifiable m)
{
return DateTime.Now.AddDays(-7).CompareTo(m.ModifiedDate) >= 0;
}
}
That gives the "feel" of helper methods that are baked into the type, but they happen to be declared elsewhere. Take this class:
public class MyModifiable :IModifiable
{
public ModifiedDate {get; set;}
}
And you can do this:
MyModifiable m = new MyModifiable;
m.ModifiedDate = DateTime.Now;
bool isToday = m.ModifiedToday();
No. C# doesn't have a mechanism to implement multiple inheritance this way.
When it comes to interfaces, this is possible because when you define multiple interfaces you also need to implement them all.
Consider a different design, possibly using composition in order to reuse the classes you want to use for multiple inheritance.
I forget the design pattern name, but there's a pattern to implement multiple interfaces by wrapping the method/property calls around interface implementations of members who are of that same interface:
interface IDrivable {
void Drive();
}
interface IFlyable {
void Fly();
}
class Car : IDrivable {
public void Drive() { /* Implementation */ }
}
class Plane : IFlyable {
public void Fly() { /* Implementation */ }
}
class MyClass : IDrivable, IFlyable {
private IDrivable _car = new Car();
private IFlyable _plane = new Plane();
public void Drive() { _car.Drive(); }
public void Fly() { _plane.Fly(); }
}
Yes there are methods, several, actually. A few thoughts:
Use an empty interface for Deletable, Modifiable etc (called marker interfaces), then create extension methods for them. This is not as expandable as multiple inheritance, but it gets a long way.
Use genericity, possibly with the same tagging interfaces to create dependencies. This way you can have a base class with all methods for both Modifiable and Deletable, including abstract methods and override implementation in derived classes
Use aspect oriented programming to get to the same results
Almost the same, but do it yourself with Castle or similar library, possibly with the help of attributes.
Obviously, none of the above has all the advantages of multiple inheritance. If you want multiple inheritance in .NET, you can use C++.NET or Eiffel.NET.
Sorry, multiple inheritance is not possible in C# and that's a bummer for you. Your choices are:
Either to chain your base class inheritance a la MyClass : MyBaseClass : EvenBasierClass
Or inherit from multiple interfaces. And implement all methods of all interfaces.
It's not pretty, but you can also control property accessibility or return values inside your classes by checking the instance type.
Modifiable & Deletable IMO should be interfaces, not base classes. A base class defines what a type is, whereas a interface describes what a type does.
As far as implementing the code, you can always use extension methods:
public interface IModifiable
{
public DateTime ModifiedDate {get; set;}
}
public interface IDeletable
{
public DateTime DeletionDate {get; set;}
}
public static class SomeExtentions
{
public static bool IsModifiedToday(this IModifiable modifiable)
{
return DateTime.Now.AddDays(-1).CompareTo(modifiable.ModifiedDate) >= 0;
}
public static bool IsModifiedInLastWeek(this IModifiable modifiable)
{
return DateTime.Now.AddDays(-7).CompareTo(modifiable.ModifiedDate) >= 0;
}
public static bool IsDeleted(this IDeletable deletable)
{
return deletable.DeletionDate != default(DateTime);
}
}
I would probably use delegation to achieve this. Create Modifiable and Deletable as interfaces, then create implementations of those. Give the Something class instances of these implementations. Here's an example for Deletable:
public interface Deletable
{
DateTime DeletionDate{get;set;}
bool Deleted{get;}
}
public class DeletableImpl : Deletable
{
public DateTime DeletionDate{get; set;}
public bool Deleted{get {return DeletionDate != default(DateTime);}}
}
// Do the same thing with Modifiable and ModifiableImpl
public class Something : Deletable, Modifiable
{
private Deletable _deletable = new DeletableImpl();
private Modifiable _modifiable = new ModifiableImpl();
public DateTime DeletionDate
{
get{return _deletable.DeletionDate;}
set{_deletable.DeletionDate = value;}
}
public bool Deleted{get{return _deletable.Deleted;}}
public DateTime ModifiedDate {
// and so on as above
}