GoF book states that there are two ways to implement Factory Method:
Consider the following issues when applying the Factory Method pattern:
Two major varieties. The two main variations of the Factory Method pattern are the case when the Creator class is an abstract
class and does not provide an implementation for the factory method it
declares, and the case when the Creator is a concrete class and
provides a default implementation for the factory method. It’s also
possible to have an abstract class that defines a default
implementation, but this is less common. The first case requires
subclasses to define an implementation, because there’s no reasonable
default. It gets around the dilemma of having to instantiate
unforeseeable classes. In the second case, the concrete Creator uses
the factory method primarily for flexibility. It’s following a rule
that says, “Create objects in a separate operation so that subclasses
can override the way they’re created.” This rule ensures that
designers of subclasses can change the class of objects their parent
class instantiates if necessary.
Parameterized factory methods. Another variation on the pattern lets the factory method create multiple kinds of products. The factory
method takes a parameter that identifies the kind of object to create.
All objects the factory method creates will share the Product
interface. In the Document example, Application might support
different kinds of Documents. You pass CreateDocument an extra
parameter to specify the kind of document to create.
Design Patterns (Design Patterns: Elements of Reusable Object-Oriented Software)
In what cases should I use one approach instead of another. What the benefits and drawbacks when I prefer one approach instead of another?
Thanks in advance.
Kudos for reading the book. Most people attempt #2 believing that is the Factory Method pattern, when in fact #1 claims to describe the two major varieties.
So we're actually dealing with three slightly different versions of the pattern in the quoted text, though only two of them are numbered. The differences between these versions are based on how much information the Creator has about which Product implementation it wants.
A Creator with an abstract Factory Method knows nothing about the Product implementation and leaves everything up to the ConcreteCreator.
A Creator with a default Factory Method knows what Product implementation it wants most of the time, but not always; so it allows a ConcreteCreator to override the default.
A Creator with a parameterized Factory Method has a menu of Product implementations to choose from and decides which one to ask the ConcreteCreator for.
So in each consecutive version, the Creator has progressively more information about the Product implementations and more logic concerning how the implementation is chosen.
In the Factory Method pattern, a Creator delegates responsibility for creating objects to its child classes because it, "can't anticipate the class of objects it must create." (page 108) Based on the different varieties, we can see how the pattern changes slightly when a Creator can anticipate some information about the class of objects to create.
The version you choose depends on how much you know about the Product implementations at compile time.
Related
I'm currently designing the domain for a reservation system meant for 2 types of reservations.
Both of these types have common properties, such as their date and location. Both also have properties which the other does not, though. Examples here are in one type you can bring along guests, and not with the other; or you can request lunch for one type, and not the other.
Currently I have an abstract Reservation class, with a concrete implementations per type of reservation. I then have a ReservationBuilder which takes an enum (reservation type) as argument in its constructor. This builder would then contain methods for both types of reservations, and using a method for a type of reservation that cannot use the information would either do nothing when built, or throw an error.
Something tells me that this isn't a good use of this pattern, though. Would it be better to abstract the builder too? Or would a factory pattern better suit my use case?
You have identified the need for an abstract superclass, Reservation. You have also identified the need for specialization in child classes, like GroupReservation, RoomServiceReservation.
What is the motivation for using a builder or factory pattern? If the problem is to create a new instance of a class given a string, a few if statements or a case statement would work fine.
if(userSelection.equals("group")) {
return new GroupReservation();
}
If the motivation is for something more complex, a builder or factory class might be useful. The messy details of selecting and instantiating a concrete class can be hidden that way.
Object-oriented programmers can unwittingly wear "pattern goggles". When we wear pattern goggles, we approach every design choice looking for just the right pattern to implement. Sometimes there is a language feature we can use that eliminates the need for a pattern. And sometimes an if statement is good enough.
I am struggling to understand both abstract and interface approach. Since i get the idea what is the purpose to use one over another is clear. I was trying to found whatever example of using them both in action however all tutorials are how to use interface over abstract or vice versa showing usage either for one or another. I would really love to see practical example which could show both in action best on some real life example. Additional comments why in specific case you used one over another appreciated. Generics are very welcome to see as well in such example.
I'll propose foloowing example. We got some engine to get files from diffrent locations which could be taken using diffrent protocols as follows. I would like to understand on this example how this could be accomplished with both interfaces and abstract.
'As all of protocol has to close and open would it be good to put in abstract?
abstract class Collector
Protected Id
Protected Name
MustInherit Sub OpenConnection
MustInherit Sub CloseConection
End Class
'?
class Ftp : Collector
class Sftp: Collector
class Soap: Collector
'Interface?
Public Interface IRepository(Of T, Tkey)
Function GetAllFiles() As IEnumerable(Of T)
Function GetAllById(Tkey) as IEnumerable(Of T)
End Interface
Some key distinctions:
An abstract class can contain some implementation. An interface cannot.
In .NET, a class can not inherit from multiple base classes.
A class can implement multiple interfaces
The choice of which approach is really up to you. In general, it's a choice between the Composition pattern or Inheritance.
Composition uses Interfaces. Think of an object as having X.
Inheritance uses Classes. Think of an object as being X.
In either case, an abstract class or an interface is just a Type, through which you will access and manipulate them. For example, if you have some code that wants to perform Insert/Update/Delete operations, it doesn't need to know that the object it is operating on is a FTP client--only that the object has the ability to support these operations. (and that is exactly what IRepository specifies)
You definitely can combine both. There's no reason a concrete FtpClient class couldn't inherit from an abstract Protocol class and also implement the IRepository interface. It could even use generics!
Interfaces are great for decoupling your code, and also great for unit test mocks.
There is also a good summary of pros & cons on Wikipedia (Composition_over_inheritance). Pros:
To favor composition over inheritance is a design principle that gives the design higher flexibility. It is more natural to build business-domain classes out of various components than trying to find commonality between them and creating a family tree. For example, a gas pedal and a wheel share very few common traits, yet are both vital components in a car. What they can do and how they can be used to benefit the car is easily defined. Composition also provides a more stable business domain in the long term as it is less prone to the quirks of the family members. In other words, it is better to compose what an object can do (HAS-A) than extend what it is (IS-A).
Initial design is simplified by identifying system object behaviors in separate interfaces instead of creating a hierarchical relationship to distribute behaviors among business-domain classes via inheritance. This approach more easily accommodates future requirements changes that would otherwise require a complete restructuring of business-domain classes in the inheritance model. Additionally, it avoids problems often associated with relatively minor changes to an inheritance-based model that includes several generations of classes.
Cons:
One common drawback of using composition instead of inheritance is that methods being provided by individual components may have to be implemented in the derived type, even if they are only forwarding methods. In contrast, inheritance does not require all of the base class's methods to be re-implemented within the derived class. Rather, the derived class only needs to implement (override) the methods having different behavior than the base class methods. This can require significantly less programming effort if the base class contains many methods providing default behavior and only a few of them need to be overridden within the derived class.
I don't understand why you want to have an example combining both. Let's just say both are valid ways to build solid software architecture. They're just two tools - like having a kitchen knife and a meat cleaver. You won't necessarily use them together but see the pro's and con's when looking at the dinner you want to serve.
So usually you take abstract/MustInherit classes if you want to provide a common denominator. Sub-classes derive from the abstract one and have to implement the methods just like they would if they implemeted an interface. The good thing here is that abstract classes can provide "base logic" which can be developed centrally and all the sub-classes can make use of that. In the best case, abstract classes provide kind of "hooks" to plug in special logic in the sub-classes.
Interfaces describe what a class has to fulfill. So everything an interface defines has to be implemented in classes implementing the interface. There's no reusable logic built-in in this approach like in abstract base classes but the big "pro" for interfaces is that they don't take away the single base type you can derive from like abstract classes do. So you can derive from anything or nothing and still implement an interface. AND: You can implement multiple interfaces.
One word to the "reusable logic" with interfaces. While this is not really wroing, the .NET framework allows use to write extension methods on types (and interfaces) to attach externally developed code. This allows code reuse with interfaces like having a method implemented in there. So for example, you could write an extension method None() for the interface IEnumerable which is checking whether the enumerable is empty.
public static bool None(this IEnumerable values)
{
return !values.Any();
}
With this, None() can be used on any IEnumerable in your code base having access to the extension method (in fact, Any(), Select(), Where(), etc. are extension methods as well, lying in the System.Linq namespace).
Apparently, singletons are bad, and a factory method is recommended. I'm wondering if a singleton toolbox is any better than a singleton.
In my opinion, It's really weak to think that singletons are bad,factory methods are good.
Each of them has preferences. As consequence, I'm sure that there is misunderstanding here.
I know that wikipedia is not the best source. But check out the definition of them. The range of situations are not the same for these patterns.
In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.
In class-based programming, the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created. This is done by creating objects via calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.
why is it recommended to define service contract as an interface.
Any specific advantages over having them as classes?
The primary goal is separate definition of your service from implementation
The user of your service should not know anything about how you implemented your service, but he should know what operations he can do and how.
That's why its using an interface instead of class, because interface doesn't contain an implementation.
You can share your interface one time and then never worry for years even if you changing implementation of its methods every day. End users will not need to recompile the code that's using your service
Of course [there are several advantages] !
The main one is probably the ability to implement multiple classes which support said Interface and to use these classes interchangeably [with regards to the particular interface]. One of the direct uses of this is with Mock classes used for testing; This is also used with IoC (Inversion of Control) pattern, and more generally wherever we care about the "What" rather than the "Who", i.e. What matters is that whichever class is in place it behaves as per the contract (the API) regardless of "who" (which class) it is.
Another salient advantage of Interfaces is the ability to modularize behavior. For example your application may implement a concept which works, say, like a List (can be iterated over, supplies a number of items, etc.) and like a widget validator (some application specific thing). By having two interfaces "describing" this particular object, you can use instances of that class wherevever you'd use a List (and just that) and similarly you can use it as a widget validator (and just that) whereever these validator are needed. This is akin to multiple inheritance but more flexible.
In a nutshell (and some other answers started with this), the Interface defines the contract and the Class(es) implement(s) it.
Technically, a single class could do both of these things, i.e. you do not __need __ to have Interfaces, but it is very preferable to define APIs for most any behavior which may be implemented by several classes (whether multiple implementations of almost the same thing as with "mock classes", or very different classes but supplying one particular generic service/feature as say two very distinct Lists.)
Because an interface IS a contract and a class is the means to fulfill a contract. There can be many different ways to fulfill a contract based on the context, so It makes more sense to have the contracts as interfaces. which can have different implementations
Abstract classes are described as being useful for a family of objects (e.g. could be used for animals which are mammals). However, what difference is there between using an interface or abstract class for representing a family of related objects?
My process is to use an abstract class when I want to define common functionality but with the option for future extensions and an interface for custom functionality (implementations).
For example, I wrote an abstract class to encapsulate some database functionality which will be used heavily in a small web app at work. I wrote an abstract class with virtual methods which can be overrided with custom functionality in the future (e.g. logging, or some reporting of the database events which may be required).
Is this the right way to go? Is there any significance in choosing one construct (abstract or interface) to represent a family?
An abstract class should be used when there is common state and behavior between all types. An interface should be used when all types will have a common interface but will not share state or behavior.
Here is an example.
German Shepherd, Golden Retriever, Beagle
These three objects are all dogs, and as such they share certain common state (carnivorous, 4 legs, etc.) and they also share certain overridable behavior (bark, pant, etc.). In this instance it would make the most sense to create an abstract Dog class to hold this common state and behavior and create subtypes of Dog for each type of dog.
Pencil, Pen, Chalk
These objects have no common state and they cannot share behavior. Yet you may notice that they do have something in common - they are cabaple of writing. These objects are best build separately and without a base class and then tied together with a Writable interface that exposes each type's Write method.
I would suggest using interfaces so that you can implement new functionality in your database utility at some future point.
As always, the primary design principle when it comes to development is
Design towards an interface, not an implementation
With abstract classes, you can provide implementation that is needed and shared by all the classes in your hierarchy. Therefore, you're reusing code. You may allow the derived classes to override the default behavior or not but at least you're providing a baseline functionality like breathing for a new born animal. However, with interfaces, you can't provide any implementation. You simply define a contract that all classes that inherits that interface should honor and provide implementation for. This may lead to repetitive and duplicate code among the hierarchy of classes.
Interfaces are not very good for extensibility and you need to worry about versioning. You decide to make change to an existing interface but you will soon realize that there are a lot of classes in existence you may need to modify. Think about adding Breath method to IMammal interface that's already being used by many mammals. You will need to go and provide Breath implementation for each one. With an abstract class, you can simply add Breath method and provide some baseline implementation without having to worry about existing derived classes. So abstract classes are more flexible in term of the development of your hierarchy and the api.