-
Notifications
You must be signed in to change notification settings - Fork 0
/
introduction-background.html
127 lines (108 loc) · 14.5 KB
/
introduction-background.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Background</title><link rel="stylesheet" href="css/style.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="" /><link rel="up" href="intro.html" title="Introduction" /><link rel="prev" href="intro.html" title="Introduction" /><link rel="next" href="what-is-cop.html" title="What is COP?" />
<!-- favicon -->
<link rel="shortcut icon" href="http://qi4j.org/favicon.ico" type="image/vnd.microsoft.icon" />
<link rel="icon" href="http://qi4j.org/favicon.ico" type="image/x-icon" />
<!-- style -->
<link href="css/shCore.css" rel="stylesheet" type="text/css" />
<link href="css/shCoreEclipse.css" rel="stylesheet" type="text/css" />
<link href="css/shThemeEclipse.css" rel="stylesheet" type="text/css" />
<link href="css/qi4j.css" rel="stylesheet" type="text/css" />
<!-- Syntax Highlighter -->
<script type="text/javascript" src="js/shCore.js"></script>
<script type="text/javascript" src="js/shBrushJava.js"></script>
<script type="text/javascript" src="js/shBrushScala.js"></script>
<script type="text/javascript" src="js/shBrushJScript.js"></script>
<script type="text/javascript" src="js/shBrushBash.js"></script>
<script type="text/javascript" src="js/shBrushPlain.js"></script>
<script type="text/javascript" src="js/shBrushXml.js"></script>
<script type="text/javascript" src="js/shBrushGroovy.js"></script>
<script type="text/javascript" src="js/shBrushPython.js"></script>
<script type="text/javascript" src="js/shBrushRuby.js"></script>
<script type="text/javascript" src="js/shBrushCSharp.js"></script>
<script type="text/javascript">
SyntaxHighlighter.defaults['tab-size'] = 4;
SyntaxHighlighter.defaults['gutter'] = false;
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all()
</script>
<!-- JQuery -->
<script type="text/javascript" src="js/jquery-1.6.4.min.js"></script>
<!-- Image Scaler -->
<script type="text/javascript" src="js/imagescaler.js"></script>
<!-- Table Styler -->
<script type="text/javascript" src="js/tablestyler.js"></script>
<!-- Qi4j WebSite Progressive Enhancement -->
<link href="css/progressive-enhancement.css" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="js/jquery.scrollTo-1.4.2.js"></script>
<script type="text/javascript" src="js/progressive-enhancement.js"></script>
<!-- Analytics -->
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-3118496-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
</head><body><div xmlns="" xmlns:exsl="http://exslt.org/common" class="logo"><a href="index.html"><img src="images/logo-standard.png" /></a></div><div xmlns="" xmlns:exsl="http://exslt.org/common" class="top-nav"><div xmlns="http://www.w3.org/1999/xhtml" class="toc"><dl><dt><span class="section"><a href="index.html#home">Qi4j</a></span></dt><dt><span class="section"><span xmlns="" href="intro.html">Introduction</span></span></dt><dt><span class="section"><a href="tutorials.html">Tutorials</a></span></dt><dt><span class="section"><a href="javadocs.html">Javadoc</a></span></dt><dt><span class="section"><a href="samples.html">Samples</a></span></dt><dt><span class="section"><a href="core.html">Core</a></span></dt><dt><span class="section"><a href="libraries.html">Libraries</a></span></dt><dt><span class="section"><a href="extensions.html">Extensions</a></span></dt><dt><span class="section"><a href="tools.html">Tools</a></span></dt><dt><span class="section"><a href="glossary.html">Glossary </a></span></dt></dl></div></div><div xmlns="" xmlns:exsl="http://exslt.org/common" class="sub-nav"><div xmlns="http://www.w3.org/1999/xhtml" class="toc"><dl><dt><span class="section"><a href="intro.html#highlights">Highligts</a></span></dt><dt><span class="section"><span xmlns="" href="introduction-background.html">Background</span></span></dt><dt><span class="section"><a href="what-is-cop.html">What is COP?</a></span></dt><dt><span class="section"><a href="qi4j-cop.html">COP with Java and Qi4j</a></span></dt><dt><span class="section"><a href="what-s-an-object-anyway.html">What’s an Object anyway?</a></span></dt><dt><span class="section"><a href="state-modeling.html">Qi4j and state modeling</a></span></dt><dt><span class="section"><a href="related.html">Related publications & projects</a></span></dt></dl></div></div><div class="section" title="Background"><div class="titlepage"><div><div><h3 class="title"><a id="introduction-background"></a>Background</h3></div></div></div><p>Qi4j 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 Qi4j with your ordinary Java code as much as you want. All your existing
Java tools works just like before, and Qi4j does not introduce any new programming language, no special development
tools needed and no XML is required.</p><div class="section" title="Purpose"><div class="titlepage"><div><div><h4 class="title"><a id="_purpose"></a>Purpose</h4></div></div></div><p>Qi4j 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.</p></div><div class="section" title="Problem Descriptions"><div class="titlepage"><div><div><h4 class="title"><a id="_problem_descriptions"></a>Problem Descriptions</h4></div></div></div><p>Qi4j 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 Qi4j vision.</p></div><div class="section" title="Object Oriented Programming (OOP)"><div class="titlepage"><div><div><h4 class="title"><a id="_object_oriented_programming_oop"></a>Object Oriented Programming (OOP)</h4></div></div></div><p>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.</p><p>This in turn leads to that there is no good OOP solution for the problem we describe below.</p></div><div class="section" title="Behavior depends on Context"><div class="titlepage"><div><div><h4 class="title"><a id="_behavior_depends_on_context_2"></a>Behavior depends on Context</h4></div></div></div><p>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.</p><div class="section" title="Who am I?"><div class="titlepage"><div><div><h5 class="title"><a id="_who_am_i"></a>Who am I?</h5></div></div></div><p>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.</p><p>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.</p></div></div><div class="section" title="Coupling"><div class="titlepage"><div><div><h4 class="title"><a id="_coupling"></a>Coupling</h4></div></div></div><p>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.</p><p>Why do we end up with large coupled class network graphs?</p><p>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.</p></div><div class="section" title="Application layer impedance mismatch"><div class="titlepage"><div><div><h4 class="title"><a id="_application_layer_impedance_mismatch"></a>Application layer impedance mismatch</h4></div></div></div><p>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.</p></div><div class="section" title="Abstracting away meaning."><div class="titlepage"><div><div><h4 class="title"><a id="_abstracting_away_meaning"></a>Abstracting away meaning.</h4></div></div></div><p>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.</p></div><div class="section" title="Solution"><div class="titlepage"><div><div><h4 class="title"><a id="_solution"></a>Solution</h4></div></div></div><p>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.</p></div><div class="section" title="Composition"><div class="titlepage"><div><div><h4 class="title"><a id="_composition"></a>Composition</h4></div></div></div><p>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.</p></div><div class="section" title="Domain Driven Design focus"><div class="titlepage"><div><div><h4 class="title"><a id="_domain_driven_design_focus"></a>Domain Driven Design focus</h4></div></div></div><p>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 Qi4j.</p></div></div><div xmlns="" xmlns:exsl="http://exslt.org/common" class="footer">(c) 2012 The Qi4j Community</div></body></html>