Joe Bought a new book


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 29

Thread: Joe Bought a new book

  1. #1
    Ted Guest

    Joe Bought a new book


    Joe,

    I see that you have purchased( or borrowed ) the Anti-Patterns book. Ah you
    seem to be quoting much from it these few days. Hmmm. You thought it was
    anti-oo didn't you. Yeah, I know many like you who are anit-oo and bought
    it thinking so. Read all the development anti-patterns that state something
    to the effect of bad OO design.

    Good luck Joe.

  2. #2
    Gregor R. Peisker Guest

    Re: Joe Bought a new book

    Hi Ted,

    > I see that you have purchased( or borrowed ) the Anti-Patterns book. Ah you
    > seem to be quoting much from it these few days. Hmmm. You thought it was
    > anti-oo didn't you. Yeah, I know many like you who are anit-oo and bought
    > it thinking so. Read all the development anti-patterns that state something
    > to the effect of bad OO design.


    your gripe with Joe aside, I would cautiously concur that *some* patterns are
    either about fixing limitations of crippled languages like Java (example: the
    type-safe enum pattern) or are about faking functional programming in an OO
    environment (like some "stateless" designs).

    Regards,
    Gregor





  3. #3
    Ted Guest

    Re: Joe Bought a new book


    >your gripe with Joe aside, I would cautiously concur that *some* patterns

    are
    >either about fixing limitations of crippled languages like Java (example:

    the
    >type-safe enum pattern) or are about faking functional programming in an

    OO
    >environment (like some "stateless" designs).


    I am curious as to why you say Java is crippled? From my understanding Java
    is ripe with design patterns built into the language.

    I don't understand what you mean about faking functional programming. Is
    a stateless design not OO, or can it not be done in an OO manner?



  4. #4
    David Bayley Guest

    Re: Joe Bought a new book

    Ted,

    > I am curious as to why you say Java is crippled? From my understanding

    Java
    > is ripe with design patterns built into the language.


    Since design-patterns are just a dictionary for the design-challenged (IMO),
    which ones are built into Java-the-language?

    --
    David.




  5. #5
    Gregor R. Peisker Guest

    Re: Joe Bought a new book

    Hi Ted,

    > I am curious as to why you say Java is crippled? From my understanding Java
    > is ripe with design patterns built into the language.


    enums are an example (and there are other features Java lacks). Sun argues enums
    are unsafe [refering to C standards], and it seems that for them, the only way
    to fix an unsafe feature is to remove it. But IMO, nothing keeps a language from
    enforcing type safety for enums (like VB.NET does).

    I'm curious as to which design pattern you think are built into Java?

    > I don't understand what you mean about faking functional programming. Is
    > a stateless design not OO, or can it not be done in an OO manner?


    In practice, it seems that a large number of stateless classes are those that
    had better be called "modules". If a class doen't encapsulate anything, what
    does an object of this class stand for? How is one instance of such a class
    differ from another one? I'm not saying that a global function (aka, static
    method) here and there is a bad thing, but that doesn't make a design
    object-oriented.

    Gregor



  6. #6
    Ted Guest

    Re: Joe Bought a new book


    "David Bayley" <dbayley@spamless.aebacus.com> wrote:
    >Ted,
    >
    >> I am curious as to why you say Java is crippled? From my understanding

    >Java
    >> is ripe with design patterns built into the language.

    >
    >Since design-patterns are just a dictionary for the design-challenged (IMO),
    >which ones are built into Java-the-language?
    >
    >--
    >David.
    >


    Design patterns are for the design-challenged? Hmmm. Could I ask what language
    you program in?

    As for java, I said "from my understanding". In the "little" work I have
    done in java it seems that observer, proxy, composite are just a few now
    that I dig in.

    Threading in java is an example. I have been using a class for years(C++)
    that was modeled after the adapter pattern. Well, when I use java threads
    the same principle applies as the class I use now. So you can add adapter
    to that list also. I am not sure as to the implementation of these examples
    but I have read that in the past.


  7. #7
    Ted Guest

    Re: Joe Bought a new book


    >I'm curious as to which design pattern you think are built into Java?

    From my understanding and doing a little work in java I have determined that
    proxy, composite, adapter are just the few that I have seen. As I stated
    in another post, I had written a thread lib that provided an adapter pattern(
    and factory ) around thread creation. In the experimentation I have done
    with threading in java, threading is done in the same manner. I don't know
    the implementation details obviously so this is just an idea that I have
    seen passed around and just from my own personal experience. Off the java
    topic, COM, MFC and ATL are also ripe with Design patterns.


    >I'm not saying that a global function (aka, static
    >method) here and there is a bad thing, but that doesn't make a design
    >object-oriented.


    True. But there are ways to make it OO. Singletons are a great example.


    I am sorry that I am such an advocate of Design patterns and OO but from
    my experience in comparing teams where I have been, those that used OO and
    Design patterns have made it much easier to add enhancements and maintain
    that code base(if done properly). I am not a great designer myself but those
    that "really know" OO can do it in such a manner to make things much easier
    on those that come behind. Plus to reverse engineer code, OO is the only
    way to go. We spend alot of time in reverse engineering so new employees
    do not have to spend months getting up to speed. Try running crappy OO or
    procedural code through the Rose reverse engineering tool and see what you
    come up with.


  8. #8
    Willy Van den Driessche Guest

    Re: Joe Bought a new book




    "Ted" <TTarney@hotmail.com> wrote in message
    news:3ba35ae8$1@news.devx.com...
    >
    > "David Bayley" <dbayley@spamless.aebacus.com> wrote:
    > >Ted,
    > >
    > >> I am curious as to why you say Java is crippled? From my understanding

    > >Java
    > >> is ripe with design patterns built into the language.

    > >
    > >Since design-patterns are just a dictionary for the design-challenged

    (IMO),
    > >which ones are built into Java-the-language?
    > >
    > >--
    > >David.
    > >

    >
    > Design patterns are for the design-challenged? Hmmm. Could I ask what

    language
    > you program in?
    >
    > As for java, I said "from my understanding". In the "little" work I have
    > done in java it seems that observer, proxy, composite are just a few now
    > that I dig in.


    Allthough they made a capital mistake by making java.util.Observable a class
    instead of an interface, thereby making it completely useless.
    You also have factory (using class.forName), decorator (Buffered IO classes)
    and probably just about all of the classic GoF patterns. For a good on
    Patterns in Java read "Patterns in Java" by Mark Grand. It's a volume 1 but
    already it offers other patterns than the 23 GoF patterns. (Remember GoF
    "Design Patterns" was written back in 1995 so in the meantime some others
    have shown up)

    >
    > Threading in java is an example. I have been using a class for years(C++)
    > that was modeled after the adapter pattern. Well, when I use java threads
    > the same principle applies as the class I use now. So you can add adapter
    > to that list also. I am not sure as to the implementation of these

    examples
    > but I have read that in the past.
    > --

    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  9. #9
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Joe Bought a new book

    "Ted" <TTarney@hotmail.com> wrote in message <news:3ba360fb$1@news.devx.com>...

    > >I'm not saying that a global function (aka, static
    > >method) here and there is a bad thing, but that doesn't make a design
    > >object-oriented.

    >
    > True. But there are ways to make it OO. Singletons are a great example.


    Bwahahahaha! So it turns out VB3 was OO after all! Just use private
    data and public subs and functions within modules and call the modules
    "singletons"...

    > I am sorry that I am such an advocate of Design patterns and OO but from
    > my experience in comparing teams where I have been, those that used OO and
    > Design patterns have made it much easier to add enhancements and maintain
    > that code base(if done properly). I am not a great designer myself but those
    > that "really know" OO can do it in such a manner to make things much easier
    > on those that come behind. Plus to reverse engineer code, OO is the only
    > way to go. We spend alot of time in reverse engineering so new employees
    > do not have to spend months getting up to speed. Try running crappy OO or
    > procedural code through the Rose reverse engineering tool and see what you
    > come up with.


    You come up with a load of garbage you'll have to refactor anyway! You
    may have a very few impressive software design books "at your side", but
    have you actually cracked, let alone read, any of them? You give little
    evidence that you have!

    Perhaps it's time for Teddee to buy a new book: _Refactoring: Improving
    the Design of Existing Code_, by Martin Fowler, ISBN (we all know how
    much you love these) 0-201-48567-2, especially after you've bravely ran
    away, away once again from the design.architecture group!

    --
    Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  10. #10
    David Bayley Guest

    Re: Joe Bought a new book

    Ted,

    > Design patterns are for the design-challenged? Hmmm. Could I ask what

    language
    > you program in?


    Java for one. More recently C#.

    > As for java, I said "from my understanding". In the "little" work I have
    > done in java it seems that observer, proxy, composite are just a few now
    > that I dig in.


    The Java API's probably contain examples of every pattern. None of them are
    built into the _language_ though, I think this is where we got our wires
    crossed.

    OO radically changed the way I develop. Reading design patterns is like
    "here's a really simple little design which we call the X-pattern, here is
    another really simple little design which we call the Y-pattern, here is
    another really boring little UML diagram, and so on". I just don't find
    them interesting or helpful at all, other than perhaps as a communication
    tool (or just trying to sound clever!).

    I can only imagine that people who go on about the GoF like they've made
    some major advance in OO development, have difficulties creating these
    simple little designs themselves. But everyone thinks differently, so I'll
    again add that this is just my opinion. Something like eXtreme Programming
    is far more interesting and innovative, and is actually changing the why I
    develop like OO did.

    --
    David.




  11. #11
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Joe Bought a new book

    "David Bayley" <dbayley@spamless.aebacus.com> wrote in message <news:3ba39d70@news.devx.com>...

    > OO radically changed the way I develop. Reading design patterns is like
    > "here's a really simple little design which we call the X-pattern, here is
    > another really simple little design which we call the Y-pattern, here is
    > another really boring little UML diagram, and so on". I just don't find
    > them interesting or helpful at all, other than perhaps as a communication
    > tool (or just trying to sound clever!).


    Formalizing them may have benefits. I'm reminded of the way some people
    deride the database normalization rules as mere "common sense". However,
    it's easier to teach newbies a set of rules than a jumble of half-formed
    "common sense" whimsies. If design patterns, like normalization, can be sufficiently nailed down, perhaps they can also be
    automated.

    > I can only imagine that people who go on about the GoF like they've made
    > some major advance in OO development, have difficulties creating these
    > simple little designs themselves. But everyone thinks differently, so I'll
    > again add that this is just my opinion. Something like eXtreme Programming
    > is far more interesting and innovative, and is actually changing the why I
    > develop like OO did.


    Have you checked out the "Agile Manifesto"? http://agileAlliance.org/

    --
    Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  12. #12
    Willy Van den Driessche Guest

    Re: Joe Bought a new book



    "David Bayley" <dbayley@spamless.aebacus.com> wrote in message
    news:3ba39d70@news.devx.com...
    > Ted,
    >
    > > Design patterns are for the design-challenged? Hmmm. Could I ask what

    > language
    > > you program in?

    >
    > Java for one. More recently C#.
    >
    > > As for java, I said "from my understanding". In the "little" work I

    have
    > > done in java it seems that observer, proxy, composite are just a few now
    > > that I dig in.

    >
    > The Java API's probably contain examples of every pattern. None of them

    are
    > built into the _language_ though, I think this is where we got our wires
    > crossed.

    I would call the class.forName pretty built-in it allows for the factory
    pattern. I would classify java reflection capabilities as a remote
    variation of the interpreter pattern. For the rest you're technically
    right. However, more and more the standard class libraries are of equal
    importance as the language as such.

    >
    > OO radically changed the way I develop. Reading design patterns is like
    > "here's a really simple little design which we call the X-pattern, here is
    > another really simple little design which we call the Y-pattern, here is
    > another really boring little UML diagram, and so on". I just don't find
    > them interesting or helpful at all, other than perhaps as a communication
    > tool (or just trying to sound clever!).


    I cannot imagine that you didn't use the GoF design patterns before. For me
    it did make a change. I was aware of many of them (with the exception of
    visitor). Now that the tricks have got a name life becomes much easier.
    The building blocks for my program design have changed forever. Having a
    new common vocabulary does make a change. The GoF doesn't document the
    patterns as being silver bullets. They just say : we've done our fair
    partof design now and strange enough we find some recurring solutions to
    recurring problems. Let's write them down so that nobody has to re-invent
    the wheel anymore. It's much like you don't write your own sort routine
    anymore. You say "QuickSort " and most people will know what that means.
    That changes a lot.
    Furthermore, don't pinpoint yourself on the 23 GoF patterns. There are many
    more pattern languages and some have nothing to do with program design in
    se. There are some pattern languages describing what seams to be the best
    way to organize programming teams, how to deal with early project leavers,
    how to refactor code, .... They don't all have the same quality but they
    are all attempts to formalize and capture the knowledge we capture when
    doing our business. Computer science is still a very immature business and
    in my opnion it does make a difference to write down the knowledge we do
    capture. Having a common format for this knowledge is more than "just the
    looks". It has to do with the maturity of the "pattern" itself. If your
    are able to write it down in the pattern format, then chances are that you
    sufficiently understand the forces and the solutions. The context and
    forces give you a clue as to when to use design pattern. The solution
    gives a proposed solution. It's OK to disaggree with the solution. After
    all we're all just learning along the way.
    I would really recommend reading "Pattern Hatching" by J. Vlissides. It's
    sort of "the making of", but not in a hollywood style. (discusses
    Generation Gap, which I happen to have used before too) There's plenty of
    other reading on patterns I'd like to recommend but I guess if you don't
    like patterns there's little use.

    >
    > I can only imagine that people who go on about the GoF like they've made
    > some major advance in OO development, have difficulties creating these
    > simple little designs themselves. But everyone thinks differently, so

    I'll
    > again add that this is just my opinion. Something like eXtreme

    Programming
    > is far more interesting and innovative, and is actually changing the why I
    > develop like OO did.


    Innovation is exactly what patterns are not about. Since they describe
    proven techniques, they can hardly be big revolutions.
    BTW, XP has exactly the same roots as the pattern community (Beck /
    Cunnignham et al). Almost all of XP is not new either. It just feels
    good - to me at least- to hear somebody say that. (I always seem to be on
    projects where people are really serious about up-front complete analysis -
    it has never worked) The recommendations for doing XP are also kind of a
    pattern in themselves. If you want to do this (write medium-sized programs
    with fuzzy requirements) then do this (use XP). It's just a pattern
    language and I would doubt i Beck didn't know that.
    >
    > --
    > David.
    >
    >
    >


    See you,
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  13. #13
    Ted Guest

    Re: Joe Bought a new book


    >OO radically changed the way I develop. Reading design patterns is like
    >"here's a really simple little design which we call the X-pattern, here

    is
    >another really simple little design which we call the Y-pattern, here is
    >another really boring little UML diagram, and so on". I just don't find
    >them interesting or helpful at all, other than perhaps as a communication
    >tool (or just trying to sound clever!).


    Design patterns are supposed to be simple. The idea is to view something
    and see if it fits. Other than the Singleton pattern I have never used any
    of the patterns as is. They are a starting point and sprout new ideas as
    we continue on.


    >again add that this is just my opinion. Something like eXtreme Programming
    >is far more interesting and innovative, and is actually changing the why

    I
    >develop like OO did.


    Actually XP is not that innovative. Kent Beck took the best of some paradigms
    and grouped it all into 1 great idea. There are some issues with XP that
    I do have problems with and that's the reason we have a modified version
    that we have adopted. Pair programming for one doesn't go over to well with
    Senior level engineers.

  14. #14
    Ted Guest

    Re: Joe Bought a new book


    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    >"Ted" <TTarney@hotmail.com> wrote in message <news:3ba360fb$1@news.devx.com>...
    >
    >> >I'm not saying that a global function (aka, static
    >> >method) here and there is a bad thing, but that doesn't make a design
    >> >object-oriented.

    >>
    >> True. But there are ways to make it OO. Singletons are a great example.

    >
    >Bwahahahaha! So it turns out VB3 was OO after all! Just use private
    >data and public subs and functions within modules and call the modules
    >"singletons"...
    >


    OK Joe, I will say that I am VB naive, but how do you get a construct like
    "static" in VB?

    >You come up with a load of garbage you'll have to refactor anyway! You
    >may have a very few impressive software design books "at your side", but
    >have you actually cracked, let alone read, any of them? You give little
    >evidence that you have!
    >

    Actually I have quite a few. Let's see Joe, Grady Booch - Chief Scientist,
    Joe "Dumbass" - Local Moron. Which one do I take advice from.


    >Perhaps it's time for Teddee to buy a new book: _Refactoring: Improving
    >the Design of Existing Code_, by Martin Fowler, ISBN (we all know how
    >much you love these) 0-201-48567-2, especially after you've bravely ran
    >away, away once again from the design.architecture group!
    >


    Sorry Joe I am an innovator. I am not a sustaining engineer. I analyze,
    design and code only new projects. Sustaining is for the junior guys to
    do. When they come and ask me about my code and my design I leave them knowing
    that they can confidently take over.

    As for the design.architecture group, can I ask what you are referring to?I
    seem to remember you being told "AGAIN" to cut the crap. I WILL SAY IT AGAIN,
    when the talk gets technical you burry your head and run. But just to make
    sure, I will go there now and try and see what you are talking about.



  15. #15
    Gregor R. Peisker Guest

    Re: Joe Bought a new book

    Hi Ted,

    > I am sorry that I am such an advocate of Design patterns and OO but from
    > my experience in comparing teams where I have been, those that used OO and
    > Design patterns have made it much easier to add enhancements and maintain
    > that code base(if done properly). I am not a great designer myself but those
    > that "really know" OO can do it in such a manner to make things much easier
    > on those that come behind. Plus to reverse engineer code, OO is the only
    > way to go. We spend alot of time in reverse engineering so new employees
    > do not have to spend months getting up to speed. Try running crappy OO or
    > procedural code through the Rose reverse engineering tool and see what you
    > come up with.


    My standard for a good design is not patterns compliance. There are good
    patterns in the books, there are also useful patterns that aren't in the books.
    I don't mean to sound anti design pattern. I just don't equate OO with the
    classic design patterns that are found in the books. Neither are an end in
    themselves, although object orientation wins out most of the time over the
    functional approach.

    Here's what I think matters: I try to make my classes well encapsulated (which
    accounts for a lot already, IMO). Certain algorithms and business rules need to
    be implement correctly. I think about how I could use a class again, whether and
    how it can be inherited, which other classes it works with. It's worth
    minimizing dependencies on other components. Just how to factor in a way to
    specialize the design later. It's also important that a class (or a group of
    classes) can be used as easily as possible, while providing flexibility - even
    without inheritance. Often, I try to provide a functionality so that in can be
    used in different ways. A consistent error handling strategy is crucial. The
    data model needs consideration.

    Then, a lot really depends on the task at hand. If I (have to) use a certain
    framework, this will sure be influential. For example, I'm currently playing
    arround with wrapping up the functionality provided in the Vsa namespace. The
    fact that that there exists the IVsaHost interface (used for callbacks, for
    example wiring up named event sources and global objects with the appropriate
    instances) already determines what I have to do, and what I might want to save
    the client from doing. Clearly, patterns aren't solely decisive here.

    On a final note, back to the purpose of my original response: In most Java
    designs I've seen, there are about 3 static methods for every instance method,
    which is a clear indication of functional programming in OO disguise. This is
    why I believe that a few simple rules (for fixing crappy designs), tailered
    toward achieving encapsulation, polymorphism and inheritance can do more for the
    ultimate goal of solid, reuseable software than a rigit following of design
    patterns (which might be useful for those who already get 90 per cent of their
    design right).

    Gregor



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center