-

1. Enterprise Application
Development
Agile Design Principles- An Overview
C3: Protected

2. © 2007, Cognizant Technology Solutions Confidential 2
About the Author
Created By: T.D Rajeshkumar (111452)
Credential
Information:
Has around 10 yrs of professional experience in developing complex and
critical systems using .NET and Java technologies.
Version and
Date:
Version 1.0

3. © 2007, Cognizant Technology Solutions Confidential 3
Icons Used
Questions
Contacts
Reference
Demonstration
Hands on
Exercise
Coding
Standards
Test Your
Understanding
Tools
A Welcome
Break

4. © 2007, Cognizant Technology Solutions Confidential 4
Enterprise Application Development
 What is Enterprise Development?:
 Enterprise development typically refers to the patterns and practices
adopted by the developers endeavoring to implement the enterprise
architecture.
 The success of the enterprise architecture depends on the ability of the
software systems that best addresses the key areas of system
development Viz.,
 Reliability
 Flexibility
 Separation of concerns
 Reusability
 Maintainability

5. © 2007, Cognizant Technology Solutions Confidential 5
Enterprise Application Development
 Reliability
 Means Breaking the code into modular with few or no dependencies
on the rest of the code. Modularization increases testability, helping to
expose potential bugs and exceptions as the code base augments.
 Flexibility
 Flexibility is the ability to change the code with relative ease. The code
base should allow for changes in isolations, without having ripple
effect in other parts of the system.
 Separation of Concerns
 Separation of concerns is much needed to support Flexibility and
Reliability. Each unit of code should have a single, distinct purpose or
value.

6. © 2007, Cognizant Technology Solutions Confidential 6
Enterprise Application Development
 Reusability
 Separating the code into distinct , flexible units not only increases
reliability and testability but also reusability. The more modular the
code is , the better the chances of being able to reuse the same
functionality is needed elsewhere.
 Maintainability
 Maintainability refers to the capacity of a system to be altered or
modified. It actually means the ease with which a software product can
be modified in order to support
 Stability
 Analyzability
 Changeability
 Testability

7. © 2007, Cognizant Technology Solutions Confidential 7
Enterprise Application Development
 Enterprise development requires more than a cursory
knowledge of academic patterns.
 It requires a change in methodology along with tools ,design
patterns and practices.
 Below are some of the key principles that helps to achieve the
afore said concerns.
 Separation of Concerns (SoC)
 Single Responsibility Principle (SRP).
 Dependency Inversion
 Dependency Injection or Inversion of Control (IoC)

8. © 2007, Cognizant Technology Solutions Confidential 8
Enterprise Application Development
 Separation of Concerns[SoC]
 This principle states that a given problem involves different kinds of
concerns, which should be identified and separated.
 It is the process of dissecting a software and splitting it into discrete
features.
 These distinct features can be used by other classes.
 A Concern represents a feature or behavior of a class.
 By Modularizing the code we can achieve SoC
 Helps in improving the code and manageability of the code.

9. © 2007, Cognizant Technology Solutions Confidential
Enterprise Application Development
 Single Responsibility Principle
 The intent of the principle is ‘A class should have only one reason to
change.
 If there are 2 reasons to change for a class, split the functionality in two
classes.
 Each class will handle only one responsibility /behavior
 If one functionality needs to be changed then change only the class
which has the logic.
 Does not affect other functionalities.
 The Single Responsibility Principle is a simple and intuitive principle,
but in practice it is sometimes hard to get it right.
9

10. © 2007, Cognizant Technology Solutions Confidential
Enterprise Application Development
 Dependency Inversion Principle
 Robert C. Martin describes Dependency Inversion as
“ High level modules should not depend on low level modules. Both should
depend on abstractions
Abstractions should not depend on details. Details should depends on
abstraction”
 This principle is about isolating the classes from the concrete
implementations and have them to depend on abstract classes or
interfaces.
 This principle helps the code to be less fragile and rigid.
10

11. © 2007, Cognizant Technology Solutions Confidential
Enterprise Application Development
 Dependency Injection Principle[DI]
 Dependency Injection refers to the act of supplying an external
dependency to high level module.
 It is also called as Inversion of Control. The concern here is the process
of obtaining lower level classes by higher level classes. This is being
inverted as the high level class just gets them either by Parameters,
Setters or Methods.
11

12. © 2007, Cognizant Technology Solutions Confidential 12
Case Study
E-Sellers Inc is a e-commerce company that has an online
shopping cart application to sell various products.
The current application supports the PayPal payment gateway
for the orders and refunds. Now the company wants to add
another gateway called ‘WorldPay’ for the payments and
refunds.
You have been assigned the task of modifying the refunds
module to include the ‘WorldPay’ gateway.
Below is the class diagram that reflects AS-IS code base.

13. © 2007, Cognizant Technology Solutions Confidential
Case Study- AS-IS Scenario
 Class Diagram
13

14. © 2007, Cognizant Technology Solutions Confidential
Case Study-Changing along with the
existing code pattern
AS IS Implementation of ReturnOrderService
Public class ReturnOrderService
{ Private ProductRepository _productRepository;
Private RetrunOrderRepository _returnOrderRepository;
Private PayPalGateWay _payPalgateway;
Private string _paypaluserid, _paypalpwd;
Public ReturnOrderService()
{
//Instantiate the repositories and paypal gateway objects
}
public void Process(ReturnOrder ReturnOrder)
{
Step 1: Find the product and Update the stock
Step 2: Refund the customerusing the paypal object
Step 3: Mark the return order as processed
Step 4: Save the updated ReturnOrder
Step 5: Create a Mail message body and format
Step 6:Notify the customer via email about funds return
}
14

15. © 2007, Cognizant Technology Solutions Confidential
Case Study- AS IS Implementation
15
 Adding WorldPay in the AS-IS Implementation.
 Step 1:Create WorldPayGateway
 Step 2:Add the necessary private variables in the RetrunOrderService
Class
 Step 3:In the constructor instantiate the appropriate gateway
 Step 4:In the process Method, on step 2 check again for the right
gateway

16. © 2007, Cognizant Technology Solutions Confidential
CaseStudy- Contd..
16
 Some of the problems with this existing implementation
 RetrunOrderservice is concerned with other activities apart from
coordinating the refund work flow.
 It has to know how the PayPal object needs to be instantiated.
 Any change in PayPal constructor will force a change in
ReturnorderService
 If PayPal class is changed to read the uid/password from other service
or from config files, Reorder Service class need to be changed
 If the stock reconciliation finds usage in other modules, it is difficult to
reuse.
 It is harder to do the unit test as some steps do multiple actions and it
uses other of dependent objects which is not required for the core
solution of the method.

17. © 2007, Cognizant Technology Solutions Confidential
Case Study-Apply SoC
 Some pointers to overcome the key problems
 Apply Separation of Concerns.
 Possible to move the stock reconciliation process as a separate module
 Move away the email and formatting logic into a separate module.
 Can have a Super class for payment gateway and inherit Paypal and
WorldPay from that.
 Apply Dependency Inversion Principle
 First step is to extract interfaces for each of the low level dependencies
 Create interfaces for ReturnStock ,EmailNotification,
ReturnOderRepository, product repository and PaymentGateway
 This enables to have different concrete implementations If needed.
17

18. © 2007, Cognizant Technology Solutions Confidential
Case Study- Apply DI
 Applying Dependency Injection Principle.
 Use Constructor injection principle to pass the interface
objects as needed.
 The ReturnOrderService no longer needs to know what to
instantiate and how to instantiate it. It simply gets what it
requires.
18
Public ReturnOrderService( INotificationService notificationService,
IProductService productService,
IReturnOderRepository returnOderRepository,
IPaymentGateway paymentGateway){
_notificationService=notificationService;
_productService=productService;
_returnOderRepository=returnOrderRepository;
_paymentGateway=paymentgateway;
}

19. © 2007, Cognizant Technology Solutions Confidential
Case Study- A Better picture
19

20. © 2007, Cognizant Technology Solutions Confidential
Case Study 2
 A change request comes in your way to add a new filtering
logic of the products search module. Already the filter module
has code for filtering by Category and the requests is
 “We need a way to filter products based off the color of the product”
20
AS-IS Implementation of the product search module.
public class ProductFilter
{
public IEnumerable<Product> ByCategory(IList<Product> products, Category
productCategory)
{
foreach (var product in products)
{
if (product.Category == productCategory)
yield return product;
}
}
}

21. © 2007, Cognizant Technology Solutions Confidential
Case Study 2
 Now you implement the change request like this
21
public class ProductFilter
{
public IEnumerable<Product> ByCategory(IList<Product> products, Category productCategory)
{
foreach (var product in products)
{
if (product.Category == productCategory)
yield return product;
}
}
public IEnumerable<Product> ByColor(IList<Product> products, ProductColor productColor)
{
foreach (var product in products)
{
if (product.Color == productColor)
yield return product;
}
}
}

22. © 2007, Cognizant Technology Solutions Confidential
 Now you get another request to have filter by
size(large,small,etc…)
 What will you do ?
 You open the ProductFilter class to include a new method…
 Do you see any problem with is approach ?
Case Study 2
22
Every time a user asks for a new criteria to filter a product do we
have to modify the ProductFilter class?
Every time a user asks for a new criteria to filter a product can we
extend the behavior of the ProductFilter class to support this new
criteria without opening up the class file again and modifying it?
Yes! This means it is not CLOSED for modification.
No! This means it is not OPEN for extension.

23. © 2007, Cognizant Technology Solutions Confidential
Case study 2 – A Better approach
 Apply little SRP and Dependency Inversion techniques to over
come the issue..
 Break the dependency on a single class ‘ProductFilter’ and
introduce Interfaces…
23
public interface IProductFilter
{
IEnumerable<Product> ApplyFilter(IList<Product> products);
}
public class ColorFilter : IProductFilter
{
private readonly ProductColor productColor;
public ColorFilter (ProductColor productColor)
{
this.productColor = productColor;
}
protected override IEnumerable<Product> ApplyFilter(IList<Product> products)
{
foreach (var product in products)
{
if (product.Color == productColor)
yield return product;
}
}
public class ProductFilter
{
IProductFilter filter =
FilterFactory.GetInstance(ColorFilter);
filter.applyFilter(products);
}

24. © 2007, Cognizant Technology Solutions Confidential
Case Study-Key Improvements
achieved
 Rigidity
 The dependencies of ReturnOrderService class can be changed with out
fear of impacting the class itself as the dependencies are actually
interface now.
 Flexibility
 No danger of ReturnOrderService breaking due to changes in lower-
level details. Again interfaces come to the rescue.
 Separation of Concerns
 The ReturnOrderService is only responsible for coordinating the
workflow and does not worry about the low level details.
 Reusability
 The ReturnOrderService can be reused with new implementations of
low level modules without harming itself.
24

25. © 2007, Cognizant Technology Solutions Confidential
Case Study – Key Improvements
(Contd..)
 Testability
 The testability of the whole system has improved as there is clear
separation of the functionalities. Use of Interfaces helps to overcome the
object dependency issue in Unit testing.
25

26. © 2007, Cognizant Technology Solutions Confidential 26
Test Your Understanding
 What is Dependency Inversion principle ?
 How is it different from Dependency Injection Principle?
 What are the different types of Dependency injections?

27. © 2007, Cognizant Technology Solutions Confidential
S.O.L.I.D Class Design Principles
27
SRP
The Single Responsibility
Principle
A class should have one, and only
one, reason to change.
OCP The Open Closed Principle
You should be able to extend a
classes behavior, without
modifying it.
LSP
The Liskov Substitution
Principle
Derived classes must be
substitutable for their base classes.
ISP
The Interface Segregation
Principle
Make fine grained interfaces that
are client specific.
DIP
The Dependency Inversion
Principle
Depend on abstractions, not on
concretions.

28. © 2007, Cognizant Technology Solutions Confidential 28
Enterprise Development
 Summary
 Tenets of Enterprise development
 Reliability
 Flexibility
 Separation of concerns
 Reusability
 Maintainability
 Principles to enable Enterprise Development
 Separation of Concerns (SoC)
 Single Responsibility Principle (SRP).
 Dependency Inversion or Inversion of Control ( DI or IoC)
 Dependency Injection

29. © 2007, Cognizant Technology Solutions Confidential 29
Introduction to Enterprise Development
 www.oodesign.com
 PoEAA by Martin Fowler
 http://skillport.books24x7.com/toc.asp?bookid=27555
 Clean Code by Robert C. Martin
 http://blogs.msdn.com/codeanalysis/archive/2007/10/03/n
ew-for-visual-studio-2008-code-metrics.aspx
Disclaimer: Parts of the content of this course is based on the materials available from the Web sites and books
listed above. The materials that can be accessed from linked sites are not maintained by Cognizant Academy and
we are not responsible for the contents thereof. All trademarks, service marks, and trade names in this course are
the marks of the respective owner(s).

30. You have successfully completed
Enterprise Application Development – An
Overview
Click here to proceed