Re: OO, I just don't get it.

From: Tsolak Petrosian (tsolakp_at_yahoo.com)
Date: 12/18/03 

Date: 18 Dec 2003 10:23:43 -0800

<universe@covad.net> wrote in message news:<fe4$3fe0ce0e$97cff003$23803@msgid.meganewsservers.com>...
> "Tsolak Petrosian" <tsolakp@yahoo.com> wrote in message
>
> > <universe@covad.net> wrote in message news:<c1da9$3fdf4caf$3f47e403
>
> > > "Tsolak Petrosian" <tsolakp@yahoo.com> wrote in message
> > > > Knowing about proper approach to any type of project (which I do)
> > > > doesnt mean that any other developer can grast your knowledge very
> > > > well.
>
> > > It *should*.
> > >
> > > In general the proper approach includes facilitating both:
> > > ~ developer<=>client domain expert comms
> > > ~ intra-developer comms
>
> > I agree, but....
>
> > > > Thats why I agree with Costin that for a person with some OO
> knowledge
> > > > its too early
>
> > > You mean for a newbie?
> > >
> > > Dig this excerpted from a book co-authored by one of the GoF:
> > >
> > > WHAT IS A PATTERN?
> > > A pattern is a format, originally developed by Christopher
> Alexander,
> > > that documents the solution to a common problem in a context. An
> expert
> > > in a field can use patterns to document the techniques he has
> learned
> > > that make him an expert. The pattern format helps the author
> document a
> > > technique completely yet concisely. THUS ONE CAN READ THESE
> > > PATTERNS TO QUICKLY LEARN DIRECTLY FROM THE EXPERT.
> > > A pattern has four main parts:
> > > ` Title - The name of the pattern, describing *who* it
> is.
> > > ` Problem - *What* the pattern is designed to solve.
> > > ` Context - The forces and constraints that show *why* the
> > > problem is difficult to solve.
> > > ` Solution - *How* to solve the problem within the given
> context.
> > >
> > > HOW TO READ A PATTERN
> > > You do not necessarily have to read all of the sections in a pattern
> to
> > > gain its benefit. These steps show how to read a pattern quickly
> and
> > > still learn from it:
> > > 1. First, read the problem statement. If it does not sound
> > > interesting to you, skip this pattern.
> > > 2. Next, read the solution. If the solution makes sense, you
> need
> > > not read the rest of the pattern.
> > > 3. For illustrations of the solution, read the examples.
> > > 4. For an explanation of why the solution is appropriate for
> the
> > > problem, read the context.
> > >
> > > So rather than adhere to the same narrowness RCM holds, discouraging
> OO
> > > newbies from reading patterns to learn directly from the expert,
> I'll go
> > >
> > > with the advice of genuine *OO* pattern experts. Especially seeing
> as
> > > how RCM doesn't even strive to generally implement an OO solution,
> by
> > > *his* own words. And Cozianu is strong rejecter of the OO paradigm!
> > > Tsolak, check your company on this. That should *tell* you
> *something*
> > > about the look, feel and bad whiff :- } of where you stand.
>
> > Patterns are basically tips of how to better use already acquired OO
> > knowledge
>
> I prefer:
>
> "Patterns" are a formal way of imparting expert knowledge about how to
> organize and manage *recurring* circumstances involving specific
> circumstances associated with OO design involving recurring kinds of
> domain entities, their class/object abstractions in sw models and code,
> and recurring kinds of collaborations between those domain entities and
> their class/object model abstractions.

Ok, I know that and probably newbie will know that too.

>
> > but doesnt explain why Object, what its and why we need
> > type, why we want to encasulate logic and responsibility into Objects
> > instead of spreading it into functions and so on.
>
> Where did I ever say newbies should learn patterns in lieu of, *instead
> of*, *in the place of* the things you just listed, *and* more.
>
> > That's why developers have to learn and understand those concept and
> > before bothering with patterns
>
> Please run that past me again.
>
> Please tell me precisely what the "That" is "why developers have to
> learn and understand those concepts *before* bothering [hmmm...
> "bothering"? :- [ with patterns.
>
> Tso, Tso, Tso!! Why so, so, so?? :- }
>

Again the "what" is the following.

1. What is the Object.
2. Why object needs to encasulate logic, domain responsibility and
state.
3. Whay Object needs to have type.

> > (thought good developers wont need
> > patterns much since they already encounter them and learn themselves
> > during that long acquiring period).
>
> ?? So a good sw engineer might not learn certain patterns sooner, with
> enhanced all-around alacrity by "pre-reading" Pattern books, catalogs?
>
> Elliott

Thats why I said "wont need patterns much" instead of "wont need
patterns at all".
You learn quite a lot about sw engineering and then read and
understend patterns, and not you read patters and then learn quite a
lot about sw engineering.

Tsolak Petrosian

Relevant Pages

  • Re: Pattern Hierarchy
    ... > Design Patterns you would probably get a million hits. ... one can regard the entire field of Process Engineering as recognizing ... represent frameworks of such patterns. ...
    (comp.object)
  • Re: Have an Opinion? Youre Violating the Law!
    ... Engineering studies are required to be ... Writing an article about mortality ... patterns is not doing medicine without a license. ...
    (misc.transport.road)
  • Re: Tantalum caps
    ... and look for patterns. ... If they see any, they come up to engineering, ... Buy them lunch/beer when they don't make a design error. ...
    (sci.electronics.design)
  • Re: Tantalum caps
    ... John Larkin writes: ... and look for patterns. ... If they see any, they come up to engineering, ... design problems. ...
    (sci.electronics.design)
  • Re: OO, I just dont get it.
    ... relevant role responsible domain entities working together as OO model ... collaborating class/object asbtractions. ... Patterns are simply repeating occurences of class/object collaborations. ...
    (comp.object)