[ajug-members] design

[Wilson, Jeff]

Right. I thought of that same thing only after I posted last night.

 

Barclay, I think you are getting caught up in the formal definition of
your classes, and not just working to solve your problem. Start by
adding only the data and methods you need to solve the immediate
problem. Get that part working, then attack the next problem. Continue
until your entire system is done. At this point, you may find your
Student has no firstName attribute, but so what? The application works.

 

 

+jeff (MJW) 

--- 

"The pure and simple truth is rarely pure and never simple." 

-- Oscar Wilde 

--------------------------------------------- 

M. Jeff Wilson, Lead Member Technical Staff 

AT&T Services, Inc. 

Operations & Service Dev 

jw9615 at att.com 

+1 404.499.7235 

From: Alan Honeycutt [mailto:alan.n.honeycutt at gmail.com] 
Sent: Thursday, February 19, 2009 3:41 PM
To: ajug-members at ajug.org
Subject: Re: [ajug-members] design

 

In other words, start with the simplest thing that could possibly work
and only increase complexity when the system has proven that it's
needed.

On Thu, Feb 19, 2009 at 3:08 PM, Wilson, Jeff <jw9615 at att.com> wrote:

You stop when the model is sufficient for your problem domain.

Reuse is most often a red-herring -- you probably will not reuse a
Person class developed for a College registration system in a Patient
care system. The domains are different; so will the behavior and the
data.

Don't think of it as modeling. You're not trying to model the real
world, that has higgs-boson particles or quantum foam. You're trying to
model a (for example) Student registering for classes. The software
model for Student registration doesn't care if the Student has three
heads, is cold-blooded, or has malarial. It only cares if the Student
has an Address, a Student Number, and $3500 per quarter.

+jeff (MJW)
---

"The first 90% of the code accounts for the first 90% of the development
time. The remaining 10% of the code accounts for the other 90% of the
development time."
     -- Ninety-Ninety Rule

---------------------------------------------
M. Jeff Wilson, Lead Member Technical Staff
AT&T Services, Inc.
Operations & Service Dev
jw9615 at att.com
+1 404.499.7235

-----Original Message-----
From: 521 [mailto:521 at ofig.org]
Sent: Thursday, February 19, 2009 11:20 AM
To: ajug-members at ajug.org
Subject: Re: [ajug-members] design

cool, tks jeff
>>The methods are considered to be the behavior of the object.
-i get freaked out, hehe, and then get no-where-
when i write stuff down on paper before i type-out classes in a simple
'math'
game or a simple 'dog-walking' game; i get very-darn caught up in how
deep do
i go?  i find my mind arguing with itself on how far do i break down an
object into the parts (for future use, code-reuse) it is made up of; say
a
person's hand,
wrist/hand/finger/hair/finger-nail/bone/joint/vein/blood/blood-
flow/blood-cell/cell-division/hand-shake/snap-fingers/thumb's-up/thumb's
-
down/shoot-bird/fingernail-growth/broken-finger/heal/cell-division/skin-
cancer/make-a-fist/finger-smashed-in-door/wooooh-nilly/ doe!  -a class
is
blueprint of blueprints down to the higgs-boson, the derivation of
mass/matter itself

barclay


On Thu, 19 Feb 2009 10:32:04 -0500, Wilson, Jeff wrote
> In general, the accepted way most people look at objects are that they
> are the "nouns". Methods that work on the objects are the "verbs".
> Systems are built by having a network of objects that invoke methods
on
> each other.
>
> Some nouns will be concepts in your business domain or problem space.
> Other nouns are computer science concepts like sessions, transactions,
> threads, etc.
>
> That is an incredibly simplified view of the world of OO. It misses a
> lot of good design practices, conventions, and so many other concepts
> that I can't list here, but I will list some other crucial points:
>
> Objects represent a concept and have methods that conceptually map
onto
> those concepts.
>
> Objects contain data that are needed to support that concept.
>
> The methods are considered to be the behavior of the object.
>
> The data in an object should not be exposed to the rest of the
> application unless that exposure is a part of the concept. (Arguably,
> most classes should not contain getter or setter methods for their
> fields, and all fields should be private.)
>
> I assume you are comfortable with procedural code, in which you've got
a
> bunch of functions and pass around data structures between them.
Robert
> Martin, in his book _Clean Code_, makes this statement about the
> differences between procedural and OO code:
>
> "Procedural code makes it easy to add new functions without changing
the
> existing data structures. OO code, on the other hand, makes it
possible
> to add new classes without changing any existing function.
>
> "Procedural code makes it hard to add new data structures because all
> the functions must change. OO code makes it hard to add new functions
> because all the classes must change."
>
> +jeff (MJW)
> ---
>
> "The first 90% of the code accounts for the first 90% of the
development
> time. The remaining 10% of the code accounts for the other 90% of the
> development time."
>      -- Ninety-Ninety Rule
>
> ---------------------------------------------
> M. Jeff Wilson, Lead Member Technical Staff
> AT&T Services, Inc.
> Operations & Service Dev
> jw9615 at att.com
> +1 404.499.7235
>
> -----Original Message-----
> From: 521 [mailto:521 at ofig.org]
> Sent: Monday, February 16, 2009 10:04 AM
> To: ajug-members at ajug.org
> Subject: [ajug-members] design
>
> by design, in java- or oop in general- is it best to have classes made
> as follows...
>
>  -certain classes are designed to be the motors or engines of an
> application
>  -certain classes are designed to the the nouns/subjects of the
> application
>  -other classes, maybe, some other stuff, etc?
>
> barclay
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>
> *****
>
> The information transmitted is intended only for the person or entity
to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use
of, or taking of any action in reliance upon this information by persons
or
entities other than the intended recipient is prohibited. If you
received
this in error, please contact the sender and delete the material from
all
computers. GA621
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members


_______________________________________________
ajug-members mailing list
ajug-members at ajug.org
http://www.ajug.org/mailman/listinfo/ajug-members

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA623



_______________________________________________
ajug-members mailing list
ajug-members at ajug.org
http://www.ajug.org/mailman/listinfo/ajug-members

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20090220/d9922c37/attachment-0001.html