Contribution 50 - Revision history

Elandre: /* Never ever break the encapsulation */

2008-06-12T13:14:36Z

Never ever break the encapsulation

←Older revision		Revision as of 13:14, 12 June 2008
Line 1:		Line 1:
	==Never ever break the encapsulation==		==Never ever break the encapsulation==
-	In systems theory containment is one of the most useful constructs when dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood, and its supported by programming language constructs such as subroutine, function, module, package, object (class) ~~and agent~~.	+	In systems theory containment is one of the most useful constructs when dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood, and its supported by programming language constructs such as subroutine, function, module, package, object (class).

-	~~Agents, modules~~ and ~~packages~~ addresses the larger scale needs for encapsulation, while object, subroutine and function addresses the more fine granular aspects of the matter. Over the years I have discovered that objects seams to be one of the hardest encapsulation constructs for developers to get right. It's not seldom you find a class with one single 3000 line main method, or a class with only set and get methods for its primitive attributes. These examples illustrates basically that the developers involved has never understood object oriented thinking, and the power of objects as modeling constructs.	+	Module and package addresses the larger scale needs for encapsulation, while object, subroutine and function addresses the more fine granular aspects of the matter. Over the years I have discovered that objects seams to be one of the hardest encapsulation constructs for developers to get right. It's not seldom you find a class with one single 3000 line main method, or a class with only set and get methods for its primitive attributes. These examples illustrates basically that the developers involved has never understood object oriented thinking, and the power of objects as modeling constructs.

-	An object encapsulates state and behavior ~~related to its~~ state, and ~~designing with objects~~ boils down to two simple tasks: '''allocation''' and '''delegation''' of responsibility to the different objects~~. This is best illustrated by an example. Lets say we have three objects, ''customer'', ''order'' and ''item''. The ''customer'' object is~~ the ~~natural placeholder of the credit limit and credit validation rules. The ''order''~~ object knows about its associated customer, and its ''addItem(item)'' operation delegates the actual credit check by calling ''customer.validateCredit(item.price())''. If the post condition for the method fails, an exception is thrown and the purchase is aborted. This approach of organizing your code is in line with the principles of the Domain Model pattern described by Martin Fowler in his book Patterns of Enterprise Application Architecture [PEAA].	+	An object encapsulates both state and behavior, where the behavior is defined by the actual state. Think of the object door, it has four states: closed, open, closing, opening. It provide two operations: open and close. Dependent of state the open and close operations will behave differently. This inherent property of an object makes the design process conceptual simple. It boils down to two simple tasks: '''allocation''' and '''delegation''' of responsibility to the different objects including the inter-object interaction protocols.

-	A less experienced object oriented developer might decide to wrap all the business rules into an object very often referred to as order-manager or order-service. In these designs ''order'', ''customer'' and ''item'' are treated as records and all logic is factored out of the objects and tied together in one single method. These designs are in line with the Transactional script pattern [PEAA], a pattern I found more an anti-pattern than a pattern for developers working in object oriented programming languages. The reason: It breaks the encapsulation and results in non maintainable code. To illustrate the problem lets extend our small system with more functionality. Customers are classified as gold, silver and basic members, and different discounts are given on that basis. Extend the discount rules to include family size, hair color, car make. Think then about what happens with the maintainability of your code. What initially started out as a 50 line script method has become 2000 lines inter tangled unmaintainable code.	+	How this works in practice is best illustrated by an example. Lets say we have three objects, ''customer'', ''order'' and ''item''. The ''customer'' object is the natural placeholder of the credit limit and credit validation rules. The ''order'' object knows about its associated customer, and its ''addItem(item)'' operation delegates the actual credit check by calling ''customer.validateCredit(item.price())''. If the post condition for the method fails, an exception is thrown and the purchase is aborted. This approach of organizing your code is in line with the principles of the Domain Model pattern described by Martin Fowler in his book Patterns of Enterprise Application Architecture [PEAA].
		+
		+	A less experienced object oriented developer might decide to wrap all the business rules into an object very often referred to as order-manager or order-service. In these designs ''order'', ''customer'' and ''item'' are treated as records and all logic is factored out of the objects and tied together in one single method. These designs are in line with the Transactional script pattern [PEAA], a pattern I found more as an anti-pattern than a pattern for developers working in object oriented programming languages. The reason: It breaks the encapsulation and results in non maintainable code. To illustrate the problem lets extend our small system with more functionality. Customers are classified as gold, silver and basic members, and different discounts are given on that basis. Extend the discount rules to include family size, hair color, car make. Think then about what happens with the maintainability of your code. What initially started out as a 50 line script method has become 2000 lines inter tangled unmaintainable code.

	Following the Domain Model approach, extending the ''customer'' object with a ''discount()'' method while maintaining a consistent allocation of responsibility would have made things simple. With the new method in place the ''order'' objects ''close()'' method could have obtained the correct discount without knowing anything about membership levels and other discount rules encapsulated by the ''customer'' object.		Following the Domain Model approach, extending the ''customer'' object with a ''discount()'' method while maintaining a consistent allocation of responsibility would have made things simple. With the new method in place the ''order'' objects ''close()'' method could have obtained the correct discount without knowing anything about membership levels and other discount rules encapsulated by the ''customer'' object.

Elandre: /* Never ever break the encapsulation */

2008-06-11T14:09:26Z

Never ever break the encapsulation

←Older revision		Revision as of 14:09, 11 June 2008
Line 1:		Line 1:
	==Never ever break the encapsulation==		==Never ever break the encapsulation==
-	In ~~the~~ systems theory containment ~~a.k.a. the "poached egg" model~~ is one of the most useful constructs dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood, and its supported by programming language constructs such as ~~subroutines~~, ~~functions~~, ~~modules~~, ~~packages~~, ~~objects~~ (class) and ~~even agents~~.	+	In systems theory containment is one of the most useful constructs when dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood, and its supported by programming language constructs such as subroutine, function, module, package, object (class) and agent.

-	Agents, modules and packages addresses ~~most often~~ the larger scale needs for encapsulation, while ~~objects~~, ~~subroutines~~ and ~~functions are most often associated with~~ the more fine granular aspects of the matter. Over the years I have discovered that objects seams to be one of the hardest encapsulation constructs for developers to get right. It's not seldom you find a class with one single 3000 line main method, or a class with only set and get methods for its primitive attributes. These examples illustrates basically that the developers has never understood object oriented thinking, and the power of objects as modeling constructs.	+	Agents, modules and packages addresses the larger scale needs for encapsulation, while object, subroutine and function addresses the more fine granular aspects of the matter. Over the years I have discovered that objects seams to be one of the hardest encapsulation constructs for developers to get right. It's not seldom you find a class with one single 3000 line main method, or a class with only set and get methods for its primitive attributes. These examples illustrates basically that the developers involved has never understood object oriented thinking, and the power of objects as modeling constructs.

-	An object encapsulates state and behavior related to its state, and designing with objects boils down to two simple tasks: allocation and delegation of responsibility to the different objects. Lets say we have three objects, customer, order and item. The customer object is the natural placeholder of the credit limit and credit validation rules. The order object knows about its associated customer, and its addItem(item) operation delegates the actual credit check by calling customer.validateCredit(item.price()). If the post condition for the method fails, an exception is thrown and the purchase ~~operation~~ is aborted. This approach of organizing your code is in line with the principles of the Domain Model pattern described in Martin Fowler's book, Patterns of Enterprise Application Architecture.	+	An object encapsulates state and behavior related to its state, and designing with objects boils down to two simple tasks: '''allocation''' and '''delegation''' of responsibility to the different objects. This is best illustrated by an example. Lets say we have three objects, ''customer'', ''order'' and ''item''. The ''customer'' object is the natural placeholder of the credit limit and credit validation rules. The ''order'' object knows about its associated customer, and its ''addItem(item)'' operation delegates the actual credit check by calling ''customer.validateCredit(item.price())''. If the post condition for the method fails, an exception is thrown and the purchase is aborted. This approach of organizing your code is in line with the principles of the Domain Model pattern described by Martin Fowler in his book Patterns of Enterprise Application Architecture [PEAA].

-	A less experienced object oriented developer might decide to wrap all the business rules into an object very often referred to as order-manager or order-service. In these designs order, customer and item are treated as records and all logic is factored out of the objects and tied together in one single method. ~~This design is~~ in line with the Transactional script pattern, a pattern ~~this is~~ more an anti-pattern than a pattern. It breaks the encapsulation and results in non maintainable code. To illustrate the problem lets extend our small system with more functionality. ~~The customers~~ are classified as gold, silver and basic members, and different discounts are given on that basis. Extend ~~functionality further and add~~ discount rules ~~that not only is derived from member status~~, ~~but from how many children the customer got and so on~~. Think about what happens with the maintainability of your code. What initially started out as a 50 line script method has become 2000 lines inter tangled unmaintainable code.	+	A less experienced object oriented developer might decide to wrap all the business rules into an object very often referred to as order-manager or order-service. In these designs ''order'', ''customer'' and ''item'' are treated as records and all logic is factored out of the objects and tied together in one single method. These designs are in line with the Transactional script pattern [PEAA], a pattern I found more an anti-pattern than a pattern for developers working in object oriented programming languages. The reason: It breaks the encapsulation and results in non maintainable code. To illustrate the problem lets extend our small system with more functionality. Customers are classified as gold, silver and basic members, and different discounts are given on that basis. Extend the discount rules to include family size, hair color, car make. Think then about what happens with the maintainability of your code. What initially started out as a 50 line script method has become 2000 lines inter tangled unmaintainable code.

-	~~Refactoring your objects~~, extending ~~them~~ with ~~new methods and~~ maintaining a consistent allocation of responsibility would have made things simple. ~~The customer object could have been extended with a discount~~ method~~, and the~~ the order objects close() ~~operation would~~ have obtained the correct discount without knowing anything about membership levels ~~or any~~ other discount rules ~~associated with~~ the customer object.	+	Following the Domain Model approach, extending the ''customer'' object with a ''discount()'' method while maintaining a consistent allocation of responsibility would have made things simple. With the new method in place the ''order'' objects ''close()'' method could have obtained the correct discount without knowing anything about membership levels and other discount rules encapsulated by the ''customer'' object.

-	So in the end, never break the encapsulation.	+	So in the end, never break the encapsulation, and use the power of your favorite object oriented language to maintain it.

Elandre: /* Never ever break the encapsulation */

2008-06-10T23:10:06Z

Never ever break the encapsulation

←Older revision		Revision as of 23:10, 10 June 2008
Line 1:		Line 1:
	==Never ever break the encapsulation==		==Never ever break the encapsulation==
-	~~Placeholder for thoughts~~	+	In the systems theory containment a.k.a. the "poached egg" model is one of the most useful constructs dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood, and its supported by programming language constructs such as subroutines, functions, modules, packages, objects (class) and even agents.

		+	Agents, modules and packages addresses most often the larger scale needs for encapsulation, while objects, subroutines and functions are most often associated with the more fine granular aspects of the matter. Over the years I have discovered that objects seams to be one of the hardest encapsulation constructs for developers to get right. It's not seldom you find a class with one single 3000 line main method, or a class with only set and get methods for its primitive attributes. These examples illustrates basically that the developers has never understood object oriented thinking, and the power of objects as modeling constructs.
		+
		+	An object encapsulates state and behavior related to its state, and designing with objects boils down to two simple tasks: allocation and delegation of responsibility to the different objects. Lets say we have three objects, customer, order and item. The customer object is the natural placeholder of the credit limit and credit validation rules. The order object knows about its associated customer, and its addItem(item) operation delegates the actual credit check by calling customer.validateCredit(item.price()). If the post condition for the method fails, an exception is thrown and the purchase operation is aborted. This approach of organizing your code is in line with the principles of the Domain Model pattern described in Martin Fowler's book, Patterns of Enterprise Application Architecture.
		+
		+	A less experienced object oriented developer might decide to wrap all the business rules into an object very often referred to as order-manager or order-service. In these designs order, customer and item are treated as records and all logic is factored out of the objects and tied together in one single method. This design is in line with the Transactional script pattern, a pattern this is more an anti-pattern than a pattern. It breaks the encapsulation and results in non maintainable code. To illustrate the problem lets extend our small system with more functionality. The customers are classified as gold, silver and basic members, and different discounts are given on that basis. Extend functionality further and add discount rules that not only is derived from member status, but from how many children the customer got and so on. Think about what happens with the maintainability of your code. What initially started out as a 50 line script method has become 2000 lines inter tangled unmaintainable code.
		+
		+	Refactoring your objects, extending them with new methods and maintaining a consistent allocation of responsibility would have made things simple. The customer object could have been extended with a discount method, and the the order objects close() operation would have obtained the correct discount without knowing anything about membership levels or any other discount rules associated with the customer object.
		+
		+	So in the end, never break the encapsulation.

Elandre at 09:02, 10 June 2008

2008-06-10T09:02:31Z

←Older revision		Revision as of 09:02, 10 June 2008
Line 1:		Line 1:
	==Never ever break the encapsulation==		==Never ever break the encapsulation==
	Placeholder for thoughts		Placeholder for thoughts
		+
		+
		+
		+	By [[Einar Landre]]
		+
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+	Back to [[97 Things Every Software Architect Should Know]] home page

Elandre: New page: ==Never ever break the encapsulation== Placeholder for thoughts

2008-06-10T09:01:20Z

New page: ==Never ever break the encapsulation== Placeholder for thoughts

New page

==Never ever break the encapsulation==
Placeholder for thoughts