Related
I have a WPF MVVM app with 3 layers:
UI
Services
DAL
and some item, for example Order. I need 3 DTO:
Class for MVVM layer, with PropertyChanged notification;
Class for Json deserializer (get objects by REST API)
Class for Entity Framework (cache data in DB).
Well, I can use ONE class for all three cases, but this will be mix of different attributes (from EF, JSon, MVVM) and excess dependencies of layers.
Another way: make 3 classes, each layer has own class, and use AutoMapper for fast convert between. No bad, but 3 almost identical (90%) copy of each DTO class... not elegant solution.
What is the best approach? What do you use?
Thanks.
What is the best approach? What do you use?
The second approach, i.e. you define your business objects in a separate assembly that you can reference from all your applications. These classes should not implement any client-specific interfaces such as INotifyPropertyChanged but be pure POCO classes that contains business logic only.
In your WPF application, you then create a view model class that implements the INotifyPropertyChanged interface and wraps any properties of the business object that it makes sense to expose to and bind to from the view.
The view model then has a reference to the model and the view binds to the view model. This is typically how the MVVM design pattern is (or should be) implemented in a WPF application. The view model class contains your application logic, for example how to notify the view when a data bound property value is changed, and the model contains the business logic that is the same across all platforms and applications.
Of course this means that you will end up with a larger number of classes in total but this is not necessarily a bad thing as each class has its own responsibility.
The responsibility of a view model is to act as a model for the application specific XAML view whereas the responsibility of the model class is to implement the business logic and the responsibility of the DTO class is to simply transfer the data between the different tiers. This is a far better solution - at least in my opinion and probably in most enterprise architect's opinions as well - than defining a single class that implements all kind of UI specific logic just for the sake of reducing the number of classes.
I know that packages are collection of Classes and Interfaces, designed to both organize and classify its contents.
I also know that Classes are the definition of Objects, and the instructions for both them, their attributes/variables, and their functions/methods.
However, I have yet to understand what an Interface is, or what it is really for...
I have read this definition on Adobe's website..:
interface
Usage
interface InterfaceName [extends InterfaceName ] {}
Defines an interface. Interfaces are data types that define a set of methods; the methods must be defined by any class that implements the interface.
An interface is similar to a class, with the following important differences:
• Interfaces contain only declarations of methods, not their implementation. That is, every class that implements an interface must provide an implementation for each method declared in the interface.
• Interface method definitions cannot have any attribute such as public or private, but implemented methods must be marked as public in the definition of the class that implements the interface.
• Multiple interfaces can be inherited by an interface by means of the extends statement, or by a class through the implements statement.
Unlike ActionScript 2.0, ActionScript 3.0 allows the use of getter and setter methods in interface definitions.
...However, this is too vague to be helpful to me.
Does anyone know the purpose and proper implementation and/or design of an Interface in ActionScript?
Interfaces basically let you announce "This class can do these things."
As a real world example, you might want to make a tutorial for a game which highlights each of the different controls on screen one by one. Each control might flash or bounce to highlight itself, so you can say they implement an "IHighlightable" interface, and let them take care of the rest:
public interface IHighlightable {
function highlight():void;
}
Then in your controls:
public class Control implements IHighlightable {
public function highlight():void {
// Bounce and flash!
}
}
This means you can do things like:
private function highlightControl(tutorialItem:IHighlightable):void {
tutorialItem.highlight();
}
Importantly, you can have a class implement multiple interfaces, which is useful when classes share abilities, but it doesn't make sense to have them all extend a common base class.
Interfaces are a contract. It is compile time mechanism to force your to implement methods. In large OOP code bases, it is the best practice to have other classes depend on interfaces rather than other classes, so you can swap the implementation without changing the code that consumes the interface (this advantage is discutable in practice, since very often the interface will change too).
I believe interfaces are borrowed from Java which introduced them to achieve polymorphism (ClassA can be of type IFoo and IBar at the same time) without inheriting from multiple abstract classes (you can only extend one class, but you can implement any number of interfaces).
Although I'm technically wrong, I consider interfaces to be similar to C++ abstract classes.
Wikipedia article on Abstract Types
Oracle Java documentation on Abstracts
MSDN article on C# Interfaces
Interfaces are meant to define properties and methods without actually implementing them. Also, they cannot be instantiated
var test:FooInterface = new FooInterface() // would error
After reverse engineering code first, I got entity classes and mapping. Most of the business classes (that I already have) have the same name as entity classes and most of the properties in entity and business classes are the same.
If I understand the implementation right, I should make partial classes with entity classes having all the properties and change the business classes by removing those properties and leaving only the business rules.
If that is correct, what to do about derived classes? Obviously entity classes need all properties from base class. Can I change the code in the entity classes so that the entity classes also inherit from the base classes?
Any thoughts would be welcome.
Perhaps you should remove your business classes. ORM is tool for loading and persisting objects - you don't have special set of objects for persistence and special set of objects for business logic. Use single set which consists of persisted properties and computed properties + business rules executed on persisted properties (store them in partial class). That will form something which is commonly called domain object - it has both data and logic related to its data. You can have separate classes performing logic on multiple domain objects (so the logic doesn't belong to the object itself). These classes are commonly called domain services.
are you saying that most of the properties in entity and business classes are the same ? It shouldn't be like that. Business classes should have only the business logic not the properties of entities. Business class will use entity classes to fulfill the business.
Here is a good example http://code.msdn.microsoft.com/ASPNET-MVC-Application-b01a9fe8/
I guess the question title sums it up. Is there a time when it would be considered good design for an ABC to have data members? I have been wondering if there is a situation where this is OK. The only ones I can come up with all are static, and even then it's kind of a stretch.
I don't see why an ABC couldn't properly have per-instance (aka non-static) data members, as needed to support the methods it supplies to subclasses. Take the common case in which an ABC exists to supply a Template Method DP (the hook methods being abstract) -- if part of the function of the organizing method is to update some instance variables (for example, a count of how many times the method was called), then obviously those variables should also be supplied by the ABC. Can you explain better why you think that's bad design?!
An abstract class can have whatever members it needs to support the functionality it supplies to the classes that inherit from it. That's not to say these would be directly accessible to the subclasses: they might be read and changed only through method calls made by the subclasses or their clients.
I see this in plugin architectures, like Paint.NET's.
Inversion of Control might require this. For example you have a bunch of classes that take an instance of Logger, the abstract class they're based off might have a constructor store it in an member variable or private property (assuming of course you remember to call the base constructor grin)
It is OK, when your data member in your abstract class contains base code for inheriting classes
I would think about using an interface, when the data member is just to describe your class
Yes, its possible to provide member variables in an abstract base class with the intention that its subclasses will use those members to make a concrete implementation.
Here's a concrete example, using a car analogy that we've all come to love.
Let's say we make Car an abstract base class, which has placeholders for wheels, chassis, and an engine for its its subclasses to use:
abstract class Car {
Wheels wheels
Chassis chassis
Engine engine
abstract void accelerate();
abstract void decelerate();
}
Now, for a class that extends Car, the members are already there to use, so the responsibility of a subclass is to populate those member variables:
class NiceCar extends Car {
Decoration decoration;
public NiceCar() {
wheels = new ChromeWheels();
chassis = new LightweightCompositeChassis();
engine = new LotsOfHorsepowerEngine();
decoration = new CoolRacingStripes();
}
void accelerate() {
engine.feedFuel();
}
void decelerate() {
wheels.applyBrakes();
}
}
As can be seen, the abstract base class can work as a blueprint for which components (member variables) should be filled in to get a full functionality of a class. In this case, the Car provides basic parts of a car to be used in a concrete implementation. NiceCar uses those member fields and adds some for its own features, such as a decorative paint job.
I suspect that you are drawing too tight a circle around your concept of an abstract base class.
An abstract base class (as opposed to a pure interface) is a class that intends for some of its functionality to be used by child classes. It will thus have some functionality along with methods that are intended to be over-ridden (the interface part). There is no reason why this functionality should not have member variables associated with it.
Many frameworks are based off of inheritance. These will almost inevitably have abstract classes with member variables. For instance, DirectShow is the multimedia streaming framework in Windows. The sources, encoders, decoders, etc. are all implemented in what are called "filters". There are base classes for various types of filters. Each of them will have member variables for the upstream and downstream filters, the negotiated media types, etc.
As others have mentioned one adds instance fields to any sort of class when one needs to store state. This holds true of abstract or concrete classes - there is no difference.
Why should it make difference ? After all an abstract class is just like anyclass except it can't be instsntiated, requiring subclassing etc to complete the class.
If it's a state used by all inherited classes, I think it's mandatory to move it to the base class. Even though the base is abstract. I think most people that are into refactoring would agree with me on this.
There might be several reasons why some state should be in the base. Reducing code duplication is a good reason enough.
This question already has answers here:
Interface vs Base class
(38 answers)
Closed 12 months ago.
I have been getting deeper into the world of OOP, design patterns, and actionscript 3 and I am still curious how to know when to use an Abstract class (pseudo for AS3 which doesn't support Abstract classes) and an interface. To me both just serve as templates that make sure certain methods are implemented in a given class. Is the difference solely in the fact that Abstract classes require inheritance and an Interface merely extends?
Use an abstract class if you have some functionality that you want it's subclasses to have. For instance, if you have a set of functions that you want all of the base abstract class's subclasses to have.
Use an interface if you just want a general contract on behavior/functionality. If you have a function or object that you want to take in a set of different objects, use an interface. Then you can change out the object that is passed in, without changing the method or object that is taking it.
Interfaces are typically loose, compared to Abstract classes. You wouldn't want to use interfaces in a situation where you are constantly writing the same code for all of the interface's methods. Use an abstract class and define each method once.
Also, if you are trying to create a specific object inheritance hierarchy, you really wouldn't want to try to do that with just interfaces.
Also, again, in some languages you can only have a single base class, and if an object already has a base class, you are going to have to do some refactoring in order to use an abstract base class. This may or may not mean that you might want to use an inteface instead.
As #tvanfosson notes, it's not a bad idea to use a lot of interfaces, when you really understand abstract classes and interfaces, it's not really an either/or situation. A particular situation could use both abstract classes and interfaces or neither. I like to use interfaces sometimes simply to restrict what a method or object can access on a passed in parameter object.
Abstract classes offer the possibility to implement specific methods and require others to be implemented in the inheriting class. With interfaces, everything has to be implemented in the implementing class.
As #m4bwav notes, the primary difference is that an abstract class can, and often does, provide a default implementation for at least some methods. This allows you to use the abstract class to keep your code DRY (don't repeat yourself), by keeping code common to all classes that inherit from the abstract class in the abstract class itself.
I think it's a false dilemma, though. You don't need to and arguably shouldn't choose between interfaces and abstract classes. In most cases, you would want to define the interface, then have your abstract class provide a default, skeleton implementation if one is required/desired. For me the question would be do I need an interface or an interface and an abstract class rather than an interface or an abstract class. Using the interface decouples your code from any particular implementation, even your abstract class implementation. If you should choose to have an alternate implementation, using the interface would allow this whereas if you only had the abstract class, you'd have to refactor to add the interface later.
The only situation where I can see that providing an interface in such a situation would not be desired is where you want to restrict it so that only your implementation can be used. Using the abstract class and having certain methods be not be virtual would enforce the use of your code in all circumstances where the implementer is deriving from your class.