Software Architecture And Patterns

What is Software Architecture?

To understand software architecture, or simply architecture, let us discuss a requirement of real life. Let us assume there is a requirement of a one-floor building where in the future we can add some more floors, and also we will be able to change the room design of new or existing floors with easy-to-make partitions at any time. So these are the common requirements of the building, and also it must not be affected by earthquakes, meaning the building should be ready to face any situation easily. So these are nothing but attributes and behaviors of the building, and we can only achieve all this through with proper design. The design of the foundation is the most important part of any building design, and also as an end user or client, we always consider concepts such as Time, Budget, Flexibility, Maintainability, Reliability, Robustness etc. Whenever we need something in real life we generally ask the vendor questions like: How was this built? What would be the cost of maintaining it in the future? How long will it last? etc. And the vendor as a non-computer person will say, we have made it this way or that way, and this particular item is long-lasting and easy- to-maintain in the future. They will say so many thing to satisfy our questions. It means in a direct way, he was trying to explain about how this item was constructed or designed so that it meets the user requirements and also is easy to maintain in the future.

The underlying idea from the above point is that if anything is designed properly or structurally then this will produce a good product which will meet all the above criteria. So this is nothing but architecting the items in a well-planned way to meet the fundamental theory of the previously-mentioned words.

So in short, architecture is nothing but the process of defining a structured solution of anything which meets technical and non-technical operations of any business. In brief, it is just a design process on paper or in real implementation.

Goals of Architecture

There are various goals of architecture,

• Create outline or skeleton to implement a product
• Hide detail and inner complexity and show the structural detail
• Help developer to utilize common components or code
• Loosely coupled design of product
• Reduce redundant code by creating reusable components or library
• Solve well known issues which occurred while designing any application
• Easy to maintain product in support phase
• Satisfy the end user by providing cutting edge solutions
• Easy to adapt any business changes in future

There are various objectives and goals which we can achieve from good architecture.

Architecting Principals

There are some key design principals which help to achieve a good architectural product and they are,

• Separation of concern
  Separation of concern is nothing but a style of implementation of code or business logic and UI in a clean way so that both should not mix together. It means business concerns or other key logic should be in a separate layer or file from UI design.
  
  
• Single Responsibility
  As the name suggests, each module or component should be responsible for one and only one task.
  
  
• Least Knowledge
  It means one component should not know the detail of other components.
  
  
• Do not Repeat
  It means the same functionality should be repeated in multiple components. One functionality should be in one component.
  
  
• Minimize the Design
  Only design what is required for the application and do not try to reinvent the wheel if something is already available. Try to use time tested reusable components if possible. This will minimize the testing effort and time for bug fixing which in turn is cost effective development and will meet the deadline easily.
  
  The idea of these design principals is to hide the complexity of modules by componentizing the solution and providing easily adoptable components or functions which we may reuse with other applications as well. For example, distribute different areas of concern into different components such as Data Access, Business Logic, Exception Handling Mechanism, Email or SMS handling, File Operation, Services etc.
  

Design Practices

If we think at a high level of architecting the solution then we may come up with some ideas and they would be,

• Practice
  In Software development, practice is nothing but a general way of coding style or the way of writing a piece of code that it should not be repeated with other areas of the solution, or utilizing concepts of Object Oriented programming in our solution or delivering quality components. There are so many ideas which we follow as good design practice.
  
  
• OOPS
  Fully utilize the concept of object oriented paradigms which help to solve known development issues and allow you to extend and maintain applications in a better way than the monolithic approach.
  
  
• Application Layer
  Be specific abut what components we are going to develop as part of the solution and categorize them in layers that help to implement certain theories of best practices like Cohesion and Coupling.
  
  
  • Use domain model or object to send and receive data across the layer whenever required so that the application will have the same format of data everywhere
    
  • Based upon functionality of components, break them into different layers such as Data Access, Business Logic, Helper or Utility or Common, Domain, Service etc.
    
  • Always use abstraction to achieve development of loosely coupled components.
    
    
• Components
  Components should not depend upon details of other components and communication of each component should be specific about how they are going to talk with each other
  
  Define the contract of each component for how other components can access the internal functionality of the component, module, or function; and the behavior of that functionality in terms of execution flow, behavior of pre and post condition, side effects, exceptions, performance characteristics, and other factors.
  
  
• System Quality
  Delivering quality components is one key aspect of software development to meet the user requirement efficiently. To do so perform unit tests for each development to ensure the piece of code works fine followed by a thorough system testing or any other type of testing. Use automated QA tools during development to ensure that the correct operational data is provided by your application’s components and sub-systems.
  

When to Create Architecture

Creating Your Own Design Pattern

Creating your own pattern is not hard but you need an idea to solve some specific problem that becomes the best solution of the given problem. Then get it reviewed, document it, and share it with your colleague so they can learn from what you have done.

Rule of Three

Any solution can be a design pattern that confirms the Rule of Three, which means something must be used at least three times to solve the same problem successfully before it can be called a design pattern.


Types of Design Patterns

There are three categories of design patterns which can be used as per the requirement and they are,

• Creational Patterns
  
  This pattern provides a mechanism to create objects of the classes in a more efficient way.
  
  
  • Factory
    Factory Pattern creates objects without exposing the creation logic to the client and refers to newly created objects using a common interface.
    
    
  • Abstract Factory
    Abstract Factory is nothing but a Factory of Factory, which create Factory objects based upon the interface without explicitly specifying classes. Each generated Factory can give the objects as per the Factory Pattern.
    
    
  • Builder
    Builds a complex object by using simple objects and also step by step.
    
    
  • Prototype
    Allows us to create duplicate objects by cloning. This pattern is useful when the creation of an object is costly.
    
    
  • Singleton
    In this pattern only single class is involved and creates only a single object.
    
    
• Structural Patterns
  
  This pattern provides a mechanism to deal with relationships of different entities in an easier way.
  
  
  • Adapter
    This pattern is something like a bridge between two independent interfaces in which one class joins the functionality of two independent interfaces.
    
    
  • Bridge
    Bridge Pattern separates an abstraction from its implementation so that the two can work independently.
    
    
  • Composite
    Composite design patterns form a tree structure to represent part of as well as the whole hierarchy. This pattern creates a class which holds a group of its own objects and provides a way to modify its objects.
    
    
  • Decorator
    This is a kind of wrapper class implementation which allows a user to add new functionality to an existing object without changing the flow, this pattern acts as a wrapper to an existing class. The wrap class wraps the original implementation and provides additional features.
    
    
  • Façade
    This pattern hides the inner complexity of a system and provides a simple method to deal with different sub systems. This pattern has a single class and its method provides delegates to different classes of methods.
    
    
  • Flyweight
    Design wise it is a factory pattern with additional checks and in-memory storage to reduce the number of objects created. Before creating an object it checks if a previously created object exists, then it returns the same.
    
    
  • Proxy
    This design pattern represents functionality of other classes in which a proxy object holds the original object to interface its functionality to the outer world.
    
    
• Behavioral Patterns
  
  This pattern provides a mechanism for how entities should talk to each other.
  
  
  • Chain of Responsibility
    This patterns creates requester and receiver objects which forms the chain. If one of the objects cannot handle the task then it passes to the next level of object, like a way of passing a request between a chain of objects.
    
    
  • Command
    A request will be encapsulated under object and passed to invoker which further finds the appropriate object which can execute the command request.
    
    
  • Interpreter
    This pattern provides a way to evaluate language or expression. It is useful in parsing some syntax or expression.
    
    
  • Iterator
    Iterator pattern provides a way to implement iterator class which returns the objects from the Array collection without knowing the underlying detail in a sequential manner.
    
    
  • Mediator
    It reduces the communication complexity between multiple objects or classes. Where classes do not talk to each other directly, the mediator class handles all the communications between different classes.
    
    
  • Memento
    This pattern is useful to maintain the state of object or application, which means it provides a way to capture and restore the state of the objects.
    
    
  • Observer
    This pattern is useful where there is a one-to-many relationship between objects and if one object is modified, its dependent objects should be notified automatically.
    
    
  • State
    This pattern changes the class behavior based on its state. It creates an objects which represents various states and a context object whose behavior varies as its state object changes.
    
    
  • Strategy
    This Pattern encapsulates various strategies and a context whose behavior varies as per its strategy object. The strategy object changes the executing algorithm of the context.
    
    
  • Template Method
    This pattern defines the abstract class and exposes a method which executes a set of methods in a defined way.
    
    
  • Visitor
    This pattern performs an operation on an element of object structure and also defines a new operation without changing the class hierarchy. So in this way the number of operations can vary as and when the visitor varies.

I hope this article will help you to understand Architecture and Design Pattern properly. In the next article we will see the real implementation of each design pattern relating to a real world problem.