In wcsf, it is possible to make a business module with a separate class library just for interfaces, if I tick the relevant box/boxes.
What is the point in having a separate class library just for interfaces? Wouldn't this add unnecessary bloat to my project and create a high coupling between two class libraries? What would be wrong with storing the interfaces in the class library storing concrete classes?
Thanks.
The advantage to storing the interfaces in a separate class library is that it actually decouples the implementing and using class libraries. If the interfaces are with the concrete implementing classes, then you have
ImplementingClasses.dll <--- ClientClasses.dll
If you put the interfaces into a separate assembly, it's more like this:
ImplementingClasses.dll ---> Interfaces.dll <--- ClientClasses.dll
Notice how this removes the coupling between your client code and the implementation - this will allow your total application to use a configuration-based approach to locating the proper implementing classes.
Related
What are the similarities & differences between traits, mixins and interfaces. I am trying to get a deeper understanding of these concepts but I don't know enough programming languages that implement these features to truly understand the similarities and differences.
For each of traits, mixins and interfaces
What is the problem being solved?
Is the definition of the concept consistent across programming languages?
What are the similarities between it and the others?
what are the differences between it and the others?
Every reference type in Java, except Object, derives from one single superclass.
By the way, Java classes may implement zero or more interfaces.
Generally speaking, an interface is a contract that describes the methods an implementing class is forced to have, though without directly providing an implementation.
In other words, a Java class is obliged to abide its contract and thus to give implementation to method signatures provided by the interfaces it declares to implement.
An interface constitutes a type. So you can pass parameters and have return values from methods declared as interface types, requiring that way that parameters and return types implement particular methods without necessarily providing a concrete implementation for them.
This sets the basis for several abstraction patterns, like, for example, dependency injection.
Scala, on its own, has traits. Traits give you all the features of Java interfaces, with the significant difference that they can contain method implementations and variables.
Traits are a smart way of implementing methods just once and - by means of that - distribute those methods into all the classes that extend the trait.
Like interfaces for Java classes, you can mix more than one trait into a Scala class.
Since I have no Ruby background, though, I'll point you to an excerpt from David Pollak's "Beginning Scala" (amazon link):
Ruby has mixins, which are collections of methods that can be mixed into any class. Because Ruby does not have static typing and there is no way to declare the types of method parameters, there’s no reasonable way to use mixins to define a contract like interfaces. Ruby mixins provide a mechanism for composing code into classes but not a mechanism for defining or enforcing parameter types.
Interfaces can do even more than is described in this post; as the topic can be vast, I suggest you to investigate more in each one of the three directions, while if you even have Java background, Scala and therefore traits are affordable to learn.
In my application I have an assembly - MyApplication.Core which contains all of my domain objects - Customer, Order etc, as well as interfaces for repositories - ICustomerRepository, IOrderRepository
I have another assembly - MyApplication.Data which contains concrete implementations of those interfaces - OrderRepository etc. The repositories are responsible for retrieving data from the DB and presenting it using the domain objects.
One thing I'm not sure about is whether my domain objects should be classes or interfaces. Would it make more sense for me to define interfaces like ICustomer, IOrder in my Core assembly, and then have the Data assembly provide the concrete implementations? From what I've read so far, it seems that actual classes are recommended, what is the reason behind this?
Your Aggregates, Entities and Value objects don't need to be defined as interfaces because you should not be trying to avoiding coupling other code to them. Every layer in the Onion Architecture is allowed to have a direct dependency on your Core/Model. Another good rule of thumb is that it is hard to imagine an alternative implementation of the Customer for example.
Repositories on the other hand are usually defined as interfaces so that the code that uses them does not get a dependency on ORM (or data access libraries) that you use to implement a repository.
Speaking of interfaces outside DDD context, I find this article by Mark Seemann very useful: Interfaces are not abstractions.
Would it make more sense for me to define interfaces like ICustomer,
IOrder in my Core assembly, and then have the Data assembly provide
the concrete implementations?
This may be a sign that your domain objects are really data objects and the design suffers from the AnemicDomainModel anti-pattern. Why would Data assembly contain implementation of the business logic?
In Spring MVC, one can define interceptors that can perform work before and after a particular controller is invoked. This can be used, for example, to do logging, authentication etc.
The programmer who wishes to write a custom interceptor is supposed to implement the HandlerInterceptor interface. To aid this task, the HandlerInterceptorAdaptor abstract base class has been provided, which provides default implementations of all the methods specified in the interface. So, if just wants to do some pre processing, one can just extend HandlerInterceptorAdaptor and #Override public boolean preHandle(...), and not worry about implementing the postHandle function.
My doubt concerns the name. From what I understand of the Adapter pattern, it adapts syntactic impedance mismatches between interfaces.
Is that so? If yes, should the class providing the boilerplate implementations be called HandlerInterceptorDefaultImpl, or something along those lines?
Is there a different nomenclature/pattern for what is happening here?
Is the fact that we need a boilerplate class a code smell, and could be removed by refactoring the HandlerInterceptor interface into two: HandlerPreInterceptor and HandlerPostInterceptor? Or is that overkill?
From GOF book about the Adapter pattern:
Adapters vary in the amount of work they do to adapt Adaptee to the Target Interface. There is a spectrum of possible work, from simple interface conversion-for example,changing the names of operations-to supporting an entirely different set of operations. The amount of work Adapter does depends on how similar the Target interface is to Adaptee's.
The boilerplate class that you are referring to is called skeletal implementation class. This is mentioned in Effective Java by Joshua Bloch. From the book:
You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. The interface still defines the type, but the skeletal implementation takes all of the work out of implementing it.
By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement. For example, the Collections Framework provides a skeletal implementation to go along with each main collection interface: AbstractCollection, AbstractSet, AbstractList, and
AbstractMap. Arguably it would have made sense to call them SkeletalCollection, SkeletalSet, SkeletalList, and SkeletalMap, but the Abstract convention is now firmly established.
I have a very simple question for MVC cause it is the first time i use it in my code.
I have 3 classes, the model, the view and the controller.
The question is :
Should I instantiate the classes separately and use them that way in my application or I can create a class that inherits this 3 classes and instantiate that class instead ?
Most importantly I don't want to violate the main MVC pattern.
You should instantiate the classes separately.
Moreover, it can pay to separate those classes into interfaces and implementation classes for later extensibility. For instance, if your model now reads date from file and later you need to be able to read the same kind of data from a database, you can then make a second implementation of your model class that implements the model interface. your controller that interacts with the model would then only need a change in how it instantiates its model. The rest of the controller implementation can remain the same (as it is has been written against the model interface).
Definitely three separate classes. The whole point of MVC is to have three classes that communicate (through the controller, which handles all the logic of the application). Creating a class that has all three in it would defeat the purpose of MVC.
In the more abstract way, inheritance should not be overused. With inheritance, you couple things together and make it harder to maintain. It contradicts with single resnponsibility principle (SRP) as well: "a class should have only one job".
Also, as any pattern, inheritance had better be only used it is neccessary and fits into the architecture correctly, for example: when there is a class Vehicle, classes Car, Bus and Truck should inherit Car: it is their nature.
So, in this current example, the answer is: It is correct to use model, controller and view classes separately, expecially when MVC pattern itself describes separating of these three parts :)
currently I trying to do something a bit tricky which I don't really know if it's possible to do.
I have a class project and I want to divide it in two sections, "Core" and "Client specific developments". And my client wants the source code of this project but I don't want to deliver the source code of the "Core" section, I just want to give him the source of "Client specific developments".
So to demonstrate a practical case let's imagine that I have a partial class named "User" that have two methods "CreateUser" and "CreateUserForClientSite". So "CreateUser" method will be located in "Core" section and "CreateUserForClientSite" will extend "CreateUser" with specific requirements for my client site (remember this methods may NOT be static, so C# 3.0 class extend feature is pointless in this case). If I have the "Core" section in dll can I extend a partial class present in the dll?
Now let's imagine another scenario. What if "Core" have methods that depend on "Client specific developments" classes, and the other way around? Since I can't do circular reference between projects, how can I manage that (is possible)
Thanks
Regarding the partial classes - you must have all the parts of the partial class available at compile time. You just split definition of a class in several files, but it is still a type that belongs to one assembly.
Thus you cannot compile dll with one part and then reference that assembly in another project and add more methods to the partial class.
I suggest to replace partial classes with inheritance in your case, if possible.
More on partial classes in msdn (look at "Restrictions" section).
Regarding the circular references - you'll have to redesign your object model if splitting into two assemblies leads to this problem. Usually, this indicates flaws in the model that should be fixed anyway.
You can define interfaces in the core assembly to break the circular reference. And implement the interfaces in client specific assembly. Take a look at this article for example - How to get rid of circular references in C#