Standard Design and Development Methodologies

Discussion in 'Java' started by Novice, Nov 19, 2011.

  1. Novice

    Novice Guest

    I have a very general question that isn't really even specific to Java but
    I'd appreciate your thoughts on this.

    I'm a Java hobbyist. I've been writing code in Java for a while because I
    like the language but haven't really used current standard design and
    programming methodologies in a formal way to develop my code, sticking to
    older methodologies that I learned long ago, like structured programming
    and structured design. I'm thinking of trying to get paying work as a full-
    time employee in a company using Java but I think I'm going to have to
    acquire some new skills to be a credible candidate for a junior position in
    systems development.

    What are the standard design and development methodologies being used in
    systems departments these days and, ideally, where can I find tutorials for
    them, preferably free and online?

    I expect that I will have to get at least a working knowledge of a bunch of
    things, including OO Design, Patterns, and a dozen other things to have any
    chance but, as a Chinese philosopher once said "a journey of a thousand
    miles begins with a single step". I'd appreciate your help in building a
    list of the things that someone like your employer would want met to have
    before considering me for a junior position writing Java.

    --
    Novice
     
    Novice, Nov 19, 2011
    #1
    1. Advertising

  2. Novice

    Arne Vajhøj Guest

    On 11/19/2011 2:42 PM, Novice wrote:
    > I have a very general question that isn't really even specific to Java but
    > I'd appreciate your thoughts on this.
    >
    > I'm a Java hobbyist. I've been writing code in Java for a while because I
    > like the language but haven't really used current standard design and
    > programming methodologies in a formal way to develop my code, sticking to
    > older methodologies that I learned long ago, like structured programming
    > and structured design. I'm thinking of trying to get paying work as a full-
    > time employee in a company using Java but I think I'm going to have to
    > acquire some new skills to be a credible candidate for a junior position in
    > systems development.
    >
    > What are the standard design and development methodologies being used in
    > systems departments these days and, ideally, where can I find tutorials for
    > them, preferably free and online?
    >
    > I expect that I will have to get at least a working knowledge of a bunch of
    > things, including OO Design, Patterns, and a dozen other things to have any
    > chance but, as a Chinese philosopher once said "a journey of a thousand
    > miles begins with a single step". I'd appreciate your help in building a
    > list of the things that someone like your employer would want met to have
    > before considering me for a junior position writing Java.


    OOA/OOD/OOP + design patters seems to be what to focus on.

    GoF book
    Code Complete
    Applying UML and Patterns/Larman
    Effective Java/Bloch

    could be useful books to study.

    Arne
     
    Arne Vajhøj, Nov 20, 2011
    #2
    1. Advertising

  3. On 11-11-19 03:42 PM, Novice wrote:
    > I have a very general question that isn't really even specific to Java but
    > I'd appreciate your thoughts on this.
    >
    > I'm a Java hobbyist. I've been writing code in Java for a while because I
    > like the language but haven't really used current standard design and
    > programming methodologies in a formal way to develop my code, sticking to
    > older methodologies that I learned long ago, like structured programming
    > and structured design. I'm thinking of trying to get paying work as a full-
    > time employee in a company using Java but I think I'm going to have to
    > acquire some new skills to be a credible candidate for a junior position in
    > systems development.
    >
    > What are the standard design and development methodologies being used in
    > systems departments these days and, ideally, where can I find tutorials for
    > them, preferably free and online?
    >
    > I expect that I will have to get at least a working knowledge of a bunch of
    > things, including OO Design, Patterns, and a dozen other things to have any
    > chance but, as a Chinese philosopher once said "a journey of a thousand
    > miles begins with a single step". I'd appreciate your help in building a
    > list of the things that someone like your employer would want met to have
    > before considering me for a junior position writing Java.
    >

    You could probably do worse than to read
    http://en.wikipedia.org/wiki/Software_development_methodology. This is
    of value primarily because it introduces a lot of common terminology.

    Ultimately _every_ software development methodology (SDM) boils down to:

    1. requirements analysis - understanding what the client needs you to do;
    2. analysis & design - how you intend to meet those needs. See
    http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
    we are talking Java, for general concepts;
    3. implementation - actually write code;
    4. testing - ensuring that your code, as written, satisfies the
    requirements;
    5. maintenance - nurturing the application over its lifespan.

    How all the various approaches differ is how they break up and sequence
    these activities. What really matters is that all these activities are
    important.

    It's probably best not to fixate on any given methodology. Just learn up
    on the highlights of each, and keep in mind that all of them ultimately
    boil down to requiring competence in the same skills. You'd be
    interested initially in object-oriented analysis (OOA), object-oriented
    design (OOD), and how to test your code (starting with unit testing and
    perhaps functional testing).

    Like Arne suggested, "Effective Java" by Bloch is a great book. So is
    "Code Complete". IMO I wouldn't bother buying a copy of the GOF design
    patterns book; borrow from a university library or locate a decent
    website instead. Read some Martin Fowler
    (http://martinfowler.com/intro.html). Don't get hung up on specific
    methodologies (did I say that already?) - no project ever succeeded or
    failed just because of what methodology a team used. Get some
    familiarity with UML but don't go overboard with it.

    My own specific suggestion - read
    http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
    also a good author). CRC is not just useful in agile.

    If your understanding of persistence (databases) is not solid - in your
    estimation, bone up on that.

    If you don't have one already, select another OO programming language to
    learn. You can make a lot more headway in learning all of the above if
    you're not tied to one specific language. Just my opinion.

    AHS
    --
    You should know the problem before you try to solve it.
    Example: When my son was three he cried about a problem with his hand. I
    kissed it several times and asked him about the problem. He peed on his
    hand.
    -- Radia Perlman, inventor of spanning tree protocol
     
    Arved Sandstrom, Nov 20, 2011
    #3
  4. Novice

    Lew Guest

    Arved Sandstrom wrote:
    > Novice wrote:
    >> What are the standard design and development methodologies being used in
    >> systems departments these days and, ideally, where can I find tutorials for
    >> them, preferably free and online?
    >>

    > You could probably do worse than to read
    > http://en.wikipedia.org/wiki/Software_development_methodology. This is
    > of value primarily because it introduces a lot of common terminology.
    >
    > Ultimately _every_ software development methodology (SDM) boils down to:
    >
    > 1. requirements analysis - understanding what the client needs you to do;
    > 2. analysis & design - how you intend to meet those needs. See
    > http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
    > we are talking Java, for general concepts;
    > 3. implementation - actually write code;
    > 4. testing - ensuring that your code, as written, satisfies the
    > requirements;
    > 5. maintenance - nurturing the application over its lifespan.
    >
    > How all the various approaches differ is how they break up and sequence
    > these activities. What really matters is that all these activities are
    > important.


    There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.

    Its main conclusion, after a very neutral overview of the extant pet theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.

    As such an individual (as you should be, too), I have a toolbox of ways to look at a programming assignment - a kit of ontologies.

    First and most fundamental skill - to look it up. Whatever the unfamiliar concept or skill, there is never an expert enough who's patient enough withtime enough and communication talent enough to explain it for you. You have to be able to do with fragments of advice (at best) and what you discover for yourself - through hard, hard study and very pragmatic experimentation. A former mentor of mine trained me that any IT person spending less than 20% over and above their normal work time to study and practice was doomed to fall behind.

    'Struth.

    As for ontologies, the most useful ones I know are event-driven programming, object-oriented programming, MVC (model-view-controller), layers (Law of Demeter), and "noun-and-verb" modeling. That last is my own term for usingthe language of the problem domain (its nouns and verbs) to define your program structures.

    There's one style trick that induces better code: Keep it short. After about 500 lines of code and comment (yes, and comment) your class should feeltoo large, and after about 700-800 lines you should be castigating yourself.

    The pressure to keep it short helps you think more clearly about structure.

    And there's one mandatory, cross-methodology practice: Javadoc the shit out of your code. Document private and package-private methods and all static variables down to private. The extra asterisk at the start of the comment block hurts nothing.

    Don't use specious comments, the kind that repeat what the code already says:

    for (Foo foo : bunchOfFoos) // operate on each of the Foos

    Pfeh! If a person doesn't know what a for-each loop is, such a comment will not rescue them.

    Do liberally comment anything that makes a maintainer go, "Hmm."

    // volatile: thread calling close() might not be same as called perform()
    private volatile boolean isStopping;

    This advice might not fit your idea of what constitutes a "methodology", but for Pete's sake, think. What does that "ology" suffix buy you but buzzword compliance? The real need is for a _method_, a process by which you canproduce effective, reliable, correct software on time to spec. In the endit's all about your personal commitment and skill.

    --
    Lew
     
    Lew, Nov 20, 2011
    #4
  5. Novice

    Lew Guest

    Lew wrote:
    > There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.


    http://www.google.com/search?q=ISBN 013590126X

    --
    Lew
     
    Lew, Nov 20, 2011
    #5
  6. On 19/11/2011 11:13 PM, Lew wrote:

    > As for ontologies, the most useful ones I know are event-driven
    > programming, object-oriented programming, MVC (model-view-controller),
    > layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
    > own term for using the language of the problem domain (its nouns and
    > verbs) to define your program structures.


    That last is also known as "programming in Lisp". ;)
     
    Derek K. Wodenhouse, Nov 20, 2011
    #6
  7. Novice

    Lew Guest

    Derek K. Wodenhouse wrote:
    > Lew wrote:
    >> As for ontologies, the most useful ones I know are event-driven
    >> programming, object-oriented programming, MVC (model-view-controller),
    >> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
    >> own term for using the language of the problem domain (its nouns and
    >> verbs) to define your program structures.

    >
    > That last is also known as "programming in Lisp". ;)


    Trivially, since the technique applies irrespective of platform.

    It's also known as "programming in /X/", where /X/ is any programming language.

    Thank you for your useful observation.

    --
    Lew
     
    Lew, Nov 20, 2011
    #7
  8. On 20/11/2011 2:45 AM, Lew wrote:
    > Derek K. Wodenhouse wrote:
    >> Lew wrote:
    >>> As for ontologies, the most useful ones I know are event-driven
    >>> programming, object-oriented programming, MVC (model-view-controller),
    >>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
    >>> own term for using the language of the problem domain (its nouns and
    >>> verbs) to define your program structures.

    >>
    >> That last is also known as "programming in Lisp". ;)

    >
    > Trivially, since the technique applies irrespective of platform.
    >
    > It's also known as "programming in /X/", where /X/ is any programming language.


    Not nearly as strongly. Lisps let you reify nearly any program
    abstraction, and build a bridge from the solution domain to the problem
    domain, expressing most of the business logic in problem domain terms. A
    common program design in another language consists of a problem domain
    focused library, plus an application layer atop that that contains the
    business logic but is still largely written in solution domain terms,
    with a sprinkling of problem domain nouns and verbs. A common program
    design in Lisp consists of a domain-specific language for the problem
    domain, in Lisp, and an application in that language with a sprinkling
    of generic-Lisp nouns and verbs (mostly lists and data structure
    traversals, and/or numbers and arithmetic -- much of which might be
    regarded as present also in the problem domain).
     
    Derek K. Wodenhouse, Nov 20, 2011
    #8
  9. On 11/20/2011 09:49 AM, Derek K. Wodenhouse wrote:
    > On 20/11/2011 2:45 AM, Lew wrote:
    >> Derek K. Wodenhouse wrote:
    >>> Lew wrote:
    >>>> As for ontologies, the most useful ones I know are event-driven
    >>>> programming, object-oriented programming, MVC (model-view-controller),
    >>>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
    >>>> own term for using the language of the problem domain (its nouns and
    >>>> verbs) to define your program structures.
    >>>
    >>> That last is also known as "programming in Lisp". ;)

    >>
    >> Trivially, since the technique applies irrespective of platform.
    >>
    >> It's also known as "programming in /X/", where /X/ is any programming
    >> language.

    >
    > Not nearly as strongly. Lisps let you reify nearly any program
    > abstraction, and build a bridge from the solution domain to the problem
    > domain, expressing most of the business logic in problem domain terms. A
    > common program design in another language consists of a problem domain
    > focused library, plus an application layer atop that that contains the
    > business logic but is still largely written in solution domain terms,
    > with a sprinkling of problem domain nouns and verbs. A common program
    > design in Lisp consists of a domain-specific language for the problem
    > domain, in Lisp, and an application in that language with a sprinkling
    > of generic-Lisp nouns and verbs (mostly lists and data structure
    > traversals, and/or numbers and arithmetic -- much of which might be
    > regarded as present also in the problem domain).


    It's also pretty easy to create DSL's in - say Ruby - so Lisp is not
    unique with respect to that. One can go even further and call any Java
    library (in fact, _any_ library) a domain specific language. The
    difference with Lisp is that it's basic syntax is trivial (sexpr) and it
    has Macros which can make special forms look like regular function calls
    by which means you can do things in this language which you cannot (or
    not as easily) in others.

    Kind regards

    robert
     
    Robert Klemme, Nov 20, 2011
    #9
  10. On 11-11-20 12:13 AM, Lew wrote:
    > Arved Sandstrom wrote:
    >> Novice wrote:
    >>> What are the standard design and development methodologies being used in
    >>> systems departments these days and, ideally, where can I find tutorials for
    >>> them, preferably free and online?
    >>>

    >> You could probably do worse than to read
    >> http://en.wikipedia.org/wiki/Software_development_methodology. This is
    >> of value primarily because it introduces a lot of common terminology.
    >>
    >> Ultimately _every_ software development methodology (SDM) boils down to:
    >>
    >> 1. requirements analysis - understanding what the client needs you to do;
    >> 2. analysis & design - how you intend to meet those needs. See
    >> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
    >> we are talking Java, for general concepts;
    >> 3. implementation - actually write code;
    >> 4. testing - ensuring that your code, as written, satisfies the
    >> requirements;
    >> 5. maintenance - nurturing the application over its lifespan.
    >>
    >> How all the various approaches differ is how they break up and sequence
    >> these activities. What really matters is that all these activities are
    >> important.

    >
    > There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.
    >
    > Its main conclusion, after a very neutral overview of the extant pet theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.
    >

    [ SNIP good stuff ]

    I hesitated to start talking about methods/"methodologies" in my first
    post, since it was getting lengthy. Or as you've phrased it, key
    features of successful methodologies. However I would agree that an
    iterative approach is most suitable for most projects.

    In that regard I'd caution the OP that waterfall is still popular and
    common, and that a lot of shops advertise that they are iterative+agile
    when in fact they are doing more, and smaller, waterfall projects. It's
    not quite the same thing.

    On the subject of "an individual who maintains the project architecture
    and structures in his/her own mind", this often won't correspond to
    titles or labels (like "architect"). Another way of looking at it is
    that you should have an individual who is the "coordinator", who can
    guide and plan the work of the individual domain experts - the developers.

    AHS
    --
    You should know the problem before you try to solve it.
    Example: When my son was three he cried about a problem with his hand. I
    kissed it several times and asked him about the problem. He peed on his
    hand.
    -- Radia Perlman, inventor of spanning tree protocol
     
    Arved Sandstrom, Nov 20, 2011
    #10
  11. Novice

    spk Guest

    Patricia Shanahan <>, wrote:
    >On 11/19/2011 8:49 PM, Derek K. Wodenhouse wrote:
    >> On 19/11/2011 11:13 PM, Lew wrote:
    >>
    >>> As for ontologies, the most useful ones I know are event-driven
    >>> programming, object-oriented programming, MVC (model-view-controller),
    >>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
    >>> own term for using the language of the problem domain (its nouns and
    >>> verbs) to define your program structures.

    >>
    >> That last is also known as "programming in Lisp". ;)

    >
    >Why do you feel it is limited to Lisp? It seems to me to be generally
    >useful, regardless of the programming language. It is certainly useful
    >for design of Java programs.
    >
    >Patricia


    From: thoolen <>
    Newsgroups: comp.lang.java.programmer
    Subject: Re: toward null-safe cookie cutter Comparators
    Followup-To: comp.os.os2.advocacy
    Date: Fri, 18 Nov 2011 15:21:25 -0500
    Organization: thingamajig
    Message-ID: <ja6eo9$boj$>
    References: <>
    <>
    <>
    <kudwq.20012$> <ja0t5t$kms$>
    <4ec5471f$0$22559$c3e8da3$>
    <14715296.1119.1321552560149.JavaMail.geo-discussion-forums@prnv30>
    <4ec54bae$0$22559$c3e8da3$>
    <>
    <23591489.9.1321566539494.JavaMail.geo-discussion-forums@prap37>
    <4ec63f7e$-privat.org>
    NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org

    From: kensi <>
    Newsgroups: comp.lang.java.programmer
    Subject: Re: toward null-safe cookie cutter Comparators
    Date: Thu, 17 Nov 2011 21:21:34 -0500
    Organization: SICN
    Message-ID: <ja4ffe$h7k$>
    References: <>
    <>
    <>
    <kudwq.20012$> <ja0t5t$kms$>
    <icWwq.30836$>
    NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org

    From: "Derek K. Wodenhouse" <>
    Newsgroups: comp.lang.java.programmer
    Subject: Re: Standard Design and Development Methodologies
    Date: Sat, 19 Nov 2011 23:49:09 -0500
    Organization: Occupy rec.arts.tv
    Message-ID: <jaa0s6$br$>
    References: <Xns9FA29593FF4C2jpnasty@94.75.214.39>
    <p4_xq.30508$>
    <4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19>
    NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org


    ....take note of the supportive lead in by <>.
    "Lew" quit posting from an ISP when that service dropped
    Usenet. Around that same time Derbyshire switched back to
    bell.ca., as his ISP of choice, despite his complaints about the service.
    The coincidence warrants closer examination as it is classic
    Derbyshire behavior to run "Spy V Spy" type roles in newsgroups
    where the idiot believes the topic is known to him.

    Then there is this;

    Date: Sat, 26 Jul 2008 09:50:50 -0400
    From: Lew <com.lewscanon@lew>
    Organization: the real lewscanon.com
    User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
    Newsgroups: comp.lang.java.programmer
    Subject: Re: Missing Lew's posts but not the impostor?
    References: <488a067a$0$3154$>
    <g6e9ab$f9o$>
    In-Reply-To: <g6e9ab$f9o$>
    Message-ID: <>
    X-Usenet-Provider: http://www.giganews.com
    NNTP-Posting-Host: 76.114.182.213


    Daniele Futtorovic wrote:
    > On 25/07/2008 18:59, Daniel Pitts allegedly wrote:
    >> I'm seeing a lot of posts by the Fake Lew, and a couple of replies to
    >> apparently the original Lew's post, but it never made it to my news
    >> client.


    ....as Daniel Pitts is now reading CJLP perhaps a comment is in order
    from that source. IS the Lew leading the Derbyshire sock for real, or an
    imposter?
    ?
    ?
    SPACE MADE FOR CONTRIBUTIONS

    __________________________________________________________

    Of corse as per usual the OP's topic is yet another Debyshire troll.
    Anyone require gill repairs?


    From: Novice <novice@example..com>
    Newsgroups: comp.lang.java.programmer
    Subject: Standard Design and Development Methodologies
    Date: Sat, 19 Nov 2011 19:42:07 +0000 (UTC)
    Organization: Your Company
    Message-ID: <Xns9FA29593FF4C2jpnasty@94.75.214.39>
    NNTP-Posting-Host: 3xQmNYlLzPWlOroV9OKfZA.user.speranza.aioe.org

    From: Just Plain Nasty <>
    Newsgroups: rec.arts.tv
    Subject: Re: William Shatner Warns Of The Dangers Of Turkey Fryers
    Date: Fri, 18 Nov 2011 19:56:20 +0000 (UTC)
    Organization: Your Company
    Message-ID: <Xns9FA197FD4E916jpnasty@94.75.214.39>
    References: <ja59al$iu7$> <4ec69cdc$-privat.org>
    NNTP-Posting-Host: 3xQmNYlLzPWlOroV9OKfZA.user.speranza.aioe.org
     
    spk, Nov 20, 2011
    #11
  12. Novice

    Lew Guest

    On Sunday, November 20, 2011 12:49:39 AM UTC-8, Derek K. Wodenhouse wrote:
    > On 20/11/2011 2:45 AM, Lew wrote:
    > > Derek K. Wodenhouse wrote:
    > >> Lew wrote:
    > >>> As for ontologies, the most useful ones I know are event-driven
    > >>> programming, object-oriented programming, MVC (model-view-controller),
    > >>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
    > >>> own term for using the language of the problem domain (its nouns and
    > >>> verbs) to define your program structures.
    > >>
    > >> That last is also known as "programming in Lisp". ;)

    > >
    > > Trivially, since the technique applies irrespective of platform.
    > >
    > > It's also known as "programming in /X/", where /X/ is any programming language.

    >
    > Not nearly as strongly. Lisps let you reify nearly any program
    > abstraction, and build a bridge from the solution domain to the problem
    > domain, expressing most of the business logic in problem domain terms. A


    So does Java, C++, BASIC, Fortran, Ada, F#, Javascript, Forth, ...

    > common program design in another language consists of a problem domain
    > focused library, plus an application layer atop that that contains the
    > business logic but is still largely written in solution domain terms,


    Hahaha.

    > with a sprinkling of problem domain nouns and verbs. A common program
    > design in Lisp consists of a domain-specific language for the problem
    > domain, in Lisp, and an application in that language with a sprinkling
    > of generic-Lisp nouns and verbs (mostly lists and data structure
    > traversals, and/or numbers and arithmetic -- much of which might be
    > regarded as present also in the problem domain).


    Language War! Language War!

    I'm breaking out my popcorn.

    Just so you know, you Lisp fanboys love to cause fights, but where's the money in programming, hm?

    Go have fun in your playpen.

    --
    Lew
     
    Lew, Nov 20, 2011
    #12
  13. Novice

    Lew Guest

    Plonk, spk.
     
    Lew, Nov 20, 2011
    #13
  14. Novice

    Novice Guest

    Arne Vajhøj <> wrote in
    news:4ec86452$0$288$:

    > On 11/19/2011 2:42 PM, Novice wrote:
    >> I have a very general question that isn't really even specific to
    >> Java but I'd appreciate your thoughts on this.
    >>
    >> I'm a Java hobbyist. I've been writing code in Java for a while
    >> because I like the language but haven't really used current standard
    >> design and programming methodologies in a formal way to develop my
    >> code, sticking to older methodologies that I learned long ago, like
    >> structured programming and structured design. I'm thinking of trying
    >> to get paying work as a full- time employee in a company using Java
    >> but I think I'm going to have to acquire some new skills to be a
    >> credible candidate for a junior position in systems development.
    >>
    >> What are the standard design and development methodologies being used
    >> in systems departments these days and, ideally, where can I find
    >> tutorials for them, preferably free and online?
    >>
    >> I expect that I will have to get at least a working knowledge of a
    >> bunch of things, including OO Design, Patterns, and a dozen other
    >> things to have any chance but, as a Chinese philosopher once said "a
    >> journey of a thousand miles begins with a single step". I'd
    >> appreciate your help in building a list of the things that someone
    >> like your employer would want met to have before considering me for a
    >> junior position writing Java.

    >
    > OOA/OOD/OOP + design patters seems to be what to focus on.
    >
    > GoF book
    > Code Complete
    > Applying UML and Patterns/Larman
    > Effective Java/Bloch
    >
    > could be useful books to study.
    >

    Thanks Arne. I already have Effective Java, although I haven't made the
    time to go through it yet. I'll have to track down the others and make time
    to work my way through them - and practice what they suggest as best I can!





    --
    Novice
     
    Novice, Nov 20, 2011
    #14
  15. Novice

    Novice Guest

    Arved Sandstrom <> wrote in
    news:p4_xq.30508$:

    > You could probably do worse than to read
    > http://en.wikipedia.org/wiki/Software_development_methodology. This is
    > of value primarily because it introduces a lot of common terminology.
    >
    > Ultimately _every_ software development methodology (SDM) boils down
    > to:
    >
    > 1. requirements analysis - understanding what the client needs you to
    > do; 2. analysis & design - how you intend to meet those needs. See
    > http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design,
    > since we are talking Java, for general concepts;
    > 3. implementation - actually write code;
    > 4. testing - ensuring that your code, as written, satisfies the
    > requirements;
    > 5. maintenance - nurturing the application over its lifespan.
    >
    > How all the various approaches differ is how they break up and
    > sequence these activities. What really matters is that all these
    > activities are important.
    >
    > It's probably best not to fixate on any given methodology. Just learn
    > up on the highlights of each, and keep in mind that all of them
    > ultimately boil down to requiring competence in the same skills. You'd
    > be interested initially in object-oriented analysis (OOA),
    > object-oriented design (OOD), and how to test your code (starting with
    > unit testing and perhaps functional testing).
    >
    > Like Arne suggested, "Effective Java" by Bloch is a great book. So is
    > "Code Complete". IMO I wouldn't bother buying a copy of the GOF design
    > patterns book; borrow from a university library or locate a decent
    > website instead. Read some Martin Fowler
    > (http://martinfowler.com/intro.html). Don't get hung up on specific
    > methodologies (did I say that already?) - no project ever succeeded or
    > failed just because of what methodology a team used. Get some
    > familiarity with UML but don't go overboard with it.
    >
    > My own specific suggestion - read
    > http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
    > also a good author). CRC is not just useful in agile.
    >
    > If your understanding of persistence (databases) is not solid - in
    > your estimation, bone up on that.
    >
    > If you don't have one already, select another OO programming language
    > to learn. You can make a lot more headway in learning all of the above
    > if you're not tied to one specific language. Just my opinion.
    >

    Thanks, Arved. Lots of great suggestions, tempered with common sense like
    not getting fixated on any specific methodology.

    A couple of followup questions if I may.
    1. I'm pretty solid on relational databases, although not OO databases.
    I'm not clear on the actual purpose of "persistence layers" though. I
    started to look at Hibernate a few years back but got sidetracked and
    didn't get very far. Can you possibly summarize in a few sentences:
    a. what a persistence layer does
    b. how an OO database differs from a relational database?

    I'm also intrigued to hear you suggest looking at another OO language as
    a way to learn more about OO in general. Interesting idea. Like learning
    French to help improve your Spanish, to use a non-computer metaphor.I did
    dabble in C++ briefly after I had the basics of C but then discovered
    that C++ was not easily portable across platforms. That's when I was sold
    (brainwashed?) into looking at Java ;-)

    What other OO language would be best to consider? C++? Smalltalk? .NET?
    (Hmm, I'm not sure if .NET is even considered OO....)


    --
    Novice
     
    Novice, Nov 20, 2011
    #15
  16. Novice

    Novice Guest

    Lew <> wrote in
    news:4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19:

    > Arved Sandstrom wrote:
    >> Novice wrote:
    >>> What are the standard design and development methodologies being
    >>> used in

    >
    >>> systems departments these days and, ideally, where can I find
    >>> tutorials

    > for
    >>> them, preferably free and online?
    >>>

    >> You could probably do worse than to read
    >> http://en.wikipedia.org/wiki/Software_development_methodology. This
    >> is of value primarily because it introduces a lot of common
    >> terminology.
    >>
    >> Ultimately _every_ software development methodology (SDM) boils down
    >> to:
    >>
    >> 1. requirements analysis - understanding what the client needs you to
    >> do; 2. analysis & design - how you intend to meet those needs. See
    >> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design,
    >> since we are talking Java, for general concepts;
    >> 3. implementation - actually write code;
    >> 4. testing - ensuring that your code, as written, satisfies the
    >> requirements;
    >> 5. maintenance - nurturing the application over its lifespan.
    >>
    >> How all the various approaches differ is how they break up and
    >> sequence these activities. What really matters is that all these
    >> activities are important.

    >
    > There's a comprehensive little pamphlet reviewing various software
    > development methodologies called /Wicked Problems, Righteous
    > Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as
    > when first published.
    >
    > Its main conclusion, after a very neutral overview of the extant pet
    > theories, is that successful methodologies rest on two key features:
    > an individual who maintains the project architecture and structures in
    > his/her own mind, and iteration.
    >
    > As such an individual (as you should be, too), I have a toolbox of
    > ways to look at a programming assignment - a kit of ontologies.
    >
    > First and most fundamental skill - to look it up. Whatever the
    > unfamiliar concept or skill, there is never an expert enough who's
    > patient enough with time enough and communication talent enough to
    > explain it for you. You have to be able to do with fragments of
    > advice (at best) and what you discover for yourself - through hard,
    > hard study and very pragmatic experimentation. A former mentor of
    > mine trained me that any IT person spending less than 20% over and
    > above their normal work time to study and practice was doomed to fall
    > behind.
    >
    > 'Struth.
    >
    > As for ontologies, the most useful ones I know are event-driven
    > programming, object-oriented programming, MVC (model-view-controller),
    > layers (Law of Demeter), and "noun-and-verb" modeling. That last is
    > my own term for using the language of the problem domain (its nouns
    > and verbs) to define your program structures.
    >
    > There's one style trick that induces better code: Keep it short.
    > After about 500 lines of code and comment (yes, and comment) your
    > class should feel too large, and after about 700-800 lines you should
    > be castigating yourself.
    >
    > The pressure to keep it short helps you think more clearly about
    > structure.
    >
    > And there's one mandatory, cross-methodology practice: Javadoc the
    > shit out of your code. Document private and package-private methods
    > and all static variables down to private. The extra asterisk at the
    > start of the comment block hurts nothing.
    >
    > Don't use specious comments, the kind that repeat what the code
    > already says:
    >
    > for (Foo foo : bunchOfFoos) // operate on each of the Foos
    >
    > Pfeh! If a person doesn't know what a for-each loop is, such a
    > comment will not rescue them.
    >
    > Do liberally comment anything that makes a maintainer go, "Hmm."
    >
    > // volatile: thread calling close() might not be same as called
    > perform() private volatile boolean isStopping;
    >
    > This advice might not fit your idea of what constitutes a
    > "methodology", but for Pete's sake, think. What does that "ology"
    > suffix buy you but buzzword compliance? The real need is for a
    > _method_, a process by which you can produce effective, reliable,
    > correct software on time to spec. In the end it's all about your
    > personal commitment and skill.
    >


    Thanks Lew, lots of sound advice in your remarks! I totally agree with
    your distinction between a methodology vs. a method; my original question
    was not ideally worded.

    I'm trying to figure out what kinds of things an interviewer from the
    technical side of the shop - as opposed to HR - is going to expect. I'm
    not sure how open-minded they will be to someone who wants a job but
    doesn't seem to have much prior contact with specific methodologies so I
    was hoping to get a list of the key methodologies. But that was probably
    misguided since I expect they will be relatively open-minded as long as
    you have the main SKILLS of each stage of the development process, even
    if they don't use whatever formal methodology you might know. So, even if
    you've never seen a UML diagram before but have done some other kind of
    diagram that conveys the same basic information, they will accept you
    anyway and recognize that you will be easily able to start doing UML
    instead of whatever you have been doing. Or is all that wishful thinking?


    --
    Novice
     
    Novice, Nov 20, 2011
    #16
  17. Novice

    Arne Vajhøj Guest

    On 11/20/2011 12:08 PM, Novice wrote:
    > I'm also intrigued to hear you suggest looking at another OO language as
    > a way to learn more about OO in general. Interesting idea. Like learning
    > French to help improve your Spanish, to use a non-computer metaphor.I did
    > dabble in C++ briefly after I had the basics of C but then discovered
    > that C++ was not easily portable across platforms. That's when I was sold
    > (brainwashed?) into looking at Java ;-)
    >
    > What other OO language would be best to consider? C++? Smalltalk? .NET?
    > (Hmm, I'm not sure if .NET is even considered OO....)


    ..NET is OO.

    But I think C# is too close to Java to provide maximum alternative
    perspective.

    C++, Ruby may provide more value for this purpose.

    Arne
     
    Arne Vajhøj, Nov 20, 2011
    #17
  18. Novice

    markspace Guest

    On 11/20/2011 9:08 AM, Novice wrote:

    > 1. I'm pretty solid on relational databases, although not OO databases.
    > I'm not clear on the actual purpose of "persistence layers" though. I
    > started to look at Hibernate a few years back but got sidetracked and
    > didn't get very far. Can you possibly summarize in a few sentences:
    > a. what a persistence layer does



    Persistence just saves stuff to long term storage. How it does that is
    another matter. When talking databases, a persistence layer interfaces
    objects to a database (usually a database connection of some sort). It
    takes care of a lot of the busy work of reading a database entity into
    objects, and writing objects out as database entities.

    You can do this manually, but it's really busy work. Do it once to see
    how it works, then forget it and go for JPA.


    > b. how an OO database differs from a relational database?



    I don't know, other than I don't think OO databases are popular or
    practical. Everyone I know uses the relational variety, or flat files.
     
    markspace, Nov 20, 2011
    #18
  19. Novice

    Lew Guest

    Novice wrote:
    > Lew wrote:
    >> There's a comprehensive little pamphlet reviewing various software
    >> development methodologies called /Wicked Problems, Righteous
    >> Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as
    >> when first published.
    >> http://www.google.com/search?q=ISBN 013590126X

    >
    > I'm trying to figure out what kinds of things an interviewer from the
    > technical side of the shop - as opposed to HR - is going to expect. I'm
    > not sure how open-minded they will be to someone who wants a job but
    > doesn't seem to have much prior contact with specific methodologies so I
    > was hoping to get a list of the key methodologies.


    Add Agile to the list in /Wicked Problems.../ and you'll have that list. Also, is there one on Wikipedia, perhaps, as Arved Sandstrom wrote:
    > You could probably do worse than to read
    > http://en.wikipedia.org/wiki/Software_development_methodology.
    > This is of value primarily because it introduces a lot of common terminology.

    ?

    --
    Lew
     
    Lew, Nov 20, 2011
    #19
  20. Novice

    Lew Guest

    Novice wrote:
    > A couple of followup questions if I may.
    > 1. I'm pretty solid on relational databases, although not OO databases.
    > I'm not clear on the actual purpose of "persistence layers" though. I
    > started to look at Hibernate a few years back but got sidetracked and
    > didn't get very far. Can you possibly summarize in a few sentences:
    > a. what a persistence layer does
    > b. how an OO database differs from a relational database?


    This is a major topic. I'll hit some headlines /infra/.

    > ...
    > What other OO language would be best to consider? C++? Smalltalk? .NET?
    > (Hmm, I'm not sure if .NET is even considered OO....)


    ..Net isn't a language, it's a platform.

    You might read Grady Booch or others on what object-oriented blahblah is generally.

    Don't get too bogged down there - skimming the TOC and a few paragraphs in each chapter in the bookstore will get you started.

    Object-oriented is just a way of looking at things. Relational algebra (RDBMSes) is another, orthogonal way.

    Object-oriented, as well explained by Booch and others, entails adherence to certain principles, the number and name of which vary a bit between authors. Basically it's encapsulation and inheritance, component and layered architecture, and a clean, well laid-out structure.

    Encapsulation involves abstraction of the interaction between tightly focused types that hide their mechanics. You program to the interface <generically at times>.

    Inheritance is a spice to use lightly.

    O-O is at its best a synonym for really good modeling. Each type should befairly simple - easier to do if you concentrate on its interface and not the messy innards.

    Unit tests are invaluable.

    Good languages are C#, C++, Smalltalk (the progenitor).

    Other languages to know are Lisp, Forth, Javascript, Python, Go, Prolog, C,bash.

    Object-oriented databases are a dead end.

    IMHO.

    But SQL is really only for those who understand relations.

    Relations are not objects.

    And vice versa.

    But they map to each other, with a lot of transformational infrastructure. The key is that the object and data ontologies are not the same.

    I've done a lot of that - mapping objects to relations, or "object-to-relational mapping" (ORM).

    The best way to do ORM in Java is JPA, the Java Persistence API. There arethree standard, free products that give you that specification: EclipseLink, Apache OpenJPA, and Hibernate. Hibernate comes with a weight of documentation and culture from its pre-JPA days. Don't get sucked into that. Stick firmly with JPA.

    OK, "best" is relative. You might be fine with just the Collections API, which you should master anyway. But to talk to databases like Derby or PostgreSQL, JPA is wonderful. As long as you don't think of it as "talking to databases".

    JPA gives you an object-oriented view of persistent information, hiding therelational sensibility from the program. It is about control of sessions,that is, 'EntityManager' lifetimes, and how durable to make object properties, not about data. The framework handles a subset of data manipulations opaquely to support that mapping.

    Well, translucently, but learn the basics first.

    --
    Lew
     
    Lew, Nov 20, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vinh Pham
    Replies:
    5
    Views:
    588
    Vinh Pham
    Dec 8, 2003
  2. A
    Replies:
    3
    Views:
    485
    jeffc
    Nov 26, 2003
  3. hvt
    Replies:
    0
    Views:
    471
  4. Replies:
    1
    Views:
    441
    Nicholas Paul Collin Gloucester
    Feb 5, 2009
  5. Nikolaos Kavvadias
    Replies:
    0
    Views:
    323
    Nikolaos Kavvadias
    Apr 22, 2013
Loading...

Share This Page