polygene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nic...@apache.org
Subject [56/57] [abbrv] polygene-java git commit: docs: fix some spelling and grammar errors
Date Thu, 21 Dec 2017 07:12:49 GMT
docs: fix some spelling and grammar errors

Project: http://git-wip-us.apache.org/repos/asf/polygene-java/repo
Commit: http://git-wip-us.apache.org/repos/asf/polygene-java/commit/5ed239cf
Tree: http://git-wip-us.apache.org/repos/asf/polygene-java/tree/5ed239cf
Diff: http://git-wip-us.apache.org/repos/asf/polygene-java/diff/5ed239cf

Branch: refs/heads/develop
Commit: 5ed239cf039c3badd77ef6a0c78a173bcfc467e0
Parents: b4f6be8
Author: Tom Saleeba <tom.saleeba@gmail.com>
Authored: Thu Dec 21 15:43:12 2017 +1030
Committer: GitHub <noreply@github.com>
Committed: Thu Dec 21 15:43:12 2017 +1030

----------------------------------------------------------------------
 tutorials/introduction/src/docs/highlights.txt | 33 ++++++++++-----------
 1 file changed, 16 insertions(+), 17 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/polygene-java/blob/5ed239cf/tutorials/introduction/src/docs/highlights.txt
----------------------------------------------------------------------
diff --git a/tutorials/introduction/src/docs/highlights.txt b/tutorials/introduction/src/docs/highlights.txt
index cee3d78..2717218 100644
--- a/tutorials/introduction/src/docs/highlights.txt
+++ b/tutorials/introduction/src/docs/highlights.txt
@@ -26,7 +26,7 @@ Composite Oriented Programming builds on some principles that are not addressed
 
 * Behavior depends on Context
 * Decoupling is a virtue
-* Business Rules matters more.
+* Business Rules matter more.
 * Classes are dead, long live interfaces.
 
 === Behavior Depends on Context ===
@@ -35,10 +35,10 @@ Many objects has life cycles that are more extensive than the simple model
that
 us to believe. A few simple examples;
 
 * An egg becomes a chicken which in turn becomes food.
-* I am a programmer at work, a father+husband at home, a victim in a traffic accident and
hunter and pray in the jungle.
+* I am a programmer at work, a father+husband at home, a victim in a traffic accident and
hunter and prey in the jungle.
 
-But it is more to it than that. The composition of the object may change over time. My home
now has a garage and my car
-have different kind of problems with their own state related to it.
+But there is more to it than that. The composition of the object may change over time. My
home now has a garage and my car
+has different kinds of problems, each with their own state related to it.
 
 In the programming world, we are constantly faced with change of requirements. These changes
are often not related to
 any real world changes, but people coming to new insights of the problem domain. OOP makes
those changes a big deal,
@@ -46,8 +46,8 @@ and often we have to tear up large chunks of the model and redo the work.
 
 But wait, there is more.
 
-Some objects traverses different scope boundaries to the extreme. For instance, a Person
will have its attributes
-changing slightly over time, new abilities be learnt and so forth, that is mentioned above.
But the Person will
+Some objects traverse different scope boundaries to the extreme. For instance, a Person will
have its attributes
+changing slightly over time, new abilities will be learnt and so forth, that is mentioned
above. The Person will
 eventually die, but that doesn't mean that the Person object should be deleted from a system,
since the "memory of"
 that Person may live on for a long time. In a OOP system, we would need to transfer some
of the state from a
 LivingPerson class to a DeadPerson class. In Composite Oriented Programming, it is the same
object with different
@@ -59,24 +59,23 @@ one or many classes are assigned.
 
 === Decoupling is Virtue ===
 
-Decoupling is more important than developers in general think. If you could have every OOP
class decoupled from all
+Decoupling is more important than developers generally think. If you could have every OOP
class decoupled from all
 other classes, it is easy to re-use that class. But when that class references another class
and the chain never ends,
-your chances of re-use diminishes quickly.
+your chances of re-use diminish quickly.
 
 Object Oriented Programming is suffering a lot from this, and many mechanisms have been introduced
over time to counter
-this problem. But in reality, the best we can manage is subsystems of functionality, which
client code can re-use. And
-these subsystems tend to be infrastructure related, since domain models are less prone to
be similar enough from one
-project to the next, and since OOP in reality constrains the the re-use of individual domain
classes, we need to re-do
-the domain model from scratch ever time.
+this problem. In reality, the best we can manage is subsystems of functionality, which client
code can re-use. These subsystems tend to be infrastructure related, since domain models are
less prone to be similar enough from one
+project to the next. Since OOP in reality constrains the the re-use of individual domain
classes, we need to re-do
+the domain model from scratch every time.
 
-=== Business Rules matters more ===
+=== Business Rules matter more ===
 
-Smart developers often think that low-level, infrastructure and framework code is more important
and more cool to work
-with, than the simple domain model. But in reality, it is the Domain Model that reflects
the actual need  and pays the
+Smart developers often think that low-level, infrastructure and framework code is more important
and cooler to work
+with than the simple domain model. In reality, it is the Domain Model that reflects the actual
needs and pays the
 bills. Infrastructure is just a necessary evil to get things done.
 
-If most developers could focus on the Business Rules and Domain Model, and not having to
worry about any infrastructure
-issues, such as persistence, transactions, security or the framework housing it all, the
productivity would surge. Eric
+If most developers could focus on the Business Rules and Domain Model, and not have to worry
about any infrastructure
+issues, such as persistence, transactions, security or the framework housing it all, then
productivity would surge. Eric
 Evans has written an excellent book about Domain Driven Design, where he goes through the
real process that makes the
 money for companies. However, it is very hard to follow that book, since one is constantly
caught up in constraints
 irrelevant to the domain model, introduced by the underlying framework, from the so called
smart developers.


Mime
View raw message