There are a few questions already on Stackoverflow with similar scenarios, but they don't really address my case.
I am currently doing some refactoring and would like to make the code more robust, flexible and readable by applying patterns. Here is the task:
I have a class, let's say class A, which applies some logic when setting one of its members. This logic is prone to change, so I would like to externalise it. This is where the strategy pattern would be useful.
Also, at some stage I need to filter a list of objects of class A. The filter logic should also be configurable, so the stragey pattern would be handy in this task also.
The question is: How do I combine these requirements into the object-oriented design?
My thoughts so far:
- Use a factory for objects of type A, that has two strategy objects: SettingMemberStrategy and FilterStrategy. If the concrete factory is implemented as singleton, the two strategy objects need to be specified before objects can be created.
- Have two methods on the interface of class A: setMember(value); boolean filtered(). The exact implementation of these methods is determined by the strategies. However, should the object then also carry instances of the strategies?
This approach might work, but it seems a bit overengineered for the task and aesthetically not too pleasing.
Could someone hint at a better solution?
Thanks a million.
Cheers,
Martin
public interface IA {
setMember();
filter();
}
public class A implements IA {
private String theMember = "";
getMember() { return this.theMember; }
setMember(String input, otherParameters[]) {
// set value for member based on strategy and parameters
}
boolean filter();
// returns yes/no based on whether this class should be filtered
// as per filter strategy
}
public class myFactory {
private FilterStrategy myFilterStrategy;
private MemberStrategy mySetMemberStrategy;
IA createObjectOfClassA() {
a = new A(mySetMemberStrategy, myFilterStrategy);
}
setFilterStrategy(FilterStrategy s) { this.myFilterStrategy = s }
setMemberStrategy(MemberStrategy s) { this.mySetMemberStrategy = s }
}
This question depends entirely on how you use these objects. My instinct tells me that in most cases you don't need both a factory and a strategy pattern - you would want to choose one or the other, thus simplifying your code.
If for example, you are creating subclasses of object A in your factory, then eliminate the configurable strategy and bake it into your subclasses.
If, however, you don't create subclasses, just have objects with configurable strategies, then eliminate the factory, and just create the objects with the appropriate strategy in their constructor when you need them.
You could also have a combination of the two if you for example create objects based on an input, and use a factory method to give you a proper instance, i.e.
public A MyFactoryMethod(string typeToCreate){
switch(typeToCreate) {
case "AbeforeB":
return new A(new FilterStrategyA(), new MemberStragegyB());
case "allA":
return new A(new FilterA(), new MemberStrategyA());
// etc. etc.
}
}
Related
I have some confusion about use of Controller with Repository Pattern while maintaining SOLID Principle. Consider, I have two types of Quotations
Commercial Quotation
Private Quotation
And there is a high chance of new types of quotations in future. Each Quotations has different fields, business logics yet they share many common functions. So I created a QuotationInterface
Quotation Inteface
interface QuotationInterface
{
public function save(array $data);
}
Quotation class that implement the interface
class CommercialQuotation implements QuotationInterface
{
public function(array $data)
{
// save commercial quotation
}
}
class PrivateQuotation implements QuotationInterface
{
public function(array $data)
{
// save Private quotation
}
}
Quotation Repository
class QuotationRepository
{
public function save(array $data, QuotationInterface $quotation)
{
$quotation->save($data);
}
}
QotationController
public function store(Resource $resource)
{
$inputs = $resource->all();
/**
* Clearly here Open/Close Principle is broken
*/
if ($inputs['type'] == 'private'){
$quotation = new PrivateQuotation;;
}
else if($inputs['type'] == 'commercial'){
$quotation = new CommercialQuotation;
}
$this->repo->save($inputs, $quotation);
}
Here in my QuotationController, it is clearly violating Open/Close Principle..
Is it a good idea to Create a Controller for each type of quotation (might be 10+ some day, who know?) to avoid the OCP violation or my design is just wrong? Any suggestion, design change tips, resource are welcome.
NOTE: My Quotation Controller will have many other functions except the save only.
If you're going ahead the way you've shown, i suggest you to use a single controller for your quotations and use a Factory design pattern to create your $quotation objects
For example, with a simple factory like this:
//FACTORY CLASS
abstract class QuotationFactory
{
/** return QuotationInterface */
public static function createQuotation($type)
{
switch($type)
{
CASE "private":
return new PrivateQuotation();
break;
CASE "commercial":
return new CommercialQuotation();
break;
}
}
}
you could use the factory from you controllers' methods:
//YOUR CONTROLLER'S METHOD
public function store(Resource $resource)
{
$inputs = $resource->all();
//delegate objects creation to factory class
$quotation = QuotationFactory::createQuotation( $inputs['type'] );
$this->repo->save($inputs, $quotation);
}
This way you are not going to violate the open/closed principle in your controllers, because as you add quotations, you'll only need to modify the method of the factory (adding cases to the switch statement ), and it will return a QuotationFactory object wherever needed.
This will also keep your code DRY and SOLID because you don't have to repeat the if/else statements to create your objects in your controller's methods as you delegate the responsability of the objects' creation to a specific factory class
As correctly pointed ount in the comments below, the Simple factory is going to help you avoiding the Open/Closed Principle in your controllers but be ware that, from a more general point of view, the Simple Factory itself is inherently violating the OCP as it uses a switch case.
Anyway, from what i see of your application, the Simple factory could be a good solution, as your primary concern is to build in many places instances from a variable type. Thus, using the Simple factory you can 'hide' this process of creating objects into the factory and get the instances you need in your controllers. So you are violating the OCP only inside the factory in the switch case, but i think this could be a beareble trade-off
I think this mostly depends on the scope of your application. In the PHP world these days, people are so angry with if/else statements :). However, if that works for your application and seems reasonable in the scope of YOUR context, I think that's fine.
Businesses change and Business changes aren't always easy to plan for. You can only try to make those changes easier when they arise.
That being said, classes are cheap and I think that having separate classes at this point (and in the future) is very reasonable. If the requirements for each type of quotation expand, you'll be in good footing and I don't think you're abstracting so far that you're code will be difficult to understand.
I know it's late, but i hope my comment helps more people searching your issue.
You should follow the following principle:
"If you have a conditional like that you should do it in the low level abstraction not in the high level"
so the design should be:
class QuotationFactory
{
public static function make($type)
{
switch($type)
{
CASE "private":
return new PrivateQuotation();
CASE "commercial":
return new CommercialQuotation();
default:
throw new InvalidTypeException("Invalid type code.");
}
}
}
The above refactoring called "Replace conditional/type code with polymorphism".
If there're no new types in the future you should follow "Replace Parameter with explicit methods" refactoring, it would improve the readability.
For more you should read a book called "Refactoring: Improving the Design of Existing Code" by Martin Fowler.
I am trying to implement a simple validator class system which respect SOLID principles and for unit testing purpose.
Suppose I have some simple validators (mandatory, integer, greaterThan ...) and now I want to implement a more complex validator which call several simple validators (example Form Validator which use some validators)
This is very inspired from Zend and other framework.
The question is, how SOLID principle are applied or violated here and how unit testing should be done for this model?
I think I could Unit Test each simple validator easily but not the complex FormValidator
interface ICheckable
{
public function check($data);
}
class MandatoryValidator implements ICheckable
{
private $_property;
public function __construct($property)
{
$this->_property = $property;
}
public function check($data)
{
return isset($data[$property]);
}
}
class IntegerValidator implements ICheckable
{
...
}
class FormValidator implements ICheckable
{
public function check($data)
{
$mandatoryValidator = new MandatoryValidator(array('LOGIN'));
if ($mandatoryValidator->check($data) == false)
{
return false;
}
$integerValidator = new IntegerValidator();
if ($integerValidator->check($data['AMOUNT']) == false)
{
return false;
}
...
return true;
}
}
First - good job with the ICheckable Interface. That's a good start.
Lets tackle the S. Single Responsibility Principle:
That's the principle that states, "a class should only have one reason to change"
Is the S. Respected in all the classes?
(Simple Responsibility.)
The two current validators respect this.
Is FormValidator has only one responsibility? I can see it does 3 things:
Creates the Validators.
Calls the 2 validators.
Checks the validator resutls.
The problem with this design is that everytime you have a new Validator, you have to create it, call it, and check its return value. This violates the O in the SOLID Principles. (Open / Close)
The form Validator should receive a "custom" List of ICheckable. This "custom" list should also impelment ICheckable so you can just call it. This "custom" List will iterate through its list of ICheckable. That will be it's only responsibility.
Then, The Result has to be evaluated. When a function returns a value, you have to process it. In general this means more code, an extra IF statement. Those two should give you a hint: too much responsibility.
So in order to make this SOLID, you should pass your validators a Callback Interface that will serve to process the validator output. Your sample is quite simple, a validator returns true of false. Which can be represented by two "output" methods - Validated() or ValidationFailed(). O_o, this looks like a very nice "output" interface for your validators and could be implemented by the FormValidator. This design would comply the S. O. L. I. D. of the principles.
Remember, when you first create the FormValidator, you have to create the two Validators, the Custom List and connect everything together.
Then you would be able to unit test all very simple classes, very quickly. (try to start writing your test first)
Note: In general if you tackle the S. Properly, the other principles are very easy to implement.
Hope this helps. Let me know if you need more information.
As input I have a list of Books. As output I expect a SimilarBookCollection.
A SimilarBookCollection has an author, publishYear and list of Books. The SimilarBookCollection can't be created if the author of the books is different or if the publishYear is different.
The solution so far in PHP:
client.php
----
$arrBook = array(...); // array of books
$objValidator = new SimilarBookCollectionValidator($arrBook);
if ($objValidator->IsValid()) {
$objSimilarBookCollection = new SimilarBookCollection($arrBook);
echo $objSimilarBookCollection->GetAuthor();
}
else {
echo 'Invalid input';
}
SimilarBookCollection.php
---
class SimilarBookCollection() {
public function SimilarBookCollection(array $arrBook) {
$objValidator = new SimilarBookCollectionValidator($arrBook);
if ($objValidator->IsValid()) {
throw new Exception('Invalid books to create collection');
}
$this->author = $arrBook[0]->GetAuthor();
$this->publishYear = $arrBook[0]->GetPublishYear();
$this->books = $arrBook;
}
public function GetAuthor() {
return $this->author;
}
public function GetPublishYear() {
return $this->publishYear;
}
public function GetBooks() {
return $this->books;
}
}
SimilarBookCollectionValidator.php
---
class SimilarBookCollectionValidator() {
public function IsValid() {
$this->ValidateAtLeastOneBook();
$this->ValidateSameAuthor();
$this->ValidateSameYear();
return $this->blnValid;
}
... //actual validation routines
}
The goal is to have a "special" collection with only books that have the same author and publishYear. The idea is to easily access the repeating information like author or year from the object.
How would you name the SimilarBookCollection? The current name is to
generic. Using a name like SameYearAuthorBookCollection looks a bit
long and strange(if more conditions will be added then name will increase)
Would you use a Validator in SimilarBookCollection constructor using a
defensive programming style?
Would you change the design of the code? If yes how?
It all depends ;)
So if I were to aim for a generic adaptable solution I would do the following:
Validator in constructor
On one hand you are validating twice; that is informative in case of a broken precondition/contract (not giving a valid list), but is double the code to run - for what purpose exactly?
If you want to use this in a system depends on its size, how critical it is, product phase, and likely more criterias.
But then it also is controller logic fitted into a model meaning you are spreading your code around.
I would not put it in the constructor.
Name / Design
I would say keep the BookCollection generic as it is, and have any validation strictly in the controller space, instead of bloating the collection which essentially seems to be an array with the extra field of author.
If you want to differentiate between different collection types use either (multiple) inheritance or some sort of additional field "collectionType"; the former if you expect many derivatives or varying functionality to come (also keeps the logic where different nicely separated).
You could also consider your collection as a set on which you perform queries and for convenience's sake you could maintain some sort of meta data like $AuthorCount = N, $publicationDates = array(...) from which you can quickly derive the collection's nature. This approach would also keep your validator-code minimal (or non-existent), as it'd be implicitly in the collection and you could just do the validation in the controller keeping the effective logic behind it clearly visible.
That would also make it more comfortable for you in the future. But the question really is what you want and need it for, and what changes you expect, because you are supposed to fit your design to your requirements and likely changes.
For your very particular problem the constraints as I understand are as follows:
There is only one collection type class in the system at any given
point in time.
The class's items have several attributes, and for a particular, possibly changing subset of these (called identical attributes), the collection only accepts item lists where the chosen attributes of all items are identical.
The class provides getters for all identical attributes
The class must not be usable in any other way than the intended way.
If not for point 1 I would use a generic base class that is either parametrized (ie you tell it upon instantiation which is the set of identical attributes) or uses multiple inheritance (or in php traits) to compose arbitrary combinations with the needed interfaces. Children might rely on the base class but use a predefined subset of the identical attributes.
The parametrized variant might look something as follows:
class BookCollection {
public function __construct($book_list, $identical_fields=array())
{
if (empty($book_list))
{
throw new EmptyCollectionException("Empty book list");
}
$default = $book_list[0];
$this->ia = array();
foreach($identical_fields as $f)
{
$this->ia[$f] = $default->$f;
}
foreach($book_list as $book)
{
foreach($identical_fields as $f)
{
if ($this->ia[$f] !== $book->$f)
{
throw new NotIdenticalFieldException("Field $f is not identical for all");
}
}
}
$this->book_list = $book_list;
}
public function getIdentical($key)
{
$this->ia[$key];
}
}
final class BC_by_Author extends BookCollection{
public function __construct($book_list)
{
parent::__construct($book_list,array('author'));
}
public function getAuthor(){ $this->ia['author']; }
}
or fooling around with abstract and final types (not sure if it's valid like this)
abstract class BookCollection{
public final function __construct($book_list){...}
abstract public function getIdenticalAttributes();
}
final class BC_by_Author {
public function getIdenticalAttributes(){ return array('author'); }
public function getAuthor(){ return $this->ia['author']; }
}
If you rely on getters that do not necessarily match the field names I would go for multiple inheritance/traits.
The naming then would be something like BC_Field1Field2Field3.
Alternatively or additionally, you could also use exactly the same classname but develop your solutions in different namespaces, which would mean you wouldn't have to change your code when you change the namespace, plus you can keep it short in the controllers.
But because there will only ever be one class, I would name it BookCollection and not unnecessarily discuss it any further.
Because of constraint 4, the white box constraint, the given book list must be validated by the class itself, ie in the constructor.
I have a base class where all common functions are written. I many classes which override this functions by virtual keyword. Like,
public class Base
{
public virtual void sample()
{
..............
}
}
public class a : Base
{
public override sample()
{
}
}
public class implement
{
public void ToSample()
{
Base baseclass = new Base();
Switch(test)
{
case a: baseclass = a();
break;
case b: baseclass = b();
break;
}
baseclass.sample();
}
}
This perfect code for current situation but now I have more class to be assign in switch case. It is not good practice for adding huge amount of cases so I want something that automatically assign child class.
Is anybody know something to be implement ?
As stated in the comment, you can decouple the implementation by using dependency injection. Note however, that in some cases you have no choice but doing that kind of switch (e.g. when you need to create a class based on a text received in a socket). In such cases the important thing is to always keep the switch statement encapsulated in one method and make your objects rely on it (or, in other words, don't copy-and-paste it everywhere :)). The idea here is too keep your system isolated from a potentially harmful code. Of course that if you add a new class you will have to go and modify that method, however you will only have to do it in one time and in one specific place.
Another approach that I have seen (and sometimes used) is to build a mapping between values an classes. So, if your class-creation switch depends on an integer code, you basically create a mapping between codes and classes. What you are doing here is turning a "static" switch into a dynamic behavior, since you can change the mappings contents at any time and thus alter the way your program behaves. A typical implementation would be something like (sorry for the pseudocode, I'm not familiar with C#):
public class implement
{
public void ToSample()
{
class = this.mapping.valueForKey(test);
Base baseclass = new class();
baseclass.sample();
}
}
Note however that for this example to work you need reflection support, which varies according to the language you are using (again, sorry but I don't know the C# specifics).
Finally, you can also check the creational family of patterns for inspiration regarding object creation issues and some well known forms of solving them.
HTH
A common red flag that an OOP language is not being leveraged properly looks like this:
if (typeof(x) == T1)
{
DoSomethingWithT1(x);
}
else if (typeof(x) == T2)
{
DoSomethingWithT2(x);
}
The standard "fix" for such design issues is to make T1 and T2 both share an interface, either through inheritance of a base type or implementation of a common interface (in languages that support it); for example, in C# a solution might be:
public interface IT
{
void DoSomething();
}
However, sometimes you want to implement functionality that differs based on the type of an object but that functionality does not belong within that object's type; thus polymorphism seems the wrong way to go.
For example, consider the case of a UI that provides a view of a given clump of data. Supposing this view is capable of rendering various layouts and controls depending on the type of data being presented, how would you implement this type-specific rendering without a bunch of if/else statements?
For reasons that I hope are obvious, putting the rendering logic in the type itself strikes me as a very bad decision in this case. On the other hand, without coupling the type of data object to its visual presentation I have a hard time seeing how the if/else scenario is avoided.
Here's a concrete example: I work on a trading application which utilizes many different pricing models for various market products. These different models are represented by types inheriting from a common PricingModel base; and each type is associated with a completely different set of parameters. When the user wants to view the parameters for a particular pricing model (for a particular product), currently these are displayed by a form which detects the type of the model and displays an appropriate set of controls. My question is how this could be implemented more elegantly than it is currently (with a big if/else block).
I realize this probably seems like a very basic question; it's just one of those gaps in my knowledge (of solid OOP principles? design patterns? common sense?) that I figured it's about time to fix.
We are injecting (Spring.Net) such functionality into dictionaries by type.
IDictionary<Type, IBlahImplementor> blahImplementors;
blahImplementors[thingy.GetType()].Do(thingy);
This dictionary could be managed by a kind of repository which provides the functionality.
As an implementation detail, the implementor usually knows the type it depends on an can provide it itself:
interface IBlahImplementor
{
Type ForType { get; }
void Do(object thingy);
}
Then it is added to the dictionary like this:
IEnumerably<IBlahImplementor> blahImplementors;
foreach (var implementor in blahImplementors)
{
blahImplementors.Add(implementor.ForType, implementor);
}
Remark: IMHO, it is very important to understand that some things do NOT belong into a class, even if providing subtype-specific implementations would make life much easier.
Edit: Finally understood your concrete example.
It is actually about instancing the right UI control to show the pricing models parameters. It should be possible with the pattern I described above. If you don't have a single UI control for a pricing model, you either create it or you write a UI configurer or something like this which sets up the required controls.
interface IPricingModelUiConfigurer
{
Type PricingModelType { get; }
void SetupUi(Control parent, IPricingModel model);
}
you can use common interface approach as you describe and Command pattern to trigger methods with "functionality does not belong within that object's type". I think this won't break solid OOP principles.
What you described is pretty much exactly the use case for the Visitor Pattern.
EDIT: For your concrete example, you could apply the visitor pattern like this:
// interface used to add external functionality to pricing models
public interface PricingModelVisitor {
void visitPricingModel1(PricingModel1 m);
void visitPricingModel2(PricingModel2 m);
...
}
// your existing base-class, with added abstract accept() method to accept a visitor
public abstract class PricingModelBase {
public abstract void accept(PricingModelVisitor v);
...
}
// concrete implementations of the PricingModelBase implement accept() by calling the
// appropriate method on the visitor, passing themselves as the argument
public class PricingModel1 : PricingModelBase {
public void accept(PricingModelVisitor v) { v.visitPricingModel1(this); }
...
}
public class PricingModel2 : PricingModel {
public void accept(PricingModelVisitor v) { v.visitPricingModel2(this); }
...
}
// concrete implementation of the visitor interface, in this case with the new
// functionality of adding the appropriate controls to a parent control
public class ParameterGuiVisitor : PricingModelVisitor {
private Control _parent;
public ParameterGuiVisitor(Control parent) { _parent = parent; }
visitPricingModel1(PricingModel1 m) {
// add controls to _parent for PricingModel1
}
visitPricingModel2(PricingModel2 m) {
// add controls to _parent for PricingModel1
}
}
now, instead of using a big if-else block when you need to display the edit-controls for the parameters of a specific subtype of PricingModelVisitor, you can simply call
somePricingModel.accept(new ParameterGuiVisitor(parentControl))
and it will populate the appropriate GUI for you.