OOPS Concepts in C# part .1
Hi frds am gathered some material from net.
Hope this will use for u.
What is Software Architecture?
Software Architecture is defined to be the rules,
heuristics and patterns governing:
·
Partitioning the problem and the system to be built into
discrete pieces
·
Techniques used to create interfaces between these pieces
·
Techniques used to manage overall structure and flow
·
Techniques used to interface the system to its environment
·
Appropriate use of development and delivery approaches,
techniques and tools.
Why Architecture is important?

The primary goal of software architecture is to
define the non-functional requirements of a system and define the environment.
The detailed design is followed by a definition of how to deliver the
functional behavior within the architectural rules. Architecture is important
because it:
·
Controls complexity
·
Enforces best practices
·
Gives consistency and uniformity
·
Increases predictability
·
Enables re-use.
What is OOP?
OOP is a design philosophy. It stands
for Object Oriented Programming. Object-Oriented Programming (OOP) uses a different set of
programming languages than old procedural programming languages (C, Pascal, etc.). Everything in OOP is grouped as self sustainable
"objects". Hence,
you gain re-usability by means of four main object-oriented programming concepts.
In order to clearly understand the
object orientation, let’s take your “hand”
as an example. The “hand” is
a class. Your body has two objects of type hand, named left hand and right
hand. Their main functions are controlled/ managed by a set of electrical
signals sent through your shoulders (through an interface). So the shoulder is
an interface which your body uses to interact with your hands. The hand is a
well architected class. The hand is being re-used to create the left hand and
the right hand by slightly changing the properties of it.
What is an Object?
An object can be considered a "thing" that can perform a set of related activities. The set of
activities that the object performs defines the object's behavior. For example,
the hand can grip something or a Student (object) can give the name or address.
In pure OOP terms an object is an instance of a
class.
What is a Class?

A class is
simply a representation of a type of object.
It is the blueprint/ plan/ template that describe the details of an object. A class is the blueprint from
which the individual objects are created. Class
is composed of three things: a name, attributes, and operations.

public class Student
{
}
According to the sample given below we can say that
the student object, named objectStudent, has created out of the Student class.

Student objectStudent = new Student();
What is Encapsulation (or information hiding)?
The encapsulation is the inclusion within a program
object of all the resources need for the object to function - basically, the
methods and the data. In OOP the
encapsulation is mainly achieved by creating classes, the classes expose public
methods and properties. The class is kind of a container or capsule or a cell,
which encapsulate the set of methods, attribute and properties to provide its
indented functionalities to other classes. In that sense, encapsulation also
allows a class to change its internal implementation without hurting the
overall functioning of the system. That idea of encapsulation is to hide how a
class does it but to allow requesting what to do.

What is the difference between Association, Aggregation and Composition?
Association is a (*a*) relationship between two classes, where one class
use another. But aggregation describes a special type of an association.
Aggregation is the (*the*)
relationship between two classes. When object of one class has an (*has*) object of another, if second
is a part of first (containment relationship) then we called that there is an aggregation
between two classes. Unlike association, aggregation always insists a
direction.

public class University
{
private Chancellor universityChancellor = new Chancellor();
}

In
this case I can say that University aggregate
Chancellor or University has an (*has-a*) Chancellor. But even without a Chancellor a University
can exists. But the Faculties
cannot exist without the University,
the life time of a Faculty (or
Faculties) attached with the life time of the University . If University
is disposed the Faculties will
not exist. In that case we called that University
is composed of Faculties.
So that composition can be recognized as a special type of an aggregation.
What is an Abstract class?
Abstract classes, which declared with the abstract
keyword, cannot be instantiated. It can only be used as a super-class for other
classes that extend the abstract class. Abstract class is the concept and
implementation gets completed when it is being realized by a subclass. In
addition to this a class can inherit only from one abstract class (but a class
may implement many interfaces) and must override all its abstract methods/
properties and may override virtual methods/ properties.
Abstract classes are ideal when
implementing frameworks. As an example, let’s study the abstract class named LoggerBase below. Please carefully read
the comments as it will help you to understand the reasoning behind this code.
What is an Interface?
In summary the Interface separates the
implementation and defines the structure, and this concept is very useful in
cases where you need the implementation to be interchangeable. Apart from that
an interface is very useful when the implementation changes frequently. Some
say you should define all classes in terms of interfaces, but I think
recommendation seems a bit extreme.
Interface can be used to define a
generic template and then one or more abstract classes to define partial
implementations of the interface. Interfaces just specify the method
declaration (implicitly public and abstract) and can contain properties (which
are also implicitly public and abstract). Interface definition begins with the
keyword interface. An interface like that of an abstract class cannot be
instantiated.
If a class that implements an
interface does not define all the methods of the interface, then it must be
declared abstract and the method definitions must be provided by the subclass
that extends the abstract class. In addition to this an interfaces can inherit
other interfaces.
What is the difference between a Class and an Interface?
In .Net/ C# a class
can be defined to implement an interface
and also it supports multiple implementations. When a class implements an interface, an object of such class can be encapsulated inside an interface.
If MyLogger is a class, which implements ILogger, there we can write

ILogger log = new MyLogger();
A
class and an interface are two different types
(conceptually). Theoretically a class emphasis
the idea of encapsulation, while an interface
emphasis the idea of abstraction (by suppressing the details of the
implementation). The two poses a clear separation from one to another.
Therefore it is very difficult or rather impossible to have an effective
meaningful comparison between the two, but it is very useful and also
meaningful to have a comparison between an interface and an abstract class.
What is the difference between an Interface and an Abstract class?
There are quite a big difference
between an interface and an abstract class, even though both look
similar.
o
Interface definition begins with a keyword interface so it
is of type interface
o
Abstract classes are declared with the abstract keyword so
it is of type class
o
Interface has no implementation, but they have to be
implemented.
o
Abstract class’s methods can have implementations and they
have to be extended.
o
Interfaces can only have method declaration (implicitly
public and abstract) and fields (implicitly public static)
o
Abstract class’s methods can’t have implementation only
when declared abstract.
o
Interface can inherit more than one interfaces
o
Abstract class can implement more than one interfaces, but
can inherit only one class
o
Abstract class must override all abstract method and may
override virtual methods
o
Interface can be used when the implementation is changing
o
Abstract class can be used to provide some default
behavior for a base class.
o
Interface makes implementation interchangeable
o
Interface increase security by hiding the implementation
o
Abstract class can be used when implementing framework
o
Abstract classes are an excellent way to create planned
inheritance hierarchies and also to use as non-leaf classes in class
hierarchies.
What is Implicit and Explicit Interface Implementations?
As mentioned before .Net support
multiple implementations, the concept of implicit and explicit implementation
provide safe way to implement methods of multiple interfaces by hiding,
exposing or preserving identities of each of interface methods, even when the
method signatures are the same.
Let's consider the interfaces
defined below.

interface IDisposable
{
void Dispose();
}
Here you can see that the class Student has implicitly and explicitly
implemented the method named Dispose() via
Dispose and IDisposable.Dispose.

class Student : IDisposable
{
public void Dispose()
{
Console.WriteLine("Student.Dispose");
}
void IDisposable.Dispose()
{
Console.WriteLine("IDisposable.Dispose");
}
}
What is a Use case?
A use case is a thing an actor
perceives from the system. A use case maps actors with functions. Importantly,
the actors need not be people. As an example a system can perform the role of
an actor, when it communicate with another system.

In another angle a use case encodes a typical user
interaction with the system. In particular, it:
·
Captures some user-visible function.
·
Achieves some concrete goal for the user.
A
complete set of use cases largely defines the requirements for your system:
everything the user can see, and would like to do. The below diagram contains a
set of use cases that describes a simple login module of a gaming website.
What is a Class Diagram?
A class diagrams are widely used
to describe the types of objects in a system and their relationships. Class
diagrams model class structure and contents using design elements such as
classes, packages and objects. Class diagrams describe three different
perspectives when designing a system, conceptual, specification, and
implementation. These perspectives become evident as the diagram is created and
help solidify the design.
The Class diagrams, physical data
models, along with the system overview diagram are in my opinion the most
important diagrams that suite the current day rapid application development
requirements.
UML Notations:

What is a Package Diagram?
Package diagrams are used to reflect the
organization of packages and their elements. When used to represent class
elements, package diagrams provide a visualization of the name-spaces. In my
designs, I use the package diagrams to organize classes in to different modules
of the system.
What is a Sequence Diagram?
A sequence diagrams model the flow of logic within
a system in a visual manner, it enable both to document and validate your
logic, and are used for both analysis and design purposes. Sequence diagrams are
the most popular UML artifact for dynamic modeling, which focuses on
identifying the behavior within your system.
What is two-tier architecture?
The two-tier architecture is refers to client/
server architectures as well, the term client/ server was first used in the
1980s in reference to personal computers (PCs) on a network. The actual client/
server model started gaining acceptance in the late 1980s, and later it was
adapted to World Wide Web programming.
According to the modern days use
of two-tier architecture the user interfaces (or with ASP.NET, all web pages)
runs on the client and the database is stored on the server. The actual
application logic can run on either the client or the server. So in this case
the user interfaces are directly access the database. Those can also be
non-interface processing engines, which provide solutions to other remote/
local systems. In either case, today the two-tier model is not as reputed as
the three-tier model. The advantage of the two-tier design is its simplicity,
but the simplicity comes with the cost of scalability. The newer three-tier
architecture, which is more famous, introduces a middle tier for the
application logic.

What is three-tier architecture?
The three tier software architecture (also known as
three layer architectures) emerged in the 1990s to overcome the limitations of
the two tier architecture. This architecture has aggressively customized and
adopted by modern day system designer to web systems.
Three-tier is a client-server
architecture in which the user interface, functional process logic, data
storage and data access are developed and maintained as independent modules,
some time on separate platforms. The term "three-tier" or "three-layer", as well as the concept of multi-tier
architectures (often refers to as three-tier architecture), seems to have
originated within Rational Software.

The 3-Tier architecture has the following three
tiers.
- Presentation Tier or Web Server: User Interface, displaying/ accepting data/ input to/ from the user
- Application Logic/ Business Logic/ Transaction Tier or Application Server: Data validation, acceptability check before being added to the database and all other business/ application specific operations
- Data Tier or Database server: Simple reading and writing method to database or any other storage, connection, command, stored procedures etc
What is MVC architecture?
The Model-View-Controller (MVC) architecture separates the
modeling of the domain, the presentation, and the actions based on user input
into three separate classes.
Unfortunately, the popularity of
this pattern has resulted in a number of faulty usages; each technology (Java, ASP.NET etc) has defined it in their own way making it
difficult to understand. In particular, the term "controller" has
been used to mean different things in different contexts. The definitions given
bellow are the closes possible ones I found for ASP.NET version of MVC.

- Model: DataSet and typed DataSet (some times business object, object collection, XML etc) are the most common use of the model.
- View: The ASPX and ASCX files generally handle the responsibilities of the view.
- Controllers: The handling of events or the controlling is usually done in the code-behind class.
In a complex n-tier distributed system the MVC architecture place the vital role
of organizing the presentation tier of the system.
What is SOA?
A service-oriented architecture is essentially a
collection of services. These services communicate with each other. The
communication can involve either simple data passing or it could involve two or
more services coordinating some activity. Some means of connecting services to
each other is needed.
The .Net technology introduces the
SOA by mean of web services.

The SOA can be used as the concept
to connect multiple systems to provide services. It has it's great share in the
future of the IT world.
According to the imaginary diagram
above, we can see how the Service Oriented Architecture is being used to
provide a set of centralized services to the citizens of a country. The citizens
are given a unique identifying card, where that card carries all personal
information of each citizen. Each service centers such as shopping complex,
hospital, station, and factory are equipped with a computer system where that
system is connected to a central server, which is responsible of providing
service to a city. As an example when a customer enter the shopping complex the
regional computer system report it to the central server and obtain information
about the customer before providing access to the premises. The system welcomes
the customer. The customer finished the shopping and then by the time he leaves
the shopping complex, he will be asked to go through a billing process, where
the regional computer system will manage the process. The payment will be
automatically handled with the input details obtain from the customer
identifying card.
The regional system will report to
the city (computer system of the city) while the city will report to the
country (computer system of the country).
What is the Data Access Layer?
The data access layer (DAL), which is a key part of
every n-tier system, is mainly consist of a simple set of code that does basic
interactions with the database or any other storage device. These
functionalities are often referred to as CRUD (Create, Retrieve, Update, and
Delete).
The data access layer need to be
generic, simple, quick and efficient as much as possible. It should not include
complex application/ business logics.
I have seen systems with lengthy,
complex store procedures (SP), which run through several cases before doing a
simple retrieval. They contain not only most part of the business logic, but
application logic and user interface logic as well. If SP is getting longer and
complicated, then it is a good indication that you are burring your business
logic inside the data access layer.
What is the Business Logic Layer?
I know for a fact that this is a question for most,
but from the other hand by reading many articles I have become aware that not
everyone agrees to what business logic actually is, and in many cases it's just
the bridge in between the presentation layer and the data access layer with
having nothing much, except taking from one and passing to the other. In some
other cases, it is not even been well thought out, they just take the leftovers
from the presentation layer and the data access layer then put them in another
layer which automatically is called the business logic layer. However there are
no god said things that cannot be changed in software world. You can change as
and when you feel comfortable that the method you apply is flexible enough to
support the growth of your system. There are many great ways, but be careful
when selecting them, they can over complicating the simple system. It is a balance
one needs to find with their experience.
As a general advice when you
define business entities, you must decide how to map the data in your tables to
correctly defined business entities. The business entities should meaningfully
define considering various types of requirements and functioning of your
system. It is recommended to identify the business entities to encapsulate the
functional/ UI (User Interface) requirements of your application, rather than
define a separate business entity for each table of your database. For example,
if you want to combine data from couple of table to build a UI (User Interface)
control (Web Control), implement that function in the Business Logic Layer with
a business object that uses couple of data object to support with your complex
business requirement.
What is Gang of Four (GoF) Design Patterns?
The Gang of Four (GoF) patterns are generally
considered the foundation for all other patterns. They are categorized in three
groups: Creational, Structural, and Behavioral. Here you will find information
on these important patterns.
Creational Patterns
o
Abstract Factory Creates an instance of several families
of classes
o
Builder Separates object construction from its
representation
o
Factory Method Creates an instance of several derived
classes
o
Prototype A fully initialized instance to be copied or
cloned
o
Singleton A class of which only a single instance can
exist
Structural Patterns
o
Adapter Match interfaces of different classes
o
Bridge Separates an object’s interface from its
implementation
o
Composite A tree structure of simple and composite objects
o
Decorator Add responsibilities to objects dynamically
o
Facade A single class that represents an entire subsystem
o
Flyweight A fine-grained instance used for efficient
sharing
o
Proxy An object representing another object
Behavioral Patterns
o
Chain of Resp. A way of passing a request between a chain
of objects
o
Command Encapsulate a command request as an object
o
Interpreter A way to include language elements in a
program
o
Iterator Sequentially access the elements of a collection
o
Mediator Defines simplified communication between classes
o
Memento Capture and restore an object's internal state
o
Observer A way of notifying change to a number of classes
o
State Alter an object's behavior when its state changes
o
Strategy Encapsulates an algorithm inside a class
o
Template Method Defer the exact steps of an algorithm to a
subclass
o
Visitor Defines a new operation to a class without change
What is the difference between Abstract Factory and Builder design patterns?
The two design patterns are
fundamentally different. However, when you learn them for the first time, you
will see a confusing similarity. So that it will make harder for you to
understand them. But if you continue to study eventually, you will get afraid
of design patterns too. It is like infant phobia, once you get afraid at your
early age, it stays with you forever. So the result would be that you never
look back at design patterns again. Let me see whether I can solve this brain
teaser for you.
In the image below, you have both
design pattern listed in. I am trying to compare the two one on one to identify
the similarities. If you observe the figure carefully, you will see an easily
understandable color pattern (same color is used to mark the classes that are
of similar kind).

Please follow up with the numbers
in the image when reading the listing below.
Mark #1: Both patterns have used a
generic class as the entry-class. The only difference is the name of the class.
One pattern has named it as “Client”, while the other named it as “Director”.
Mark #2: Here again the difference is the class name. It is “AbstractFactory” for one and “Builder” for the other. Additionally both classes are of type abstract.
Mark #3: Once again both patterns have defined two generic (WindowsFactory & ConcreteBuilder) classes. They both have created by inheriting their respective abstract class.
Mark #4: Finally, both seem to produce some kind of a generic output.
Mark #2: Here again the difference is the class name. It is “AbstractFactory” for one and “Builder” for the other. Additionally both classes are of type abstract.
Mark #3: Once again both patterns have defined two generic (WindowsFactory & ConcreteBuilder) classes. They both have created by inheriting their respective abstract class.
Mark #4: Finally, both seem to produce some kind of a generic output.
Now, where are we? Aren’t they
looking almost identical? So then why are we having two different patterns
here?
Let’s compare the two again side
by side for one last time, but this time, focusing on the differences.
·
Abstract Factory: Emphasizes a family of product
objects (either simple or complex)
·
Builder: Focuses on constructing a complex object step by step
·
Abstract Factory: Focus on *what* is made
·
Builder: Focus on *how* it is made
·
Abstract Factory: Focus on defining many different
types of *factories* to build many *products*, and it is not a one builder for
just one product
·
Builder: Focus on building a one complex but one single *product*
·
Abstract Factory: Defers the choice of what
concrete type of object to make until run time
·
Builder: Hide the logic/ operation of how to compile that complex
object
·
Abstract Factory: *Every* method call creates and
returns different objects
·
Builder: Only the *last* method call returns the object, while
other calls partially build the object
Sometimes creational patterns are
complementary: So you can join one or many patterns when you design your
system. As an example builder can use one of the other patterns to implement which
components get built or in another case Abstract Factory, Builder, and
Prototype can use Singleton in their implementations. So the conclusion would
be that the two design patterns exist to resolve two type of business problems,
so even though they look similar, they are not.
I hope that this shed some light
to resolve the puzzle. If you still don’t understand it, then this time it is
not you, it has to be me and it is since that I don’t know how to explain it.
Comments