locked
Design Pattern Question RRS feed

  • Question

  • User1304912589 posted

    I am new to design patterns. While I plan to learn as many patterns as I can, I currently have an immediate need that I must fullfill.  My data access layer writes to two different sources of data, one is SQL Server and the other is a legacy flat file database.  Sometimes I need to write to only the Sql Server database and sometimes I need to write to both the Sql Server database and the Legacy database.

    Given the following fictious example I have three classes:

    1. Customer - which is nothing but an entity class
    2. CustomerSqlServer - which has a Save method with the following signature Save(Customer c)
    3. CustomerLegacy - which has a Save method with the following signature Save(Customer c)

    My boss suggests that I code the system by always calling the Save method on the CustomerSqlServer class and then use an if statement to determine whether or not to call the Save method on the CustomerLegacy class. 

    I don't want to do this especially because at some point in the future the Legacy system is going away.  Once the legacy system goes away I don't want to have to find and remove each of the 'if' statements or make sure that if I decide to leave the 'if' statements, that they always return false. Ideally I don't want the code that calls the CustomerSqlServer to even know about the CustomerLegacy class.

    I assume that there is a better way to do this.  Is there a pattern or patterns that I could use to solve this?  If so, what are they so I can study them sooner rather then later. If there is not a pattern that I could use, is there a way that I can accomplish what I need without the 'if' statements?

    Thanks

    Thursday, February 4, 2010 1:30 PM

Answers

  • User8761146 posted

    I recommend u to try using State pattern. It's easy and works fine.

    Just search for "State pattern" and you'll have decision in 15 minutes)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, February 4, 2010 3:51 PM
  • User-952121411 posted

    You could try to use the GOF State Pattern as recommended in the previous post.  But before getting into the specifics of that pattern, read this statement that summarizes well when to apply a design pattern to a problem:

    A Word of Caution

    It is agreed that design patterns can solve complexities and problems in software design phases, but improper applicability of Design Patterns can lead to bad designs that can facilitate software design errors. Be very careful when using or applying design patterns. Do not use a pattern to solve a problem that does not need it. Do not simply ornament software design using a design pattern when it is not at all required in that context. Think twice before you decide to use them in your design. Understand the scope of the problem context and then search for a design pattern that best fits in that context to solve the problem. Further, one should have an excellent understanding of the scope and applicability of each design pattern before using it. Analyze the problem carefully, consider all options and apply the appropriate design pattern to solve the problem. What I personally feel is that we should only implement a design pattern in our software design provided we have sufficient knowledge of its applicability and scope. At the same time, we should be able to analyze the problem context and judge the applicability of the correct design pattern (if it is required at all) as a solution to the problem in question. It is quite unnecessary and not wanted of a software architect to implement a design pattern in a problem domain and increase complexity when it can be solved without using one.   http://www.dotnetjohn.com/articles.aspx?articleid=272

    In a nutshell... don't go applying elaborate design patterns to a small scale problem if you can find another simpler solution to the problem.  I agree in your situation a bunch of If-Else statements are not the solution, but you may be able to find a nice middle ground.  One way is just to expose a property set possibly through the class constructor when instantiated that could be monitored and decide which method to call.  You could expose only one .Save() method, but then internally based on the parameter value determine which .Save internally to call.  Then if the flat file method every needed to go away, you could modify the centralized logic to handle accordingly.

    The interesting thing about the state pattern is you may still end up using If-Else statements or implied logic to determine the state of the object and which concrete class to implement.  The nice thinking however about this pattern is it would greatly reduce the amount of logic checking you would need to do and could centralize the branching of logic to a single location.  A decent article on implementing the State Pattern and real world simple to follow example can be found here:

    State Design Pattern in C# and VB.NET.:

    http://www.dofactory.com/Patterns/PatternState.aspx

    Another option could be to use the Factory Method and based on the parameters passed to the factory you could internally decide the outcome of the object the Factory returns:

    Factory Method Design Pattern in C# and VB.NET.:

    http://www.dofactory.com/Patterns/PatternFactory.aspx

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, February 4, 2010 5:11 PM

All replies

  • User8761146 posted

    I recommend u to try using State pattern. It's easy and works fine.

    Just search for "State pattern" and you'll have decision in 15 minutes)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, February 4, 2010 3:51 PM
  • User-952121411 posted

    You could try to use the GOF State Pattern as recommended in the previous post.  But before getting into the specifics of that pattern, read this statement that summarizes well when to apply a design pattern to a problem:

    A Word of Caution

    It is agreed that design patterns can solve complexities and problems in software design phases, but improper applicability of Design Patterns can lead to bad designs that can facilitate software design errors. Be very careful when using or applying design patterns. Do not use a pattern to solve a problem that does not need it. Do not simply ornament software design using a design pattern when it is not at all required in that context. Think twice before you decide to use them in your design. Understand the scope of the problem context and then search for a design pattern that best fits in that context to solve the problem. Further, one should have an excellent understanding of the scope and applicability of each design pattern before using it. Analyze the problem carefully, consider all options and apply the appropriate design pattern to solve the problem. What I personally feel is that we should only implement a design pattern in our software design provided we have sufficient knowledge of its applicability and scope. At the same time, we should be able to analyze the problem context and judge the applicability of the correct design pattern (if it is required at all) as a solution to the problem in question. It is quite unnecessary and not wanted of a software architect to implement a design pattern in a problem domain and increase complexity when it can be solved without using one.   http://www.dotnetjohn.com/articles.aspx?articleid=272

    In a nutshell... don't go applying elaborate design patterns to a small scale problem if you can find another simpler solution to the problem.  I agree in your situation a bunch of If-Else statements are not the solution, but you may be able to find a nice middle ground.  One way is just to expose a property set possibly through the class constructor when instantiated that could be monitored and decide which method to call.  You could expose only one .Save() method, but then internally based on the parameter value determine which .Save internally to call.  Then if the flat file method every needed to go away, you could modify the centralized logic to handle accordingly.

    The interesting thing about the state pattern is you may still end up using If-Else statements or implied logic to determine the state of the object and which concrete class to implement.  The nice thinking however about this pattern is it would greatly reduce the amount of logic checking you would need to do and could centralize the branching of logic to a single location.  A decent article on implementing the State Pattern and real world simple to follow example can be found here:

    State Design Pattern in C# and VB.NET.:

    http://www.dofactory.com/Patterns/PatternState.aspx

    Another option could be to use the Factory Method and based on the parameters passed to the factory you could internally decide the outcome of the object the Factory returns:

    Factory Method Design Pattern in C# and VB.NET.:

    http://www.dofactory.com/Patterns/PatternFactory.aspx

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, February 4, 2010 5:11 PM
  • User1304912589 posted

     I will definitely look into the state pattern. I might have come up with my own solution that I would like to get your opinion of.

    1. Have the CustomerLegacy class inherit from the CustomerSqlServer
    2. Have the CustomerLegacy class first call base.Save(customer)
    3. Have the CustomerLegacy class call its own Save(customer) method
    4. Create a Factory class that returns either a CustomerSqlServer object or a CustomerLegacy object.

    I could then do the following:

    CustomerSqlServer dal = CustomerFactory.Create();

    dal.Save(customer);

    If the Factory returns a CustomerLegacy object, the CustomerSqlServer.Save and the CustomerLegacy.Save will be invoked. If the factory returns a CustomerSqlServer only the CustomerSqlServer.Save will be invoked.

    This means that when the legacy system goes away I will only have to change the CustomerFactory class.

    Does this make sense?  Is it a better solution then using the state pattern?

    Thanks so much

     

     

     

     

    Friday, February 5, 2010 8:19 AM
  • User-952121411 posted

    If the Factory returns a CustomerLegacy object, the CustomerSqlServer.Save and the CustomerLegacy.Save will be invoked. If the factory returns a CustomerSqlServer only the CustomerSqlServer.Save will be invoked.

    This means that when the legacy system goes away I will only have to change the CustomerFactory class.

    Does this make sense?  Is it a better solution then using the state pattern?

     

    Yes it does and it was something I eluded to in the 2nd half of my previous post.  The Factory Method is a good way to make it seamingless to which concrete class was created, and for your case this should work well.  The State pattern is just another way to accomplish what you needed to do, but I think the architecture you detailed should be fine.

    Friday, February 5, 2010 8:53 AM
  • User1304912589 posted

    If the Factory returns a CustomerLegacy object, the CustomerSqlServer.Save and the CustomerLegacy.Save will be invoked. If the factory returns a CustomerSqlServer only the CustomerSqlServer.Save will be invoked.

    This means that when the legacy system goes away I will only have to change the CustomerFactory class.

    Does this make sense?  Is it a better solution then using the state pattern?

     

    Yes it does and it was something I eluded to in the 2nd half of my previous post.  The Factory Method is a good way to make it seamingless to which concrete class was created, and for your case this should work well.  The State pattern is just another way to accomplish what you needed to do, but I think the architecture you detailed should be fine.

     

    Thanks so much.  I will still check into the state pattern just to get a better understanding of it.  I will however take your advice and use the method that I detailed.

     

    Friday, February 5, 2010 9:32 AM