The Single Responsibility Principle - Revision history

Unclebob at 22:01, 9 July 2009

Unclebob — Thu, 09 Jul 2009 22:01:04 GMT

←Older revision		Revision as of 22:01, 9 July 2009
Line 29:		Line 29:
	The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.		The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.

-	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be independently deployed. However, the other classes ''can'' be independently deployed~~; no~~ modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently deployed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a [http://www.amazon.com/dp/0135974445/ different book].	+	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be modified and then independently deployed. However, the other classes ''can'' be modified and independently deployed. No modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently deployed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a [http://www.amazon.com/dp/0135974445/ different book].
-		+

		+	Careful application of the SRP, separating things that change for different reasons, is one if the keys to creating designs that have an independently deploy-able component structure.

Kevlin at 10:41, 9 July 2009

Kevlin — Thu, 09 Jul 2009 10:41:51 GMT

←Older revision		Revision as of 10:41, 9 July 2009
Line 3:		Line 3:
	: Gather together those things that change for the same reason, and separate those things that change for different reasons.		: Gather together those things that change for the same reason, and separate those things that change for different reasons.

-	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.	+	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database:

	public class Employee {		public class Employee {
Line 11:		Line 11:
	}		}

-	Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The <code>calculatePay()</code> function will change whenever the business rules for calculating pay change. The <code>reportHours()</code> function will change whenever someone wants a different format for the report. The <code>save</code> function will change whenever the DBAs change the database schema. These three reasons to change combine to make <code>Employee</code> very volatile. It will change for ''any'' of those reasons. More importantly, any classes that depend upon <code>Employee</code> will be affected by those changes.	+	Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The <code>calculatePay</code> function will change whenever the business rules for calculating pay change. The <code>reportHours</code> function will change whenever someone wants a different format for the report. The <code>save</code> function will change whenever the DBAs change the database schema. These three reasons to change combine to make <code>Employee</code> very volatile. It will change for ''any'' of those reasons. More importantly, any classes that depend upon <code>Employee</code> will be affected by those changes.

	Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if <code>Employee</code> is heavily used by many other classes in other components, then every change to <code>Employee</code> is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).		Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if <code>Employee</code> is heavily used by many other classes in other components, then every change to <code>Employee</code> is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).
Line 29:		Line 29:
	The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.		The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.

-	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be independently deployed. However, the other classes ''can'' be independently deployed; no modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently deployed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book~~. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall)~~.	+	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be independently deployed. However, the other classes ''can'' be independently deployed; no modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently deployed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a [http://www.amazon.com/dp/0135974445/ different book].

Unclebob at 17:21, 18 February 2009

Unclebob — Wed, 18 Feb 2009 17:21:08 GMT

←Older revision		Revision as of 17:21, 18 February 2009
Line 29:		Line 29:
	The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.		The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.

-	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be independently deployed. However, the other classes ''can'' be independently deployed; no modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently ~~employed~~ through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall).	+	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be independently deployed. However, the other classes ''can'' be independently deployed; no modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently deployed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall).

Unclebob at 16:29, 18 February 2009

Unclebob — Wed, 18 Feb 2009 16:29:12 GMT

←Older revision		Revision as of 16:29, 18 February 2009
Line 29:		Line 29:
	The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.		The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.

-	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes and so cannot be independently deployed. However, the other classes ''can'' be independently deployed. Even <code>Employee</code> could be independently employed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall).	+	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes. So if <code>Employee</code> is modified, the other classes will likely have to be recompiled and redeployed. Thus, <code>Employee</code> cannot be independently deployed. However, the other classes ''can'' be independently deployed; no modification of one of them can force any of the others to be recompiled or redeployed. Even <code>Employee</code> could be independently employed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall).

Kevlin at 15:38, 26 November 2008

Kevlin — Wed, 26 Nov 2008 15:38:06 GMT

←Older revision		Revision as of 15:38, 26 November 2008
Line 1:		Line 1:
	One of the most foundational principles of good design is:		One of the most foundational principles of good design is:

-	* Gather together those things that change for the same reason, and separate those things that change for different reasons.	+	: Gather together those things that change for the same reason, and separate those things that change for different reasons.

-	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.	+	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.
-	~~public class Employee {~~	+
-	~~public Money calculatePay();~~	+
-	~~public String reportHours();~~	+
-	~~public void save();~~	+
-	}	+
-	Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The <tt>calculatePay()</tt> function will change whenever the business rules for calculating pay change. The <tt>reportHours()</tt> function will change whenever someone wants a different format for the report. The <tt>save</tt> function will change whenever the DBAs change the database schema. These three reasons to change combine to make <tt>Employee</tt> very volatile. It will change for ''any'' of those reasons. More importantly, any classes that depend upon <tt>Employee</tt> will be affected by those changes.	+

-	~~Good system design means that we separate the system into components that can be independently deployed.~~ Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if <tt>Employee</tt> is heavily used by many other classes in other components, then every change to <tt>Employee</tt> is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).	+	public class Employee {
-	public class Employee {	+	public Money calculatePay() ...
-	public Money calculatePay();	+	public String reportHours() ...
-	}	+	public void save() ...
		+	}

-	~~public~~ class ~~EmployeeReporter {~~	+	Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The <code>calculatePay()</code> function will change whenever the business rules for calculating pay change. The <code>reportHours()</code> function will change whenever someone wants a different format for the report. The <code>save</code> function will change whenever the DBAs change the database schema. These three reasons to change combine to make <code>Employee</code> very volatile. It will change for ''any'' of those reasons. More importantly, any classes that depend upon <code>Employee</code> will be affected by those changes.
-	~~public String~~ reportHours(~~Employee e~~);	+
-	}	+

-	~~public class EmployeeRepository {~~	+	Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if <code>Employee</code> is heavily used by many other classes in other components, then every change to <code>Employee</code> is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).
-	~~public void save(Employee e);~~	+
-	}	+
-	~~The simple partitioning shown above resolves~~ the ~~issues. Each of these classes~~ can be ~~placed in a~~ component of ~~it's own~~. ~~Or rather~~, ~~all the reporting~~ classes ~~can go into~~ the ~~reporting~~ component~~. All~~ the ~~database related classes can go into the repository component. And all the business rules can go into the business rule component~~.	+

-	~~The astute reader will see that there are still dependencies in the above solution.~~ ~~That <tt>~~Employee~~</tt> is still depended upon by the other classes and so cannot be independently deployed~~. ~~However, the other classes ''can'' be independently deployed~~. ~~Even <tt>Employee</tt> could be independently employed through a careful use of the ''Dependency Inversion Principle''~~ (~~DIP~~)~~, but that's a topic for a different book~~. (~~Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall~~).	+	public class Employee {
		+	public Money calculatePay() ...
		+	}
		+
		+	public class EmployeeReporter {
		+	public String reportHours(Employee e) ...
		+	}
		+
		+	public class EmployeeRepository {
		+	public void save(Employee e) ...
		+	}

		+	The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.
		+
		+	The astute reader will see that there are still dependencies in the above solution. That <code>Employee</code> is still depended upon by the other classes and so cannot be independently deployed. However, the other classes ''can'' be independently deployed. Even <code>Employee</code> could be independently employed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall).

Unclebob at 14:41, 26 November 2008

Unclebob — Wed, 26 Nov 2008 14:41:54 GMT

←Older revision		Revision as of 14:41, 26 November 2008
Line 4:		Line 4:

	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.		This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.
-	class X	+	public class Employee {
-	hi	+	public Money calculatePay();
		+	public String reportHours();
		+	public void save();
		+	}
		+	Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The <tt>calculatePay()</tt> function will change whenever the business rules for calculating pay change. The <tt>reportHours()</tt> function will change whenever someone wants a different format for the report. The <tt>save</tt> function will change whenever the DBAs change the database schema. These three reasons to change combine to make <tt>Employee</tt> very volatile. It will change for ''any'' of those reasons. More importantly, any classes that depend upon <tt>Employee</tt> will be affected by those changes.
		+
		+	Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if <tt>Employee</tt> is heavily used by many other classes in other components, then every change to <tt>Employee</tt> is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).
		+	public class Employee {
		+	public Money calculatePay();
		+	}
		+
		+	public class EmployeeReporter {
		+	public String reportHours(Employee e);
		+	}
		+
		+	public class EmployeeRepository {
		+	public void save(Employee e);
		+	}
		+	The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of it's own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.
		+
		+	The astute reader will see that there are still dependencies in the above solution. That <tt>Employee</tt> is still depended upon by the other classes and so cannot be independently deployed. However, the other classes ''can'' be independently deployed. Even <tt>Employee</tt> could be independently employed through a careful use of the ''Dependency Inversion Principle'' (DIP), but that's a topic for a different book. (Cite: Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall).
		+

Unclebob at 14:09, 26 November 2008

Unclebob — Wed, 26 Nov 2008 14:09:19 GMT

←Older revision		Revision as of 14:09, 26 November 2008
Line 4:		Line 4:

	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.		This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.
		+	class X
		+	hi

Unclebob at 14:08, 26 November 2008

Unclebob — Wed, 26 Nov 2008 14:08:12 GMT

←Older revision		Revision as of 14:08, 26 November 2008
Line 1:		Line 1:
		+	One of the most foundational principles of good design is:
		+
		+	* Gather together those things that change for the same reason, and separate those things that change for different reasons.
		+
		+	This principle is often known as the ''Single Responsibility Principle'' or SRP. In short it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is an class that has methods that deal with business rules, reports, and database.
		+
		+
		+

	by [[Uncle Bob]]		by [[Uncle Bob]]

Unclebob: New page: by Uncle Bob This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to 97 Things Every Programmer Should Know home ...

Unclebob — Wed, 26 Nov 2008 13:19:16 GMT

New page: by Uncle Bob This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to 97 Things Every Programmer Should Know home ...

New page

by [[Uncle Bob]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Programmer Should Know]] home page