Category Archives: Architect

Architect

SOLID Software Design Principle

Leave a comment

Why Software Design Principles?

Software Design principles are a set of guidelines to handle complexity and reduce the effort needed to develop a good system design. Design principles ease problems of future development, enhancement, maintenance and also reduce the scope of error during design.

SOLID Design Principles

What are Software Design Principles?

These are around 12  Software Design Key Principles but most important is SOLID Software Design principles. which use in all software designing.

  1. Single Responsibility Principle: One class should do one thing and do it well.
  2. Open Close Design Principle: Open for extension, close for modification.
  3. Liscov Substitution Principle: Subtype must be a substitute for supertype.
  4. Interface Segregation Principle: avoid monolithic interface, reduce pain on the client-side.
  5. Dependency Inversion Principle: Don’t ask lets framework give it to you.

1: Single Responsibility Principle (SRP)

A class should have only one reason to change. If there is any other reason to create another class.

This principle is completely based on Coupling and Cohesion. This principle states that your software design classes should in such a way that each class should have a single purpose/responsibility/functionality.

While designing software if you put more than one functionality in a single class then increase coupling between functionalities. If change required in one functionality there are chances to broke other functionality and required more testing to avoid such surprises in the production environment.

Responsibility Examples

Suppose you are having JPA classes as SavingAccountRepository.java and CurrentAccountRepository.java then SavingAccountRepository.java class should have only methods and queries related with Saving Accounts. It means your class should specialize in a single purpose.

Others most common example of responsibilities:

  • Logging
  • Formatting
  • Validation
  • Notification
  • Error Handling
  • Parsing
  • Caching
  • Mapping
  • Class Section/ Instantiation etc.

Benefits

  • This principle makes your software easier to implement and prevent unexpected side-effects of future changes.
  • Your class will change only if anything will change in respected responsibility.
  • Need to update dependencies and compile when some respected dependencies change.
  • Reduce coupling between software and components.

The Single Responsibility Principle (SRP) also provides other benefits with classes, components, and microservices with single responsibility to make your code easier to explain, understand, implement. It also improves development speed and easier to track bugs.

2: Open-Closed Principle (OCP)

Software entities like classes, modules, and functions should be open for extension (new functionality) and closed for modification.

This principle is based on inheritance or composition design patterns like Strategy Design pattern. As per this principle:

  • “Open” means, Your code should be able to extend existing code in order to introduce new functionality.
  • “Close” means, Once your module has been developed and tested, the code will change only when correct bugs.

For Example, A BankAccount.java base class contains all basic transaction-related properties and methods. The same class can be extended by SavingAccount.java and CurrentAccount.java to handle saving and current account functionalities. If new functionalities need to add then only modification required in BankAccount.java class. Hence this class is open for extension and close for modification.

Benefits

The main benefit of the Open/Close Design principle is that already developed and tested code will not be modified and don’t break.

3: Liscov Substitution Principle (LSP)

The driven type must be completely substituted for their base type.

Liscov Substitution Principle is closely related to the Single Responsibility Principle and Interface Segregation Principle.

This principle states that Subclasses or derived classes should be completely substituted by the superclass. The Subclass should enhance the functionality but not reduce it.

In other words, functions that use pointers and reference of base classes must be able to use objects derived classes without knowing it.

Example

Suppose Employee class extends Person Class by inheritance. In this way wherever you are using person class should also be able to use Employee class because Employee is a subclass of Person class.

Benefits

  • If this principle violates then so much extra conditional code of type checking and duplicate code need to write throughout the application that can cause bugs when the application grows.
  • In methods or functions which use the superclass type must work with the object of subclass without any issue.

4: Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods in interfaces that they don’t use.

This principle states that a client should not implement an interface if it doesn’t use that. An interface should belong to clients, not to the library or hierarchy and keep only those methods as required for the client.

Example

In an application service interface exposed to the client should have only those methods that are related to the client.

Benefits

If you violate this principle and add some more methods in an interface that are not used with the client then if you change anything in interface definitely some functionality of the client will break.

5: Dependency Inversion Principle (DIP)

The high-level module should not depend on low-level module, both should depend on abstractions. Abstraction should not depend on detail. detail should depend on abstraction.

This principle provides loose coupling between the dependencies of modules and classes.

The Dependency Inversion Principle states that:

High-level modules should not depend on low-level modules directly, both should depend on abstractions. This abstraction should not depend on details, details should depend on abstractions.

Examples

The best example of the Dependency Inversion Principle is the Spring framework where dependencies are injected through XML or Annotation which provide abstractions and can change without modification on implementation.

Benefits

  • If you violate this principle your code will be tightly coupled because every high-level module is directly referencing to lower-level modules.
  • Makes testing easy by injecting the mock objects without modification on existing functionality.
Architect

Software Development Team Roles and Responsibilities

Leave a comment

This post you will know about the peoples with different roles involved within an organization specifically for developing software or application. This software development can divide into multiple project teams based on the area of expertise, modules and do development in parallel in multiple project teams. These projects teams management for functional or operational taken care by management people like IT manager, Functional Manager, Delivery Manager, etc.

Project Team

A project team may consist of full-time and part-time resources assigned to analysis, designing, development, and testing to the deliverable of projects. As a team, these peoples have below common responsibilities that make a project team more effective.

Responsibilities

  • A clear understanding of work needs to complete.
  • Plan the activities in detail and do the assignment to the team.
  • Complete the assigned work in the budget, timeline and meet the quality expectation.
  • Inform management proactively about issues, scope changes, risk, and quality concerns.
  • Use flexible methodologies and constant changes to get the best possible results.
  • There should not be any communication gap because that can impact their understanding of the project, roles, and responsibilities of other team members.
  • Maintain a mutually supportive and foster work environment where team members understand each other’s efforts.

A project team can be under a functional organization that can involve members from the same organization or from other cross-functional organizations. To make an effective team every team member should know their responsibilities based on assigned roles.

In an organization, the software development team size and roles decide based on some common factors like outline project requirements, budget, and timeline. These requirements decide to type of resources required to fulfill those requirements within the timeline.

Generally, in software development project people involve having these roles, sometimes one role responsibility can merge with other roles also depend on organization size and budget of the project:

  1. Client/Customer
  2. Client Project Manager
  3. Project Manager
  4. Software Delivery Manager
  5. Product Owner
  6. Functional Manager
  7. Business Analyst
  8. Software Architect
  9. QA Manager
  10. Change Manager
  11. Process Analyst
  12. Test Engineer
  13. Software Developer/ Programer
  14. Subject Matter Expert
  15. Database Administrator
  16. Designer
  17. Solution Architect

1. Client/Customer

These are people that are direct beneficiaries of a product or project or service is being undertaken. These people are also called “customers” if they are internal to the organization then referred to as clients.

2. Client Project Manager

In a large project, Client Project Manager is the primary contact person that is designated as project manager for work on the client-side. If an IT manager needs any support on the client-side then Client Project manager would be responsible for those. The IT project manager and client project manager would be peers to build and implement complete solutions.

3. Project Manager

The project manager is for developing a plan, manage teams, assign tasks to project team members, recruit the right resources, lead, monitor and determine the methods and technologies to be utilized.

Responsibilities

  • Develop a project plan.
  • Manage deliverables according to the plan.
  • Recruit project staff.
  • Lead and manage the project team.
  • Determine the methodology used on the project.
  • Establish a project schedule and determine each phase.
  • Assign tasks to project team members.
  • Provide regular updates to upper management.

4. Software Delivery Manager

Delivery Manager takes care of project progress, budget and complete project delivery within the timeline.

Responsibilities

  • Serve as the primary contact person for client-related queries and concerns.
  • Review and Analyze customer orders, coordinate delivery activities set delivery priorities and make schedule adjustments to meet timely.
  • Build positive, productive and healthy working relationships with customers for business growth.
  • Analyze progress of development, defects and troubleshoot delivery issues in a timely fashion.
  • Manage a delivery team to ensure delivery of projects in a timely and accurate.
  • Oversee the progress of the delivery team and provide direction and guidance as required.
  • Perform workload assignments and resource allocation according to delivery requirements.
  • Ensure that the team maintains a high level of skills competence and operational excellence.
  • Evaluate the performance at team members and determine training needs
  • delivery goals
    • Evaluate the process  to achieve cost-effectiveness and time saving,
    • Perform customer negotiations for delivery rates.
    • Make critical business decisions to meet customer expectations.
    • Develop scope and budget for delivery projects.
    • Report project delivery status to customers and develop the required delivery artifacts.

5. Product Owner

Product owner term used in Agile Methodology. This person is the leader responsible for maximizing the value of the products created by the scrum development team.

Responsibilities

  • Acting as a primary person to coordinate with the client.
  • Define the vision of the project/product.
  • Anticipating client needs.
  • Managing the product backlog according to prioritizing needs.
  • Overseeing development stages.
  • Evaluate product progress at each iteration.

6. Functional manager

The functional manager takes care of working closely with the team members, ensuring project progress and manage ongoing responsibilities for the project.

Responsibilities

  • Assign projects to the team.
  • Work with the employee to set and coach on career goals.
  • Gather information from other Project Managers to write the evaluation.
  • Evaluate person based on work standard and performance and if a person wants to continue doing it (providing opportunities for growth)

7. Operational Manager

An operations manager is a senior role. It’s the job of overseeing organization is running as expected, check the production of goods, meeting client expectations, etc.

Responsibilities

  • Plan effective strategies, processes, policies in support of organizational goals and vision for the financial well-being of the company.
  • Coordinate, manage and monitor the workings of various departments in the organization and also evaluate performance.
  • Review financial statements and data. Utilize financial data to improve profitability.
  • Prepare and control operational budgets and Control inventory.
  • Plan the use of human resources utilization, recruitment, and placement of required staff.
  • Establish organizational structures and work schedules.
  • Delegate tasks and accountabilities.
  • Coordinate and monitor the work of various departments involved in the production, warehousing, pricing, and distribution of goods and also provide facilities required.
  • Managing quality assurance programs.
  • Setting and reviewing budgets and managing cost.
  • Research new technologies and alternative methods of efficiency.
  • Overseeing inventory, distribution of goods and facility layout.

8. Business Analyst

The Business Analyst is responsible for ensuring that the requirements of the clients are captured and documented correctly before a solution is developed and implemented. They verify the project deliverables to ensure that they meet the client’s requirements.

In many companies, Business Analysts also called as Analyst, Business Systems Analyst, Systems Analyst or Requirements Analyst.

Responsibilities

  • Bridge the gap between IT development and the business using data.
  • Assist in defining the project and translating requirements to the team.
  • Gather requirements from business units or users.
  • Document technical and business requirements.
  • Requirement specification document.
  • Performing acceptance testing.
  • Defining the scope of the project.
  • Determine requirements, Analytics to assess processes and deliver data-driven recommendations and reports to executives and stakeholders

9. Software Architect

A Software Architects design and develop software systems and applications based on client requirements.

Responsibility

  • Identifying business requirements clients and stakeholders on the project.
  • Designing the entire software system based on the received requirements from customers.
  • Choose the system architecture and each individual component of this system at a high level.
  • Choosing the right tools, technologies, and framework for the implementation of each component and connections between the components.
  • Writing project documentation and its support in a timely manner so that the overall organization can make progress before it’s complete.
  • communicate with stakeholders to make sure their application needs are being met.
  • Resolve technical problems.
  • Architectural Review.
  • Code Review.
  • Design model and also verify the qualities and performance are being met.

10. QA Manager

The quality assurance manager works with other QA (Quality Assurance) staff such as Functional Analyst and Solutions Architect to verify that the product meets the client’s requirements.

Responsibilities

  • QA converts the requirements and design documents into a set of testing cases and scripts.
  • Verify that the system meets the client’s needs.
  • Make Test Plan for test cases and scripts.
  • Make Test Plan documents as simple which provides an overview of each test case.
  • Use test cases and script to validate so that the system will not have any unexplained error.
  • Take approval from SME (Subject Matter Expert)for test plan and scripts and represents the criteria to reach a project closing.
  • Check all the test cases and script passed test status and met acceptance criteria.

Note :

  • Test scripts are step-by-step instructions on what needs to execute, what to look for, and what will result.
  • Test cases can be created with nearly on input from the architecture or design and the test scripts. Test cases are specifically shown, how a problem was solved by the software development team and it requires an understanding of not only the requirements, but also the architecture, design, and detailed design.

11. Change manager

These are a group of people usually do decision about the budget, requirements, and timeline of the project.

12. Process Analyst

Process Analyst includes process review and improvement, relationship management, product documentation, and support. The business process analyst is responsible for the business architecture and maintains artifacts.

Responsibilities

  • Process Review and Enhancement.
  • Documentation, Training, and Support.
  • Stakeholder Relationship Management.
  • Understand customer and user requirements, strategies, and goals.
  • Assess the situation of the customer organization where the projects will be deployed.
  • Facilitate modeling of the customer organization.
  • Discuss to management and facilitate a business engineering effort, if needed.
  • Perform a cost/benefit analysis for any suggested changes in the customer organization.
  • Discuss and support the marketing and sales team for the end-product of the project.

13. Test Engineer

The Test Engineer’s main responsibility is to define test cases, monitoring the test coverage, evaluate the test cycle to monitor quality and the consistent outcome. Tester is also responsible for specifying test data and evaluate the outcome of each test cycle. Test Engineer also called by name Test Analyst or Tester.

Responsibilities

  • Ensures the solution meets the business requirements and free of bug, errors, and defects.
  • Identifying the Target Test areas to be evaluated by the test effort.
  • Write the appropriate tests required and associated Test Data to execute it.
  • Gathering and managing the Test Data.
  • Evaluating the outcome of each test cycle.

14. Software Developers/Programmers

A software developer or programmer is responsible for the development and implementation of assigned tasks mentioned in design documents or user stories.

Responsibilities

  • Software Developers design, develop, and test new software programs and applications.
  • Design and update the software database.
  • Regularly communicate with management and technical support team for development.
  • Maintain and improve the performance of existing software.
  • Recommend improvements to existing software programs as necessary.
  • Test and maintain software products to ensure fulfill strong functionality and optimization.

15. Subject Matter Expert

Subject Matter Expert (SME) are specialists in specific domains and having knowledge of a discipline, technology, product, business or entire business area for specific aspects of the development.

Responsibilities

  • Review test cases for integration testing associated with the software management system.
  • Help validate user requirements for payroll application.
  • Conduct code walkthrough for accounts payable interface to a legacy system.
  • Review requirements traceability matrix, and ensure that requirements have  all code coverage.
  • Help refine and determine feasibility, correctness, and completeness of end-users ’ requirements.
  • Provide input for the design and implementation of test cases and business scenarios.
  • Help answer questions associated with the design of the status of the application, its features, and its capabilities.
  • Validate executed test results.

16. Database Administrator

A Database Administrator is a specialist that schema models, designs and creates the databases and tables used by a software solution. This role is a combination of  Data  DBA (physical) and administration (logical).

17. Designer

The application designer is responsible for understanding the business requirements clearly and designing a solution that will fulfill the business needs.

Responsibilities

  • Choose the best potential and optimum solution that will meet the client’s needs.
  •  Decide technology to create an optimum solution for the client.
  • Determine the overall model and framework for the solution, down to the level of designing screens, reports, programs and other project components.
  • Determine the data needs.
  • Handover the design and specification to programmers and other people who will implement the solution over design.

18. Solution Architect

The role of Solution Architect is used where generally SAP module customization required based on clients’ needs.

Responsibilities

  • Define the scope of the project.
  • Understand the client’s requirements and business viabilities.
  • Determine the gaps between requirements and SAP functionalities and provide workable solutions to bridge the gaps.
  • Design the solutions in detail with the help from the consultants and business.
  • Plan the closure of the solutions and see through the implementation of the solutions.

 

Architect, RDBMS, Vs

DBMS VS RDBMS

Leave a comment

RDBMS is extension of DBMS.

DBMS (Database Management System)

Software that provides a systematic way of creating, retrieving and managing data in a database.

DBMS Example : File System, XML, Dbase, Microsoft Access, LibreOffice Base, Fox Pro etc.

RDBMS(Relational Database Management Information System)

A DBMS based on relational model and store data in tables that related to each other.

RDBMS Example: MySQL, PostGre, SQL Server, Oracle, MariaDB, SqlLite etc.

Here area some main points that make differences between DBMS and RDBMS.

DBMS RDBMS
DBMS application stores data in files that have no relationship. RDBMS application stores data in tabular form which will have a relation between tables.
DBMS store data either in hierarchical form or navigational form. RDBMS table has one identifier called as primary key and data stored in tabular form.
DBMS does not support Normalization. RDBMS supports normalization.
DBMS does not provide any security with regards to data manipulation. RDBMS defines the integrity constraints for the purpose of ACID property.
DBMS does not support distributed database. RDBMS support distributed database.
DBMS is for small organization to deal with small data. It supports for single user. RDBMS is designed to handle large amount of data. It supports multiple users.
DBMS does not support client server architecture. RDBMS  support client server architecture.
DBMS have high data redundancy. RDBMS have low data redundancy.
DBMS takes more time to access data. RDBMS takes less time to access data.
Architect, RDBMS, Vs

ACID Vs BASE for Database Transactions

Leave a comment

In the previous post, you have learned about the ACID and BASE properties of database transactions in detail.

ACID vs BASE

Here you will know about high-level differences between ACID and BASE.

 

ACID BASE
Provides Vertical Scaling Provides Horizontal Scaling
Strong Consistency Weak Consistency – Stale Data OK
Isolation Last Write Wins, availability first
Transaction Programmer Managed
Available/Consistent Available/Partition Tolerant
Robust Database/Simple Code Simpler Database, Harder Code
Focus on “Commit” Best Effort
Nested Transactions Approximated Answers
Less Availability Aggressive (optimistic)
Conservative (pessimistic) Simpler
Difficult Evaluation(i.e Schema) Faster, Easier evolution
High Maintenance Cost Low Maintenance Cost
Expensive Joins and Relationship Free from joins and Relationship
Examples: Oracle, MySQL, SQL Server, etc. Example : DynamoDB, Cassandra, CouchDB, SimpleDB etc.

See Also:

Architect, RDBMS, Vs

SQL vs NoSQL

Leave a comment

In this post you will know about the main high level difference between SQL and NoSQL type databases.

SQL vs NoSQL

SQL NoSQL
Relational Type Non-Relational Type
Structured Data Stored in Tables The un-structured data store in JSON format in file but graph of database show relationship.
Strict Schema Dynamic Schema
Vertical Scalable Horizontal Scalable
Structured Query Language Un-structured Query Language
ACID Transactions CAP Theorem
Requires downtime In most cases automatic, No outage required
Rigid schema bound to the relationship Non-rigid schema and flexible.
Helpful to design complex queries. No joins relationship, no any powerful tool to prepare complex queries.
Recommend and best suited for OLTP (Online Transactional Processing) Systems. Less likely to be considered for the OLTP System.
Storage : Table (Row->Entity, Column->Attribute)
RDBMS: Oracle, MYSQL, SQL Server, IBM DB2 etc.		 Storage:
Key-Value: Redis, Dynamo
Document: MongoDB
Graph: Neo4j, InfiniteGraph
Wide-column- Cassandra, HBASE
SQL is not fit for Hierarchical work. NoSQL is the best fit for hierarchical work as it follows the key-value pair’s way to store values.
Architect, RDBMS

BASE Properties for Distributed Database Transactions

1 Comment

In the previous post, you have learned about ACID properties of the database transactions for traditional databases. As transactions are growing over the internet, systems are scalable and distributed. In some of the systems where availability is more important than the consistency.

For Example, Amazon, eBay, etc.

For such types of systems in 2000, Eric Brewer’s introduce a theorem that’s called CAP Theorem. It states that

“In a distribution system can only have two out of following three Consitentency, Availability, and Partition Tolerance- One of them must be a sacrifice. You can’t promise all three at a time across reading/write requests.”

Based on CAP theorem, where scalability and availability is most important. It introduces alternatives to ACID is BASE for distributed database transactions.

BASE full form:

BASE

Basically Available

The system guarantees availability.

It majorly focuses on availability, potentially with outdated data and it does not provide guarantee on global data consistency across the entire system.

Soft-state

The state of the system may change over time.

Even without explicit state updates, data may change due to the asynchronous propagation of updates and nodes that become available.

Eventual consistent

The system will eventually become consistent.

Updates eventually propagated, the system would reach in a consistent state if no further updates and network partitions fixed.

See Also:

Architect, oops

12 Software Design Key Principles

Leave a comment

If you are in software development and working as senior programmer or application architect then you should keep these software deigning principle in your mind while working on software or application development.

Why Software Design Principles?

Software Design principles are set of guidelines to handle complexity and reduce effort needed to develop a good system design. Design principles ease problems of future development, enhancement, maintenance and also reduce the scope of error during design.

What are Software Design Principles

These are the key software design principles but most important is SOLID (top 5)  which use in all software designing.

  1. Single Responsibility Principle : One class should do one thing and do it well.
  2. Open Close Design Principle : Open for extension, close for modification.
  3. Liscov Substitution Principle : Sub type must be substitute for super type.
  4. Interface Segregation Principle: avoid monolithic interface , reduce pain on client side.
  5. Dependency Inversion Principle: Don’t ask lets framework give it to you.
  6. DRY(Don’t Repeat Yourself) : avoid duplication in code.
  7. KISS (Keep it Simple, Stupid) : Keep you code simple, small and understandable.
  8. Encapsulate what changes : hides implementation detail helps in maintenance.
  9. Favor Composition over inheritance: Code reuse without cost of inflexibility.
  10. Programming for interface : Helps in maintenance, improve flexibility.
  11. Delegation Principle: Don’t do all things by your self. Lets Delegate it.
  12. YAGNI ( You Ain’t Gonna Need It) : If it’s not in the concept, it’s not in the code

All these software design principles are mainly based on four factors:

  1. Problem Partitioning : Divide the problem in manageable pieces.
  2. Modularity : Divide software to well-defined separate module .
  3. Abstraction: Provide component as interface and hide internal implementation.
  4. Strategy Of Design: Top-Down/Bottom-Up Approach

In this further section will discuss about in these principles in detail.

1 : Single Responsibility Principle (SRP)

      A class should have only one reason to change. If there is any other reason create another class.

This principle is completely based on Coupling and Cohesion. This principle states that In your software design a classes should in such a way that each class should have a single purpose/responsibility/functionality.

While designing software if you put more than one functionality in single class then increase coupling between functionalities. If change required in one functionality there are chances to broke other functionality and required more testing to avoid such surprises in production environment.

 Responsibility Examples

Suppose you are having JPA classes as  SavingAccountRepository.java and CurrentAccountRepository.java then SavingAccountRepository.java class should have only methods and queries related with Saving Accounts. It means your class should specialize in single purpose.

Others most common example of responsibilities:

  1. Logging
  2. Formatting
  3. Validation
  4. Notification
  5. Error Handling
  6. Parsing
  7. Caching
  8. Mapping
  9. Class Section/ Instantiation etc.

Benefits:

  • This principle make your software easier to implement and prevent unexpected side-effects of future changes.
  • Your class will change only if anything will change in respected responsibility.
  • Need to update dependencies and compile when some respected dependencies change.
  • Reduce coupling between software and components.

The Single Responsibility Principle (SRP) also provides other benefits with classes, components and micro services with single responsibility make your code easier to explain, understand, implement. It also improves development speed and easier to track bugs.

2 : Open Close Principle (OCP)

Software entities like classes, modules and functions should be open for extension (new functionality) and closed for modification.

This principle is based on  inheritance or composition design pattern like Strategy Design pattern. As per this principle:

  • “Open” means , Your code  should be able to extend existing code in order to introduce new functionality.
  • “Close” means, Once your module has been developed and tested, the code will change only when correct bugs.

For Example: A BankAccount.java base class contains all basic transaction related properties and methods. The same class can be extended by SavingAccount.java and CurrentAccount.java to handle saving and current account functionalities. If new functionalities need to add then only modification required in BankAccount.java class. Hence this class is open for extension and close for modification.

Benefits:

  • The main benefit of Open/Close Design principle is that already developed and tested code will not modified and don’t break.

3 : Liscov Substitution Principle (LSP)

Drived type must be completely substitute of their base type.

Liscov Substitution Principle is closely related to the Single Responsibility Principle and Interface Segregation Principle.

This principle states that Subclasses or derived classes should be completely substituted of superclass. The Subclass should enhance the functionality but not reduce it.

In other words, functions that use pointers and reference of base classes must be able to use objects derived classes without knowing it.

Example

Suppose Employee class extends Person Class by inheritance. In this way wherever you are using person class should also be able to use Employee class because Employee is a subclass of Person class.

Benefits

  • If this principle violates then so much extra conditional code of type checking and duplicate code need to write throughout the application that can cause bugs when the application grows.
  • In methods or functions which use the superclass type must work with the object of subclass without any issue.

4 : Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods in interfaces that they don’t use.

This principle states that a client should not implement an  interface if it doesn’t use that.  An interface should belong to clients , not to library or hierarchy and keep only those methods as required for client.

Example

In an application service interface exposed to client should have only those methods that are related to client.

Benefits

  • If you violate this principle and add some more methods in interface that are not used with client then if you change any thing in interface definitely some functionality of client will break.

5:  Dependency Inversion Principle (DIP)

High level module should not depend on low level module , both should depend on abstractions. Abstraction should not depend on detail. detail should depend on abstraction.

This principle provide loose coupling between  the dependencies of modules and classes.

The Dependency Inversion Principle states that:

  1. High level modules should not depend on low level modules directly, both should depend on abstractions.
  2. This abstraction should not depend on details, details should depend on abstractions.

Examples

The best example of Dependency Inversion Principle is Spring framework where dependencies are injected through XML or Annotation which provide abstractions and can change with out modification on implementation.

Benefits

  • If you violate this principle your code will be tightly coupled because every high level module is directly referencing to lower level modules.
  • Makes testing easy by injecting the mock objects with out modification on existing functionality.

6: Don’t Repeat Yourself (DRY)

          Avoid duplication of code.

This principle states that don’t write duplicate code. If you have same code on multiple places then consider making a separate method. or If you are using any hard code value more than one time make this value as public static final constant.

Example

Suppose, you are using some format to validate orderId and your complete system is based on it. In future, if your orderId format get change and if your code is duplicate then you have to modify in all places otherwise system will fail. In such scenarios better write hardcoded values and common code in methods so that make system maintenance easy.

Benefits

  1. The main benefit of DRY principle is maintenance of system.
  2.  This helps to design a system scalable, maintainable and reusable.
  3.  Common functionality or utility methods will on one place.

7 : Keep it Simple, Stupid (KISS)

Keep it short, simple and Understandable.

KISS principle states that always try to keep your code in small pieces, simple and avoid unnecessary complexity.

Benefits

  • KISS principle helps to write easy maintainable code.

DRY and KISS principle are almost similar because it focus on small piece of code but difference is KISS principle more focused on simplicity and avoid complexity.

8 : Encapsulate What Changes

Hidden implementation detail helps in maintenance.

This principle states that encapsulate the code you expect or suspect to be changed in future. By default make your variables and methods private and increase access step by step like from private to protected not directly public.

Example

In java lots of design patterns use encapsulated code , like Factory Design Pattern is one example where object creation code is inside factory class and in future need to enhance functionality for any new product then do it without impact of existing code.

Benefits

  • It’s easy to test and maintain proper encapsulated code.

9: Favor Composition Over Inheritance

Code reuse without cost of inflexibility.

In OOPS there are two ways to reuse the code, Inheritance and composition, both the ways have own advantage and disadvantage.

This principle states that, If possible always prefer composition over inheritance because composition are lot more flexible than inheritance.

Benefits

  •  Composition allow to change behavior of class at runtime by setting properties during runtime and by using interfaces to compose a class by runtime polymorphism provides flexibility to use better implementation any time.

10 : Programming for Interface

This principle states that we should always program for interface not for implementation. It makes code flexible with any implementation of the interface.

In other words, We should always use interface type in variable, methods arguments and return type of methods like Super class type to object instead of sub class.

Example

Programming for Interface Example

Benefits

  • It provides flexibility to maintenance code and change implementation.

11 : Delegation Principle

Don’t do all things by yourself, Lets delegate it

This principle states that don’t all things in yourself, we should write logic to delegate it to respective class.

Example

  •  Event delegation, where an event is delegate to handlers class for handling.
  •  equals() and hashcode() methods compare two objects for equality. Here we ask class inself to do comparison instead of Client class doing that check.

Benefit

  •  No duplication of code.
  •  Pretty easy to modify behaviour.

12 : You Ain’t Gonna Need It (YAGNI)

                 If it’s not in the concept, Not in the code.

YAGNI principle state that we should implement things when we need then never implement things before need them.

Benefit

  • If we violate this principle and write unnecessary code with perception like may required in future then unnecessarily have to take care while maintenance or some change happen.
Architect, RDBMS

CAP Theorem

Leave a comment

Now a days, most of the enterprise based applications are distributed (a collection of interconnected nodes that shared data) over the internet/cloud so that increases the availability of systems. As the application grows and in terms of users and transactions counts and required persistence than big concern is database scalability.

After considering such facts In the year 2000, Eric Brewer developed one theorem that is called as CAP Theorem or Brewer’s conjecture.

CAP Theorem, states that:

“In a distribution system can only have two out of following three Consitentency, Availability, and Partition Tolerance- One of them must be a sacrifice. You can’t promise all three at a time across reading/write requests.”

  • Consistency: Every read request receives the most recent write or an error.
  • Availability: Every request should receive a (non-error) response, without the guarantee that it contains the most recent write.
  • Partition Tolerance: The system continues to work despite an arbitrary number of messages being dropped/delayed by the network between nodes/partitions.

Cap Theorem

In the CAP theorem, consistency is quite different from the ACID database transactions. In distributed systems, partition tolerance means the system will work continue unless there is a complete network failure. If a few nodes fail then the system should keep going.

CAP Theorem Example

You can decide your system technologies based on your primary importance for Consistency, Availability and Partitioning Tolerance. Here we are just taking one example base on database selection:

CA (Consistency + Availability) Type

In this system consistency and availability is primary constraints but such type of system not provide a guarantee of one of the system is offline then the whole system is offline. Otherwise, some of the nodes will not consistent and also not have the latest information.

For Example, Oracle and MySQL are good with Consistency and Availability but not partition tolerant.

CP (Consistency + Partition Tolerant) Type

In this system, consistency and partition tolerance is primary constrains but such a system not provide a guarantee for availability and throws an error as long as the partitioned state not resolved.

For Example, Hadoop and MongoDB stored redundant data in multiple slave nodes and it tolerates an outage of a large number of nodes in the cluster.

AP (Availability + Partition Tolerant) Type

Such a system can not guarantee consistency because if updates can be made to either of a node if some nodes or network issues. This system can have different values on different nodes.

For Example, CouchDB, Dynamo DB, and Cassandra PA type database.

Note CouchDB and Dynamo DB store values in key-value pairs while Cassandra store values in the form of a column family.

See Also:

References

Architect, RDBMS

ACID Properties for Database Transactions

1 Comment

ACID is one of the main concepts or compliance to handle transactions in relational database systems (RDBMS). Full form of the ACID acronym is :

ACID

Here you will know about these concepts in detail:

Atomicity

Each Database transaction must completely succeed or failure/rolled back.

This concept state that partially success not allowed. Each transaction should completely successful or failed. Suppose your transactions have multiple steps (either read or write ) to perform operations in the database then if one operation gets failed then your database will return in the same state it was before starting the transactions.

Consistency

A transaction can not leave the database in an inconsistent state.

This concept state that if your data is replicated across multiple nodes(copies of the database) then these nodes should have the same information.

Isolation

One transaction can not interfere with Others.

This concept state that one client database transactions should not interfere with other client transactions. If one transaction is taking place for the same records then other transactions should wait.

Durability

Completed transactions should persist, even when servers restart etc.

This concept states that once your transaction got completed then this information should not be lost even system is powered off or restart. It should store in nonvolatile storage like the hard drive.

ACID Example

The best example of an ACID is transferring money from one account to another account. There may be two databases with different banks, so this transaction will perform withdrawal from one account while depositing on another account. If one of the steps got failed then return both database state to initial from where get started. The balance should be consistent on all nodes and if someone also performing some transaction at the same time that should be in the waiting state so that it keeps it isolated. If the transaction got completed it should durable by maintaining state in data.

In the case of ACID, other transactions must wait to complete the current transaction. This waiting causes the performance issue. In this case for maintaining consistency and improve performance, the solution is vertical scaling so that getting more get more powerful systems to process each transaction in less time and become available to process other requests.

See Also: