I have a class called GatewayClaims and a class called GatewayItems. And yes, the project I'm working on is a gateway.
I have several classes derived from GatewayItems: GatewayUser, GatewayCompany, GatewayRole and a few more. Each of these derived classes will hold claims. (Actually, just values. Simplified here.) And these claims gets passed forward to another service as a JWT token. This should work just fine.
But the problem is this:
public class GatewayClaim
{
public GatewayItem Item { get; set; } = new();
}
public abstract class GatewayItem
{
public List<GatewayClaim> Claims { get; set; } = new();
}
The "abstract" is part of the challenge here...
The problem is that I want separate tables for each item/claim pair so I have UserItems/UserClaims, CompanyItems/CompanyClaims, etc. So, preferably I would make the Claims type a generic class GatewayClaim<T> where T:GatewayItem, new() but then List<GatewayClaim> becomes invalid. And I don't weant to create a lot of derived classes just to support the various configurations that would be possible. I could use List<GatewayClaimValue<GatewayItem>> in GatewayItem which seems to work. But then I need to configure the DBSet and IEntityTypeConfiguration class for the various Claims tables and things become really messy by then.
So, I'm looking for an elegant solution to keep the amount of code to a minimum. And keep it readable!
To be clear: GatewayItem is NOT directly mapped to an entity, but a public class GatewayItemConfiguration<T> : IEntityTypeConfiguration<T> where T : GatewayItem is used to allow inheritance of basic configuration for any derived classes. This has an public virtual void Configure(EntityTypeBuilder<T> builder) method that gets overridden in the child configuration classes. Again, I'm trying to stay DRY in my code.
So the GatewayUser class uses a public class GatewayUserConfiguration : GatewayItemConfiguration<GatewayUser> {} class to configure the GatewayUser entity. I do the same way for a GatewayUserClaim which is derived from GatewayClaim at this moment. But the derived Claim types don't differ from their parent class, except the Items list is of a different type. Which is why I want to use GatewayClient<T> instead of GatewayClient.
I have several classes derived from GatewayItems: GatewayUser, GatewayCompany, GatewayRole
These are not closely-enough related to use inheritance in the database. If you want to have a common base class in code, simply don't map GatewayItem to an EF entity.
I want separate tables for each item/claim pair so I have UserItems/UserClaims
Great. Just introduce a UserClaim type, again perhaps inheriting from an unmapped Claim type, and it will map to a separate UserClaim table.
I'm looking for advice on this problem and whether service locator and class naming conventions are an ok solution (I tend to avoid these anti-patterns), and potential performance ramifications.
An app has a collection of objects implementing the same interface, distinguished by name. For example:
public interface IDog {
void Bark();
}
public class Pug: IDog {
public void Bark() {
// Pug bark implementation
}
}
public class Beagle: IDog {
public void Bark() {
// Beagle bark implementation
}
}
In the code, when you need an IDog, you only know a string name that is passed to you, for example "Pug" or "Beagle". In this case the string may contain special characters (example: <breed:pug />)
There are a few proposed solutions that have come about:
Using reflection, find the implementation needed where the string name == implementation name.
Add an addribute to each class, use reflection where string name == attribute property. Ex [DogBreed("Pug")]
Add a Breed property to the IDog interface. Inject a IList into a factory class, and have it retrieve the matching dog. Ex.
Private IList _dogs;
Public DogFactory(IList<IDog> dogs) {
_dogs = dogs;
}
Public IDog GetDog(string dogBreed) {
return _dogs.First(x => x.Breed == dogBreed);
}
1 and 2 use service locator. 1 uses an implied naming convention that you will only know by seeing the reflection code. 3 the concern is that all of the objects will be built in memory even though you only need a single implementation.
I personally have leaned towards #3 in the past. Object creation should be cheap. However, this is a legacy web app and objects down the chain may have heavy initialization cost. This application uses Unity for IoC.
Option 1.
This option sounds like the Partial Type Name Role Hint idiom. If you inject the list of candidates and find the appropriate Strategy among those candidates, it's just plain old Constructor Injection, and has nothing to do with Service Locator (which is a good thing).
Option 2.
This option sounds like the Metadata Role Hint idiom. Again, if you inject the list of candidates via the constructor, Service Locator is nowhere to be seen.
Option 3.
This options sounds like a variation of the Role Interface Role Hint idiom. Still supports use of good old Constructor Injection.
Personally, I tend to favour Partial Type Name Role Hint because this design doesn't impact the implementation of any business logic. All the selection logic becomes a pure infrastructure concern, and can be defined independently of the implementations and clients.
When it comes to the cost of composing the relevant object graphs, there are ways to address any issues in clean ways.
Do you always create these two abstract base classes as the basis of any new project in DDD?
I've read that Entity should have two things. First, an identity property, probably of a generic type. Second, an Equals() method that determines whether it's the same as another Entity. Anything else? Any other natural methods or rules of thumb?
I like to have a common abstract ancestor for all my Domain objects but that is a matter of preference and overall infrastructure requirements.
After that, yes I have abstract classes for Entity and Value objects.
Don't forget that also overriding Equals for Value objects to return equality based on equal property state can be important.
Also people frequently overlook the value of packages. Put all these core base classes in their own "kernel" library and don't be reluctant to split your domain model into multiple assemblies instead of winding up with a single large "Domain Library".
If you're using .NET/C#, I've published a set of DDD interfaces and classes for public use. Take a look to see what typically goes inside them. The embedded code comments should hint towards their usage.
You can [download it here][1]. Project is dead now.
I've never needed the Equals() method in my applications thus far. Your mileage may vary though.
However, I create empty interfaces and use them as descriptors:
public interface IAggregateRoot {}
public interface IEntity {}
public interface IValueObject {}
public class Order : IAggregateRoot
{
...
}
public class State : IValueObject
{
...
}
Sorry to ask sich a generic question, but I've been studying these and, outside of say the head programming conveying what member MUST be in a class, I just don't see any benefits.
There are two (basic) parts to object oriented programming that give newcomers trouble; the first is inheritance and the second is composition. These are the toughest to 'get'; and once you understand those everything else is just that much easier.
What you're referring to is composition - e.g., what does a class do? If you go the inheritance route, it derives from an abstract class (say Dog IS A Animal) . If you use composition, then you are instituting a contract (A Car HAS A Driver/Loan/Insurance). Anyone that implements your interface must implement the methods of that interface.
This allows for loose coupling; and doesn't tie you down into the inheritance model where it doesn't fit.
Where inheritance fits, use it; but if the relationship between two classes is contractual in nature, or HAS-A vs. IS-A, then use an interface to model that part.
Why Use Interfaces?
For a practical example, let's jump into a business application. If you have a repository; you'll want to make the layer above your repository those of interfaces. That way if you have to change anything in the way the respository works, you won't affect anything since they all obey the same contracts.
Here's our repository:
public interface IUserRepository
{
public void Save();
public void Delete(int id);
public bool Create(User user);
public User GetUserById(int id);
}
Now, I can implement that Repository in a class:
public class UserRepository : IRepository
{
public void Save()
{
//Implement
}
public void Delete(int id)
{
//Implement
}
public bool Create(User user)
{
//Implement
}
public User GetUserById(int id)
{
//Implement
}
}
This separates the Interface from what is calling it. I could change this Class from Linq-To-SQL to inline SQL or Stored procedures, and as long as I implemented the IUserRepository interface, no one would be the wiser; and best of all, there are no classes that derive from my class that could potentially be pissed about my change.
Inheritance and Composition: Best Friends
Inheritance and Composition are meant to tackle different problems. Use each where it fits, and there are entire subsets of problems where you use both.
I was going to leave George to point out that you can now consume the interface rather than the concrete class. It seems like everyone here understands what interfaces are and how to define them, but most have failed to explain the key point of them in a way a student will easily grasp - and something that most courses fail to point out instead leaving you to either grasp at straws or figure it out for yourself so I'll attempt to spell it out in a way that doesn't require either. So hopefully you won't be left thinking "so what, it still seems like a waste of time/effort/code."
public interface ICar
{
public bool EngineIsRunning{ get; }
public void StartEngine();
public void StopEngine();
public int NumberOfWheels{ get; }
public void Drive(string direction);
}
public class SportsCar : ICar
{
public SportsCar
{
Console.WriteLine("New sports car ready for action!");
}
public bool EngineIsRunning{ get; protected set; }
public void StartEngine()
{
if(!EngineIsRunning)
{
EngineIsRunning = true;
Console.WriteLine("Engine is started.");
}
else
Console.WriteLine("Engine is already running.");
}
public void StopEngine()
{
if(EngineIsRunning)
{
EngineIsRunning = false;
Console.WriteLine("Engine is stopped.");
}
else
Console.WriteLine("Engine is already stopped.");
}
public int NumberOfWheels
{
get
{
return 4;
}
}
public void Drive(string direction)
{
if (EngineIsRunning)
Console.WriteLine("Driving {0}", direction);
else
Console.WriteLine("You can only drive when the engine is running.");
}
}
public class CarFactory
{
public ICar BuildCar(string car)
{
switch case(car)
case "SportsCar" :
return Activator.CreateInstance("SportsCar");
default :
/* Return some other concrete class that implements ICar */
}
}
public class Program
{
/* Your car type would be defined in your app.config or some other
* mechanism that is application agnostic - perhaps by implicit
* reference of an existing DLL or something else. My point is that
* while I've hard coded the CarType as "SportsCar" in this example,
* in a real world application, the CarType would not be known at
* design time - only at runtime. */
string CarType = "SportsCar";
/* Now we tell the CarFactory to build us a car of whatever type we
* found from our outside configuration */
ICar car = CarFactory.BuildCar(CarType);
/* And without knowing what type of car it was, we work to the
* interface. The CarFactory could have returned any type of car,
* our application doesn't care. We know that any class returned
* from the CarFactory has the StartEngine(), StopEngine() and Drive()
* methods as well as the NumberOfWheels and EngineIsRunning
* properties. */
if (car != null)
{
car.StartEngine();
Console.WriteLine("Engine is running: {0}", car.EngineIsRunning);
if (car.EngineIsRunning)
{
car.Drive("Forward");
car.StopEngine();
}
}
}
As you can see, we could define any type of car, and as long as that car implements the interface ICar, it will have the predefined properties and methods that we can call from our main application. We don't need to know what type of car is - or even the type of class that was returned from the CarFactory.BuildCar() method. It could return an instance of type "DragRacer" for all we care, all we need to know is that DragRacer implements ICar and we can carry on life as normal.
In a real world application, imagine instead IDataStore where our concrete data store classes provide access to a data store on disk, or on the network, some database, thumb drive, we don't care what - all we would care is that the concrete class that is returned from our class factory implements the interface IDataStore and we can call the methods and properties without needing to know about the underlying architecture of the class.
Another real world implication (for .NET at least) is that if the person who coded the sports car class makes changes to the library that contains the sports car implementation and recompiles, and you've made a hard reference to their library you will need to recompile - whereas if you've coded your application against ICar, you can just replace the DLL with their new version and you can carry on as normal.
So that a given class can inherit from multiple sources, while still only inheriting from a single parent class.
Some programming languages (C++ is the classic example) allow a class to inherit from multiple classes; in this case, interfaces aren't needed (and, generally speaking, don't exist.)
However, when you end up in a language like Java or C# where multiple-inheritance isn't allowed, you need a different mechanism to allow a class to inherit from multiple sources - that is, to represent more than one "is-a" relationships. Enter Interfaces.
So, it lets you define, quite literally, interfaces - a class implementing a given interface will implement a given set of methods, without having to specify anything about how those methods are actually written.
Maybe this resource is helpful: When to Use Interfaces
It allows you to separate the implementation from the definition.
For instance I can define one interface that one section of my code is coded against - as far as it is concerned it is calling members on the interface. Then I can swap implementations in and out as I wish - if I want to create a fake version of the database access component then I can.
Interfaces are the basic building blocks of software components
In Java, interfaces allow you to refer any class that implements the interface. This is similar to subclassing however there are times when you want to refer to classes from completely different hierarchies as if they are the same type.
Speaking from a Java standpoint, you can create an interface, telling any classes that implement said interface, that "you MUST implement these methods" but you don't introduce another class into the hierarchy.
This is desireable because you may want to guarantee that certain mechanisms exist when you want objects of different bases to have the same code semantics (ie same methods that are coded as appropriate in each class) for some purpose, but you don't want to create an abstract class, which would limit you in that now you can't inherit another class.
just a thought... i only tinker with Java. I'm no expert.
Please see my thoughts below. 2 different devices need to receive messages from our computer. one resides across the internet and uses http as a transport protocol. the other sits 10 feet away, connect via USB.
Note, this syntax is pseudo-code.
interface writeable
{
void open();
void write();
void close();
}
class A : HTTP_CONNECTION implements writeable
{
//here, opening means opening an HTTP connection.
//maybe writing means to assemble our message for a specific protocol on top of
//HTTP
//maybe closing means to terminate the connection
}
class B : USB_DEVICE implements writeable
{
//open means open a serial connection
//write means write the same message as above, for a different protocol and device
//close means to release USB object gracefully.
}
Interfaces create a layer insulation between a consumer and a supplier. This layer of insulation can be used for different things. But overall, if used correctly they reduce the dependency density (and the resulting complexity) in the application.
I wish to support Electron's answer as the most valid answer.
Object oriented programming facilitates the declaration of contracts.
A class declaration is the contract. The contract is a commitment from the class to provide features according to types/signatures that have been declared by the class. In the common oo languages, each class has a public and a protected contract.
Obviously, we all know that an interface is an empty unfulfilled class template that can be allowed to masquerade as a class. But why have empty unfulfilled class contracts?
An implemented class has all of its contracts spontaneously fulfilled.
An abstract class is a partially fulfilled contract.
A class spontaneously projects a personality thro its implemented features saying it is qualified for a certain job description. However, it also could project more than one personality to qualify itself for more than one job description.
But why should a class Motorcar not present its complete personality honestly rather than hide behind the curtains of multiple-personalities? That is because, a class Bicycle, Boat or Skateboard that wishes to present itself as much as a mode of Transport does not wish to implement all the complexities and constraints of a Motorcar. A boat needs to be capable of water travel which a Motorcar needs not. Then why not give a Motorcar all the features of a Boat too - of course, the response to such a proposal would be - are you kiddin?
Sometimes, we just wish to declare an unfulfilled contract without bothering with the implementation. A totally unfulfilled abstract class is simply an interface. Perhaps, an interface is akin to the blank legal forms you could buy from a stationary shop.
Therefore, in an environment that allows multiple inheritances, interfaces/totally-abstract-classes are useful when we just wish to declare unfulfilled contracts that someone else could fulfill.
In an environment that disallows multiple inheritances, having interfaces is the only way to allow an implementing class to project multiple personalities.
Consider
interface Transportation
{
takePassengers();
gotoDestination(Destination d);
}
class Motorcar implements Transportation
{
cleanWindshiedl();
getOilChange();
doMillionsOtherThings();
...
takePassengers();
gotoDestination(Destination d);
}
class Kayak implements Transportation
{
paddle();
getCarriedAcrossRapids();
...
takePassengers();
gotoDestination(Destination d);
}
An activity requiring Transportation has to be blind to the millions alternatives of transportation. Because it just wants to call
Transportation.takePassengers or
Transportation.gotoDestination
because it is requesting for transportation however it is fulfilled. This is modular thinking and programming, because we don't want to restrict ourselves to a Motorcar or Kayak for transportation. If we restricted to all the transportation we know, we would need to spend a lot of time finding out all the current transportation technologies and see if it fits into our plan of activities.
We also do not know that in the future, a new mode of transport called AntiGravityCar would be developed. And after spending so much time unnecessarily accommodating every mode of transport we possibly know, we find that our routine does not allow us to use AntiGravityCar. But with a specific contract that is blind any technology other than that it requires, not only do we not waste time considering all sorts of behaviours of various transports, but any future transport development that implements the Transport interface can simply include itself into the activity without further ado.
None of the answers yet mention the key word: substitutability. Any object which implements interface Foo may be substituted for "a thing that implements Foo" in any code that needs the latter. In many frameworks, an object must give a single answer to the question "What type of thing are you", and a single answer to "What is your type derived from"; nonetheless, it may be helpful for a type to be substitutable for many different kinds of things. Interfaces allow for that. A VolkswagonBeetleConvertible is derived from VolkswagonBeetle, and a FordMustangConvertible is derived from FordMustang. Both VolkswagonBeetleConvertible and FordMustangConvertible implement IOpenableTop, even though neither class' parent type does. Consequently, the two derived types mentioned can be substituted for "a thing which implements IOpenableTop".
I have a Foo entity in Entity Framework. But I'm making it inherit from IFoo so that my business logic only knows IFoo - thus abstracting Entity Framework away.
The problem is that Foo has a collection of Bar entities. And this collection is of type EntityCollection<Bar> .
If I put this collection in IFoo as it is, I make IFoo dependent on Entity Framework. So I thought of putting it as ICollection<IBar>, but this doesn't compile (naturally).
The only solution I can think of is to go to the concrete Foo implementation generated by the Entity Framework designer and change the collection from EntityCollection<Bar> to ICollection<IBar> there. But I dread the thought of the implications this will have on Entity Framework "behind the scenes".
Is there any way for me to define IFoo and IBar independently of Entity Framework while still maintaining Foo and Bar as EF Entities that implement them? Do IFoo and IBar even make sense, if I cannot achieve this independence that I aim for?
The general concept you are referring to is "persistence ignorance" (PI), although that generally applies directly to entities themselves rather than the code that consumes the entities.
In any case, Hibernate and NHibernate natively support PI, but the initial version of Microsoft's Entity Framework does not. MS caught a lot of flak for this and PI is probably the #1 most discussed feature for the next version (whenever that is).
As far as what you are trying to do with interfaces, does the collection of Bars need to be modified after it is retrieved? If the answer is yes, there is no easy answer. Even covariance couldn't help you here because ICollection<T> has an Add method.
If the collection is read-only, then you might consider exposing it as IEnumerable<IBar>. The Enumerable.Cast method makes this fairly convenient.
interface IFoo
{
IEnumerable<IBar> Bars { get; }
}
partial class Foo : IFoo
{
IEnumerable<IBar> IFoo.Bars
{
get { return Bars.Cast<IBar>(); }
}
}
Also, I know of at least one effort to make the current version of EF support persistence ignorance.
I'm a Java developer, so I can't comment with any authority on Entity Framework. I can tell you that ORM solutions like Hibernate make it possible to have POJO persistence without having to resort to common abstract classes, interfaces, or modifying byte code. It handles relationships like the 1:m you cite for your Foo and Bar without having to use special collection classes.
The special sauce is externalized into mapping configuration and Hibernate itself.
The little bit that I read about Entity Framework suggests that it's an ORM solution with the same aim: POCO persistence. I didn't see any mention of interfaces. I can't see the need for them from your example, because it's too abstract.
I'm inferring that it's possible to get that independence between business objects and persistence tier without having to resort to those interfaces, because I know Hibernate does it. I'd say that Spring's JDBC solution accomplishes it as well, because there's no need for common interfaces. They use a RowMapper construct to ferry data out of a query and into an object.
I wish I could advise you precisely how to do it with Entity Framework, but maybe you'll take heart knowing that it can be done.
I recently wrote a comprehensive post about this: Persistence Ignorance in ADO.NET Entity Framework. You might want to look at EFPocoAdapter. That does just this and it will eventually deprecate into EF v2.
For what it's worth, I am using EFPocoAdapater and it's been working well for me.
We've been doing the exact same thing for LINQ to SQL. I got around the collection issue by writing a class which wraps an IList and casts to and from the correct type as required. It looks a bit like this:
public class ListWrapper<TSource, TTarget> : IList<TTarget>
where TTarget : class
where TSource : class, TTarget
{
private IList<TSource> internalList;
public ListWrapper(IList<TSource> internalList)
{
this.internalList = internalList;
}
public void Add(TTarget item)
{
internalList.Add((TSource)item);
}
public IEnumerator<TTarget> GetEnumerator()
{
return new EnumeratorWrapper<TSource, TTarget>(internalList.GetEnumerator());
}
// and all the other IList members
}
EnumeratorWrapper similarly wraps an IEnumerator and performs the casting.
In the LINQ to SQL partial classes we expose the property like this:
public IList<ICustomer> Foos
{
get
{
return new ListWrapper<Foo, IFoo>(this.Foos_internal);
}
}
Any changes to the exposed list will be performed on the internal EntitySet so they stay in sync.
This works well enough but my feeling is that this whole approach is more trouble than it's worth, I'm a huge NHibernate fan and a strong believer in P.I. but we've put in a LOT of extra effort doing this and haven't really seen any advantage. We use the repository pattern to abstract away the actual DataContext access which I would say is the key part of decoupling ourselves from LINQ to SQL.
Use a partial class to seperate your logic and rules from the autogenerated EF objects. In the example below FooEntityObject class is split into two using the partial keyword. I've used this technique before with EF and LINQ to SQL. The partial classes can be stored in seperate files so if your regenerate your EF object again your custom code doesn't get overwriten.
interface IFoo
{
public ICollection<IBar> GetBars();
}
public partial class FooEntityObject : IFoo
{
public ICollection<IBar> GetBars()
{
// convert EntityCollection<Bar> into ICollection<IBar> here
}
}
public partial class FooEntityObject
{
EntityCollection<Bar> Bars{get;set;}
}