locked
ways to Pattern choose RRS feed

  • Question

  • User-1012273157 posted

    Hello everyone.

    I am learning design patterns now and started with adapter pattern. So as per my understanding adapeter patterns uses to interface incompatible types.

    1. As an example, i have SQL and Oracle as the backend. So some customer needs oracle and some needs sql. Here for sql we need sql client and the methods and for oracle different. For client i can give common interface and class called adpater so that client don't need to know the specfic implementation. Is my understanding right?

    Kindly clarify me if i am wrong.

    2. If my point is right i have one confusion like thinking of opposite scneario. I have common db as SQL. For data collection i have seperate custom scenarios for each client like for one client i interface hardware with serial port and another with excel import and another direct entry. But all these data will enetred in same table and i have SQL database only. Here which pattern help me to commonize the code? Or i use like layered approach. (Example Raw methods as hosted in wcf and the the client pages as custom for each one?

    Can anyone clarify me this scenarios so that i can have the clarity.

    Wednesday, October 29, 2014 3:22 AM

All replies

  • User-1611549905 posted

    In theory, that's exactly how the Adapter pattern works. You have two or more technologies where you want to swap out one for another, so you create a common interface that exposes the functionality that you need that's common to both of them.

    However, in practice, creating an Adapter can be complex. You have to take into account not just structural differences between the two implementations but behavioural differences as well, and some of these can be quite subtle. You need to build and test all the implementations that you're trying to make interchangeable right from the word go, otherwise you'll end up building assumptions into your system that apply to one but not the other, and that can cause no end of problems. For the same reason, you shouldn't attempt to use the Adapter pattern when you only have one implementation: some people try to do this "just in case" they need to swap the implementation out for something else, but it never works in practice and just over-complicates your code.

    Data access is probably about as complex an example as you can possibly get. You can swap between different RDBMSs (e.g.e SQL Server, Oracle, MySQL, Postgresql, SQLite) using an O/R mapper, but if you're going to try and make it swappable with any other kind of data source (a NoSQL database, a web service etc) it's going to be a massive task, because they have different performance characteristics, different workflows for allocating primary keys, different ways of handling concurrency and transactions, different approaches to querying, and many, many other concerns.

    In general, the most important thing you need to learn about design patterns is that they should be used sparingly. It's a common beginner mistake to implement design patterns left, right and centre, which can result in over-complex code. Experiment with them on hobby projects first and make sure you understand them properly before you roll them out onto production code.

    Also read the series of posts by Oren Eini (Ayende Rahien) entitled "Design patterns in the test of time" -- it gives you some idea of which design patterns are most worth learning and common pitfalls that many people fall into.

    Wednesday, October 29, 2014 5:49 AM
  • User71929859 posted

    hangxanh

    I am learning design patterns now and started with adapter pattern. So as per my understanding adapeter patterns uses to interface incompatible types.

    Correct.

    hangxanh

    1. As an example, i have SQL and Oracle as the backend. So some customer needs oracle and some needs sql. Here for sql we need sql client and the methods and for oracle different. For client i can give common interface and class called adpater so that client don't need to know the specfic implementation. Is my understanding right?

    Correct. Infact, the ADO.NET adapters (SqlDataAdapter, OledbDataAdapter, OdbcDataAdapter, OracleDataAdapter) are using the adapter pattern.

    hangxanh

    For data collection i have seperate custom scenarios for each client like for one client i interface hardware with serial port and another with excel import and another direct entry.

    If I understood your problem correctly, In my opinion, you can use Adapter pattern here. In your scenario, your adaptees would be the data entered through hardware with serial port, excel import and direct entry, If you already have codes for collecting data then you can use Facade design pattern I think.

    Thursday, October 30, 2014 2:25 AM