tutorials/introduction/src/docs/background.txt - polygene-java - Git at Google

 ///////////////////////////////////////////////////////////////
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
  * regarding copyright ownership.  The ASF licenses this file
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
  *
  *   http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing,
  * software distributed under the License is distributed on an
  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  * KIND, either express or implied.  See the License for the
  * specific language governing permissions and limitations
  * under the License.
 ///////////////////////////////////////////////////////////////

 [[introduction-background,Background]]
 = Background =
 Zest™ is the first Composite Oriented Programming implementation leveraging the Java 5 platform, so that everything you
 know from Java 5 still applies. You can mix Zest™ with your ordinary Java code as much as you want. All your existing
 Java tools works just like before, and Zest™ does not introduce any new programming language, no special development
 tools needed and no XML is required.

 == Purpose ==
 Zest™ addresses the programming problems from the top-down, starting with the Domain Model and Business Rules needs,
 and let those requirements flow downwards in the software stack and dictate the requirements for underlying layers
 such as persistence, messaging, querying and more. This means that the business value developer is left to
 concentrate on the domain models and the actual application bringing the value, instead of creating massive amounts
 of glue code to tie underlying technologies together.

 == Problem Descriptions ==
 Zest™ didn't appear out of the blue, when the founders of the project had nothing better to do. It is the result of
 observation of problems in real applications, and the experience from previous attempts to address or correct these
 problems, that has led to the Zest™ vision.

 == Object Oriented Programming (OOP) ==
 How can OOP be a problem? We and others have observed that there is a fundamental flaw in the OOP model. In fact, we
 would like to even state that OOP as it is commonly practiced today is not object oriented at all. The object is not
 the primary citizen, instead the class is the primary artifact. In most mainstream OOP languages, Objects are derived
 from classes, not that classes are assigned to created objects. Therefore, we think it should have been called Class
 Oriented Programming. We can also see this class focus in many of the technologies in Java today: in Spring you declare
 class names in application contexts, JSP uses class names to declare beans and so forth.

 This in turn leads to that there is no good OOP solution for the problem we describe below.

 == Behavior depends on Context ==
 Once you start thinking of "Behavior depends on Context", you have a hard time understanding how people for the last 20
 years or so of Object Oriented Programming (OOP) has ignored this fact.

 === Who am I? ===
 When I sitting in front of the computer, I am a software developer, but if I go out in the jungle, I am suddenly
 hunter-gatherer and prey. A large set of me is the same, but my interaction with the surroundings, i.e. the context, is
 very different. I need different interfaces, so to speak, in these two different contexts.

 Now, the above example is perhaps a bit extreme, but we see it in everyday life of the developer. When an object is
 stored in the database it is of a different class, than when it is transported to the client and possibly when it is
 displayed in the GUI. We see the effect of this problem in many of the design patterns and so called "best practices"
 in Java EE development. Facades, delegation, data transport objects and many more.

 == Coupling ==
 The OOP proponents once proclaimed that classes can be re-used, since the code is encapsulated with the class, so the
 class is an independent unit which lends itself well to re-use. In reality, however, we have found that classes becomes
 tightly coupled with many other classes in their neighborhood, leading to impossibilities of single class re-use. Many
 tricks are introduced to minimize the "Coupling Hell", such as Inversion of Control and Dependency Injection. Although
 those tools are good, the underlying problem remains.

 Why do we end up with large coupled class network graphs?

 Essentially, it boils down to "scope". Classes are too large, their scope is too large, and for each small functional
 unit within the class, there will be additional coupling to other classes. And this often progresses to the full
 boundary of the entire domain the class remains in.

 == Application layer impedance mismatch ==
 Almost all technologies used in modern software development, starts by looking at an infrastructural problem and try to
 solve that the best way. This is often done in a vacuum and layers on top will be struggling to map or translate the
 solution into the higher abstraction, and the higher up we get, the harder it becomes to ignore the assumptions,
 problems and limitations of the underlying technologies. It is also common that the underlying technologies "bleeds"
 through the layers all the way into the domain models. The "bleed" combined with the problem of using independently
 developed technologies, puts a large burden on the application developer, whose job it is to bring business value. And
 often, the most skilled developers end up doing the bottom layers, leaving the hardest job to the least suitable.
 Another interesting consequence is that each layer needs to anticipate every single use-case - real, potential or
 perceived - and deal with it in a specifiable and useful manner. This leads to overly complex solutions, compared to if
 the system is built from the top layer down, where each layer beneath knows exactly what is expected from it, and only
 needs to handle those use-cases.

 == Abstracting away meaning. ==
 To paraphrase a famous proverb about a hammer: "If all you have are objects, everything looks like a dependency."
 We think that increasing abstraction often also increases complexity, and that the abstraction benefits are somewhat
 linear whereas the complexity negatives are exponential. So, our conclusion is that by making no distinction between
 different kinds of objects, many sound technologies run into incredibly difficult problems. The implementation of the
 programming platform (e.g. Java) is of course easier to implement with a hefty amount of scope reduction into as few as
 possible abstractions. But that is not the situation for the user. The abstraction is then required to be reversed when
 the rubber hits the road, e.g. ORM mapping must be declared explicitly by the programmer, often using separate tools
 and languages.

 == Solution ==
 We think the solution was expressed more than 2500 years ago, first by Indian scholars and slightly later by Leucippus
 and Democritus. We are of course talking about atoms, and by using really small building blocks, we can express
 arbitrarily complex structures.
 By reducing the classes into what we in Composite Oriented Programming call Fragments, we limit the coupling network
 graph substantially. Re-use of Fragments becomes a reality, and by combination of Fragments, we compose larger
 structures, the Composites.

 == Composition ==
 Composite Oriented Programming also view the object, we call it the Composite instance, as the first class citizen. The
 Composite instance can be cast to any context, meaning a different behavior can be applied to the Composite instance,
 without affecting its underlying state. And back. This in turn means that we can for instance create a
 ServerContextualInvoiceEntity, transport that across to a client, cast it to a GuiContextualInvoiceEntity do the
 modifications to the underlying state, possibly using extra interfaces and methods for interacting with the GUI
 environment, and then transport the modified object back to the server, cast it back to the
 ServerContextualInvoiceEntity, and then persist the changes.

 == Domain Driven Design focus ==
 Composite Oriented Programming is heavily influenced by the book "Domain Driven Design" by Eric Evans. And we are
 trying to use his analysis of the problem to provide the mechanisms needed to get the job done quicker and more
 reliably. Mr Evans talks about Applications, Layers, Modules, Specifications, SideEffects and so forth, and all of
 these should be present in a Composite Oriented Programming implementation, and to a large extent it is in Zest™.
	///////////////////////////////////////////////////////////////
	* Licensed to the Apache Software Foundation (ASF) under one
	* or more contributor license agreements. See the NOTICE file
	* distributed with this work for additional information
	* regarding copyright ownership. The ASF licenses this file
	* to you under the Apache License, Version 2.0 (the
	* "License"); you may not use this file except in compliance
	* with the License. You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing,
	* software distributed under the License is distributed on an
	* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	* KIND, either express or implied. See the License for the
	* specific language governing permissions and limitations
	* under the License.
	///////////////////////////////////////////////////////////////

	[[introduction-background,Background]]
	= Background =
	Zest™ is the first Composite Oriented Programming implementation leveraging the Java 5 platform, so that everything you
	know from Java 5 still applies. You can mix Zest™ with your ordinary Java code as much as you want. All your existing
	Java tools works just like before, and Zest™ does not introduce any new programming language, no special development
	tools needed and no XML is required.

	== Purpose ==
	Zest™ addresses the programming problems from the top-down, starting with the Domain Model and Business Rules needs,
	and let those requirements flow downwards in the software stack and dictate the requirements for underlying layers
	such as persistence, messaging, querying and more. This means that the business value developer is left to
	concentrate on the domain models and the actual application bringing the value, instead of creating massive amounts
	of glue code to tie underlying technologies together.

	== Problem Descriptions ==
	Zest™ didn't appear out of the blue, when the founders of the project had nothing better to do. It is the result of
	observation of problems in real applications, and the experience from previous attempts to address or correct these
	problems, that has led to the Zest™ vision.

	== Object Oriented Programming (OOP) ==
	How can OOP be a problem? We and others have observed that there is a fundamental flaw in the OOP model. In fact, we
	would like to even state that OOP as it is commonly practiced today is not object oriented at all. The object is not
	the primary citizen, instead the class is the primary artifact. In most mainstream OOP languages, Objects are derived
	from classes, not that classes are assigned to created objects. Therefore, we think it should have been called Class
	Oriented Programming. We can also see this class focus in many of the technologies in Java today: in Spring you declare
	class names in application contexts, JSP uses class names to declare beans and so forth.

	This in turn leads to that there is no good OOP solution for the problem we describe below.

	== Behavior depends on Context ==
	Once you start thinking of "Behavior depends on Context", you have a hard time understanding how people for the last 20
	years or so of Object Oriented Programming (OOP) has ignored this fact.

	=== Who am I? ===
	When I sitting in front of the computer, I am a software developer, but if I go out in the jungle, I am suddenly
	hunter-gatherer and prey. A large set of me is the same, but my interaction with the surroundings, i.e. the context, is
	very different. I need different interfaces, so to speak, in these two different contexts.

	Now, the above example is perhaps a bit extreme, but we see it in everyday life of the developer. When an object is
	stored in the database it is of a different class, than when it is transported to the client and possibly when it is
	displayed in the GUI. We see the effect of this problem in many of the design patterns and so called "best practices"
	in Java EE development. Facades, delegation, data transport objects and many more.

	== Coupling ==
	The OOP proponents once proclaimed that classes can be re-used, since the code is encapsulated with the class, so the
	class is an independent unit which lends itself well to re-use. In reality, however, we have found that classes becomes
	tightly coupled with many other classes in their neighborhood, leading to impossibilities of single class re-use. Many
	tricks are introduced to minimize the "Coupling Hell", such as Inversion of Control and Dependency Injection. Although
	those tools are good, the underlying problem remains.

	Why do we end up with large coupled class network graphs?

	Essentially, it boils down to "scope". Classes are too large, their scope is too large, and for each small functional
	unit within the class, there will be additional coupling to other classes. And this often progresses to the full
	boundary of the entire domain the class remains in.

	== Application layer impedance mismatch ==
	Almost all technologies used in modern software development, starts by looking at an infrastructural problem and try to
	solve that the best way. This is often done in a vacuum and layers on top will be struggling to map or translate the
	solution into the higher abstraction, and the higher up we get, the harder it becomes to ignore the assumptions,
	problems and limitations of the underlying technologies. It is also common that the underlying technologies "bleeds"
	through the layers all the way into the domain models. The "bleed" combined with the problem of using independently
	developed technologies, puts a large burden on the application developer, whose job it is to bring business value. And
	often, the most skilled developers end up doing the bottom layers, leaving the hardest job to the least suitable.
	Another interesting consequence is that each layer needs to anticipate every single use-case - real, potential or
	perceived - and deal with it in a specifiable and useful manner. This leads to overly complex solutions, compared to if
	the system is built from the top layer down, where each layer beneath knows exactly what is expected from it, and only
	needs to handle those use-cases.

	== Abstracting away meaning. ==
	To paraphrase a famous proverb about a hammer: "If all you have are objects, everything looks like a dependency."
	We think that increasing abstraction often also increases complexity, and that the abstraction benefits are somewhat
	linear whereas the complexity negatives are exponential. So, our conclusion is that by making no distinction between
	different kinds of objects, many sound technologies run into incredibly difficult problems. The implementation of the
	programming platform (e.g. Java) is of course easier to implement with a hefty amount of scope reduction into as few as
	possible abstractions. But that is not the situation for the user. The abstraction is then required to be reversed when
	the rubber hits the road, e.g. ORM mapping must be declared explicitly by the programmer, often using separate tools
	and languages.

	== Solution ==
	We think the solution was expressed more than 2500 years ago, first by Indian scholars and slightly later by Leucippus
	and Democritus. We are of course talking about atoms, and by using really small building blocks, we can express
	arbitrarily complex structures.
	By reducing the classes into what we in Composite Oriented Programming call Fragments, we limit the coupling network
	graph substantially. Re-use of Fragments becomes a reality, and by combination of Fragments, we compose larger
	structures, the Composites.

	== Composition ==
	Composite Oriented Programming also view the object, we call it the Composite instance, as the first class citizen. The
	Composite instance can be cast to any context, meaning a different behavior can be applied to the Composite instance,
	without affecting its underlying state. And back. This in turn means that we can for instance create a
	ServerContextualInvoiceEntity, transport that across to a client, cast it to a GuiContextualInvoiceEntity do the
	modifications to the underlying state, possibly using extra interfaces and methods for interacting with the GUI
	environment, and then transport the modified object back to the server, cast it back to the
	ServerContextualInvoiceEntity, and then persist the changes.

	== Domain Driven Design focus ==
	Composite Oriented Programming is heavily influenced by the book "Domain Driven Design" by Eric Evans. And we are
	trying to use his analysis of the problem to provide the mechanisms needed to get the job done quicker and more
	reliably. Mr Evans talks about Applications, Layers, Modules, Specifications, SideEffects and so forth, and all of
	these should be present in a Composite Oriented Programming implementation, and to a large extent it is in Zest™.