Normally when declare a class
type data member in class or when we pass parameters to a method, we assume
only one possible use case of this. That is this class need some DATA it is
managed like this i.e. by parameter or by declaring it as the data member. We
completely ignore the BEHAVIOURAL part of the object. These object are not only
the DATA CONTAINERS but they carry BAHAVIOUR as well. For example we can do
following things with an object other then DATA
1.
Receiver object can call the methods of passed object.
2.
Receiver object can send method of passed object
as parameter it own method or to any other object
3.
Receiver object itself can subscribe one or more
events of passed object and attach its event handlers to them.
4.
Receiver object can make other objects to
subscribe one or more events of passed and attach their event handlers them.
5.
Receiver object can raise one or more events of
passed object and cause functionality to be executed in all its subscribers.
6.
Passed object can consume receiver’s method as parameter to its
own method or it can be passed to any other object’s method as parameter
7.
Passed object can subscribe one or more events
of the receiver and attach its events handlers to it.
8.
There can be a complete Zig-Zag between the
Passed object and Receiver object. Receiver already has the reference of the
Passed object, Passed object know about the Receiver by using the THIS keyword.
9.
There is always a Main program or Startup module
that composes the object graph properly and wires the events among the object
and inject the dependencies. The resultant object graph is the SOFTWARE that
exhibit the required functionality or behavior. This object graph can be
expanded by the lazy load technique. The entire object graph should not eager
loaded at the startup. It makes the bulky application that takes too many
spaces in memory. Also not needed functionality should be eliminated from the
object graph.
10.
If an object implements 5 interfaces, then it
means that object has 5 different VIEWS or WINDOWS by which its data and
functionality can be exposed. Or we can say, object has 5 faces or face-lets by
which it can expose its functionality. This is the one use of interface.
Implementing the interface means, object can be seen like that. We can hide the
show the particular sub set of data and functionality by using a particular
Interface.
11.
Provider pattern and Adapter pattern are same,
as they adapt the different data sources APIs to be used uniformly for .NET
applications. .NET provider for SQL server adapts the SQL server APIs to be
used uniformly across the .NET applications. .NET provider for Oracle adapts
the Oracle APIs to use uniformly for .NET application. Adapter seems to be a
small concept like a class. But in case of provider, this adapter grows to full
blown API or Library, therefore these are called Providers. They provide access
to the particular data source.
12.
Ideally, the upper layer should depend upon the
interface of lower layer, so that the upper layer can be unit tested by mocking
the lower layer and provide the dummy functionality. If it is not, then we are
forced to provide the PRODUCTION lower layer. If by any means this PRODUCTION
lower layer is not available, or it is not possible to provide that, then we
can test the upper layers. For example Payment gateways cannot be test in real. Credit card transactions
cannot be tested in real. We may not be provided by a SMTP server while testing. Enterprise
application has many dependencies on the outer world. While in the test we are
not available with those dependencies or it is not feasible to do so. Cause
update in the external
Database or any other department but we do not have that Database for
our application. External
service is down or it is under development. Or external service is
secures and it could only be used in PRODUCTION scenario. Calling service is
not feasible in testing environment. Enterprise service bus cannot be used in Testing Environment and
we are not available with Testing ESB.
13.
Repository pattern expose the underlying data
source as the in-memory collection and relieves the business logic layer form
the underlying details of data source. Along with Unit of work design pattern relieves
business logic layer and data from the headache of Transactions, Locking, and
Conflicting Updates. All things are managed behind the scenes. Different ORM
solutions or Data access Libraries like Linq2Sql, N-Hibernate, ADO.NET Entity
Framework, ADO.NET, and Dynamic Data provide the Unit of work mechanism. But
using these Unit of work in the business logic make our BLL data source
dependent. Do implement the Logical Transactions we need to implement the Unit
of Work on the top of Unit of Work provided by the ORM solution.
14.
If the steps and the control flow of the WORKFLOW
or ALGORITHM are FIXED and DO NOT CHANGE and the underlying details of the
WORKFLOW or ALGORITHM vary and implemented by the developer then this
functionality is implemented by Template Method Pattern.
15.
At runtime, behavior can be added to an object,
by Strategy Pattern. Composition based solution, delegate behavior to
dynamically added objects. We have A, B and C type of behaviors and further we
have A1, A2 and A3 type of behaviors. In the same type B1, B2 and B3.
16.
If we have object composition like the stack or
like the onion, and functionality is hieratical, then decorator pattern is
used. For example, Form composed of may buttons, Data grid compose of many
components.
17.
CASE 1: (Client application has upper hand) (We are coding the client
application and we want to reuse the existing legacy or incompatible API or
Library) Adapter or wrapper is a class that wraps a legacy or
incompatible API or Library and exposes that API or Library in an interface
that the client code expects. Adapt the API or Library in a way so that it
could be used by client. CASE
2: (API or Library application has upper hand) (We are coding the API or
Library and we want it to be reused by all future expected clients)
Adapter or wrapper interface is exposed by the API or Library; all interested
clients implement that interface exposed in order to use that API or Library.
