Consolidating java objects

Discussion in 'Java' started by Dave, Oct 16, 2006.

  1. Dave

    Dave Guest

    I have been a J2EE developer since Jan 2000, and have been on a number
    of projects. However, with most of the projects we have been able to
    keep the number of objects that can be used fairly small, to around 50
    at the most and re-used or inherited from the core group of objects.

    I am now on a project where the number of objects keeps growing with
    each development release. It went from 250 to 277 objects in the last
    release. There are so many objects that developers no longer look to
    see if an object will work for them, they just create a new one from
    scratch.

    Some objects are small, around 4-10 fields, others are much larger
    (dozens of fields) and some inherit from other objects. I cannot come
    up with a good way to find the similar objects so that the number can
    be brought back under control. I also cannot come up with a good way
    for developers to find objects that have what they need, since they
    have spread the objects out from the initial framework package into
    packages and modules all through the code. A way to compare objects
    would also be very helpful.

    The project is larger, around 15-25 developers at any time, but I am
    tasked with figuring out a solution to this problem. I have tried a
    spreadsheet, but it grows too big in a short time, and I can't see more
    than 1-3 objects on the screen at once, when I need to be able to see
    more of them. I also tried writing an XML document but it was too
    hard. Javadoc generates too many files for this to be useful as well.


    I have found several examples where the object wasn't needed and a
    framework object could be used. I've also found cases where the object
    simply extended another object and then didn't add any additional
    fields. There have also been cases where the same set of fields show
    up in object after object.

    Does anyone have any ideas of tools or methodologies to use that could
    help? I tried google and yahoo but didn't have any luck. Any ideas
    would be greatly appreciated.

    Thanks in advance
     
    Dave, Oct 16, 2006
    #1
    1. Advertising

  2. Dave wrote:
    > I have been a J2EE developer since Jan 2000, and have been on a number
    > of projects. However, with most of the projects we have been able to
    > keep the number of objects that can be used fairly small, to around 50
    > at the most and re-used or inherited from the core group of objects.
    >
    > I am now on a project where the number of objects keeps growing with
    > each development release. It went from 250 to 277 objects in the last
    > release. There are so many objects that developers no longer look to
    > see if an object will work for them, they just create a new one from
    > scratch.


    Are you actually talking about objects? It seems more that you mean
    "classes" instead.

    > Some objects are small, around 4-10 fields, others are much larger
    > (dozens of fields) and some inherit from other objects. I cannot come
    > up with a good way to find the similar objects so that the number can
    > be brought back under control. I also cannot come up with a good way
    > for developers to find objects that have what they need, since they
    > have spread the objects out from the initial framework package into
    > packages and modules all through the code. A way to compare objects
    > would also be very helpful.


    What about documentation? Is there proper JavaDoc and package
    documentation?

    > The project is larger, around 15-25 developers at any time, but I am
    > tasked with figuring out a solution to this problem. I have tried a
    > spreadsheet, but it grows too big in a short time, and I can't see more
    > than 1-3 objects on the screen at once, when I need to be able to see
    > more of them. I also tried writing an XML document but it was too
    > hard. Javadoc generates too many files for this to be useful as well.


    The question is what is the criteria for identifying similar classes?
    If it is just methods or fields that seems pretty easy - even with
    reflection. But if you are talking about semantics or want to compare
    method behavior then you'll have a difficult task to do.

    > I have found several examples where the object wasn't needed and a
    > framework object could be used. I've also found cases where the object
    > simply extended another object and then didn't add any additional
    > fields. There have also been cases where the same set of fields show
    > up in object after object.
    >
    > Does anyone have any ideas of tools or methodologies to use that could
    > help? I tried google and yahoo but didn't have any luck. Any ideas
    > would be greatly appreciated.


    First of all 270 classes is not really much. You might be more
    successful with a social solution instead of a technical one. For
    example, you can improve communication by having developers present what
    they developed so others know about. Or you install a process that must
    be followed during creation of new classes and which might ensure people
    find and use solutions done by others etc.

    Kind regards

    robert
     
    Robert Klemme, Oct 16, 2006
    #2
    1. Advertising

  3. Dave

    Daniel Dyer Guest

    On Mon, 16 Oct 2006 20:29:16 +0100, Dave <> wrote:

    > I have been a J2EE developer since Jan 2000, and have been on a number
    > of projects. However, with most of the projects we have been able to
    > keep the number of objects that can be used fairly small, to around 50
    > at the most and re-used or inherited from the core group of objects.
    >
    > I am now on a project where the number of objects keeps growing with
    > each development release. It went from 250 to 277 objects in the last
    > release. There are so many objects that developers no longer look to
    > see if an object will work for them, they just create a new one from
    > scratch.


    Do you mean classes rather than objects?

    250 classes is not that big a project (unless they are all huge monolithic
    things), especially for such a large team.

    > Some objects are small, around 4-10 fields, others are much larger
    > (dozens of fields) and some inherit from other objects. I cannot come
    > up with a good way to find the similar objects so that the number can
    > be brought back under control. I also cannot come up with a good way
    > for developers to find objects that have what they need, since they
    > have spread the objects out from the initial framework package into
    > packages and modules all through the code. A way to compare objects
    > would also be very helpful.


    This really comes down to organisation and communication. If you can
    reorganise your packages, and which classes are in them, to be more
    logical it should make things easier to locate. Ideally, you'd get the
    whole team to agree on how things are to be arranged, then everybody knows
    how things are supposed to be organised.

    > The project is larger, around 15-25 developers at any time, but I am
    > tasked with figuring out a solution to this problem. I have tried a
    > spreadsheet, but it grows too big in a short time, and I can't see more
    > than 1-3 objects on the screen at once, when I need to be able to see
    > more of them. I also tried writing an XML document but it was too
    > hard.


    Something like a UML class diagram would probably be more appropriate, it
    will also show the relationships between classes. Many tools will
    generate a diagram for you from source code (though it may need some human
    input to tidy it up).

    Anything that exists in isolation from the codebase is going to be awkward
    to maintain and will quickly become out-of-date and useless.
    Reports/diagrams that can be automatically generated from the code would
    be preferable.

    > Javadoc generates too many files for this to be useful as well.


    There are lots of configuration options and custom doclets to control the
    kind of output it gives you.

    > I have found several examples where the object wasn't needed and a
    > framework object could be used. I've also found cases where the object
    > simply extended another object and then didn't add any additional
    > fields. There have also been cases where the same set of fields show
    > up in object after object.


    Again this is communication. It sounds like your developers are working
    in isolation, trying to get their little piece done without considering
    the bigger picture. Perhaps code reviews would help?

    Dan.

    --
    Daniel Dyer
    http://www.uncommons.org
     
    Daniel Dyer, Oct 16, 2006
    #3
  4. Dave

    Dave Guest

    Thank you for your answers.
    When a class has private fields, getters and setters and no logic, I
    call this an object. It is certainly a class.

    There are a couple of other problems that I have not mentioned. Half
    of the project is offshored to India, and the other half of the
    development is done in-house by additional Indian developers and then I
    have come into the picture. I would be staying long term and
    maintaining what is being written now in addition to doing further
    development.

    They are not doing any documenting, adding JavaDoc, etc... When asked
    to help document their objects so we could see what their objects are
    doing/used for, one of the team leaders outright refused and said they
    didn't have time for that. Since my boss apparently allowed this,
    there won't be any documentation for that.

    We have plenty of instances where there are 3-4 classes (objects) named
    exactly the same, but with completely different fields and each is in a
    completely different module or package. How would anyone know which
    student class to use without any documentation or JavaDoc?

    Reorganizing is easier said then done. There may only be around 280
    classes (objects), but we have a few hundred JSPs, a very large number
    of services and data access objects that all depend on them. Everyone
    is acting fairly independently and without documentation they are
    creating classes rather than re-using.

    Can you recommend any UML tools that would do this?
    Also, I am working towards doing code reviews. Unfortunately, it is
    only because I am pushing for it and it will be coming fairly late into
    the development process.
     
    Dave, Oct 16, 2006
    #4
  5. "Dave" <> writes:

    > Some objects are small, around 4-10 fields, others are much larger
    > (dozens of fields) and some inherit from other objects. I cannot come
    > up with a good way to find the similar objects so that the number can
    > be brought back under control. I also cannot come up with a good way
    > for developers to find objects that have what they need, since they
    > have spread the objects out from the initial framework package into
    > packages and modules all through the code. A way to compare objects
    > would also be very helpful.
    >



    I suspect that if I looked at your project, I'd suggest breaking
    up some of the larger classes (dozens of fields?) into smaller
    classes with fewer responsibilities.

    That's clearly not the direction you want to go.

    What difficulty is having too many classes causing? Alternately,
    what Good Thing would you gain by having fewer classes that you
    don't have now?


    --
    Mark Jeffcoat
    Austin, TX
     
    Mark Jeffcoat, Oct 16, 2006
    #5
  6. Dave

    Daniel Dyer Guest

    On Mon, 16 Oct 2006 21:45:27 +0100, Dave <> wrote:

    > Thank you for your answers.
    > When a class has private fields, getters and setters and no logic, I
    > call this an object. It is certainly a class.
    >
    > There are a couple of other problems that I have not mentioned. Half
    > of the project is offshored to India, and the other half of the
    > development is done in-house by additional Indian developers and then I
    > have come into the picture. I would be staying long term and
    > maintaining what is being written now in addition to doing further
    > development.
    >
    > They are not doing any documenting, adding JavaDoc, etc... When asked
    > to help document their objects so we could see what their objects are
    > doing/used for, one of the team leaders outright refused and said they
    > didn't have time for that. Since my boss apparently allowed this,
    > there won't be any documentation for that.


    OK, this doesn't sound like much fun.

    > We have plenty of instances where there are 3-4 classes (objects) named
    > exactly the same, but with completely different fields and each is in a
    > completely different module or package. How would anyone know which
    > student class to use without any documentation or JavaDoc?


    The short answer is, without documentation, you don't know. If there are
    two classes with the same name and neither is documented, the only real
    solution is to document them somehow.

    There are tools for finding duplicate code in projects (see
    http://checkstyle.sourceforge.net/config_duplicates.html) but it doesn't
    sound like these will be much help.

    > Reorganizing is easier said then done. There may only be around 280
    > classes (objects), but we have a few hundred JSPs, a very large number
    > of services and data access objects that all depend on them. Everyone
    > is acting fairly independently and without documentation they are
    > creating classes rather than re-using.


    An IDE with good refactoring support (such as IDEA) should be able to
    resolve all of these dependencies for you when doing the reorganisation.
    Just make sure everybody has checked-in their changes, declare a temporary
    code freeze and then checkout the code on one machine, make the necessary
    changes and commit them (in theory).

    > Can you recommend any UML tools that would do this?


    Most of the ones you have to pay for (i.e. Rational Rose, Together,
    etc.). I think even the Open Source ArgoUML (http://argouml.tigris.org)
    does it (if not, it's commercial cousin Poseidon -
    http://www.gentleware.com - will do).

    > Also, I am working towards doing code reviews. Unfortunately, it is
    > only because I am pushing for it and it will be coming fairly late into
    > the development process.


    Good luck. I was on a project last year where development took place in
    three different timezones, so I know that remote coordination can be very
    difficult. I'm glad that my current project team are all in the same room
    as me. Even the guy who runs a separate project that we have to interface
    with sits next to me.

    Dan.

    --
    Daniel Dyer
    http://www.uncommons.org
     
    Daniel Dyer, Oct 16, 2006
    #6
  7. "Dave" <> writes:

    > Thank you for your answers.
    > When a class has private fields, getters and setters and no logic, I
    > call this an object. It is certainly a class.



    That this sort of class should exist at all is a red flag--
    it usually indicates you've got a lot of old-school procedural
    programmers who are just faking the whole OO thing. Using
    getters and setters, instead of just admitting it's a C-style
    struct and making all the fields public, means they're probably
    not aware of it.

    (Of course, "old-school procedural programmers" got a lot
    of good software written. It's just useful to know who you're
    dealing with, now that a lot of them have migrated to Java.
    In syntax, at least.)

    >
    > They are not doing any documenting, adding JavaDoc, etc... When asked
    > to help document their objects so we could see what their objects are
    > doing/used for, one of the team leaders outright refused and said they
    > didn't have time for that. Since my boss apparently allowed this,
    > there won't be any documentation for that.


    Another red flag, as you're well aware.

    >
    > We have plenty of instances where there are 3-4 classes (objects) named
    > exactly the same, but with completely different fields and each is in a
    > completely different module or package. How would anyone know which
    > student class to use without any documentation or JavaDoc?


    Student class? Is that the domain model slipping out?

    If the fields are different, and there's no logic, there's
    no real commonality between the classes. This is not a sign
    that you have too many classes, but that the separation between
    modules isn't doing enough to help manage the project's complexity.


    > Reorganizing is easier said then done. There may only be around 280
    > classes (objects), but we have a few hundred JSPs, a very large number
    > of services and data access objects that all depend on them. Everyone
    > is acting fairly independently and without documentation they are
    > creating classes rather than re-using.


    Another red flag. That is, that no one's looking for opportunities
    to build better abstractions.


    >
    > Can you recommend any UML tools that would do this?
    > Also, I am working towards doing code reviews. Unfortunately, it is
    > only because I am pushing for it and it will be coming fairly late into
    > the development process.



    You don't need a new tool. You've got a broken development
    process. Someone in project management must recognize this--that
    seems to be why you were brought in.

    Code reviews won't help unless your team has some basic agreement
    on the difference between good code and bad. For instance, your
    definition of good code includes "has documentation", and it seems
    that most of the rest of the team disagrees, or just doesn't care.

    You're in a tough spot. If everyone continues working as they
    are right now, with their current values, they will continue
    to get the same results, no matter what new tools you introduce,
    UML and otherwise.

    (Yeah--no actual Java programming in this post, but I've spent
    the last year on a project that once had very similar problems.)

    --
    Mark Jeffcoat
    Austin, TX
     
    Mark Jeffcoat, Oct 16, 2006
    #7
  8. Dave wrote:
    > I am now on a project where the number of objects keeps growing with
    > each development release. It went from 250 to 277 objects in the last
    > release. There are so many objects that developers no longer look to
    > see if an object will work for them, they just create a new one from
    > scratch.
    >
    > Some objects are small, around 4-10 fields, others are much larger
    > (dozens of fields) and some inherit from other objects. I cannot come
    > up with a good way to find the similar objects so that the number can
    > be brought back under control. I also cannot come up with a good way
    > for developers to find objects that have what they need, since they
    > have spread the objects out from the initial framework package into
    > packages and modules all through the code. A way to compare objects
    > would also be very helpful.


    As other has said then this is not that many classes.

    That of course does not prevent it from being a mess.

    But I doubt any tools will solve the problems.

    You will simply have to look at the classes, see where
    they are used, see what they contain and do the refactoring
    the hard way.

    Arne
     
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Oct 17, 2006
    #8
  9. Mark Jeffcoat wrote:
    > "Dave" <> writes:
    >> Thank you for your answers.
    >> When a class has private fields, getters and setters and no logic, I
    >> call this an object. It is certainly a class.

    >
    > That this sort of class should exist at all is a red flag--
    > it usually indicates you've got a lot of old-school procedural
    > programmers who are just faking the whole OO thing. Using
    > getters and setters, instead of just admitting it's a C-style
    > struct and making all the fields public, means they're probably
    > not aware of it.


    Or they may have read a book about J2EE (including the
    section about DTO pattern).

    Arne
     
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Oct 17, 2006
    #9
  10. Arne Vajhøj <> writes:

    > Mark Jeffcoat wrote:
    >> "Dave" <> writes:
    >>> Thank you for your answers.
    >>> When a class has private fields, getters and setters and no logic, I
    >>> call this an object. It is certainly a class.

    >>
    >> That this sort of class should exist at all is a red flag--
    >> it usually indicates you've got a lot of old-school procedural
    >> programmers who are just faking the whole OO thing. Using
    >> getters and setters, instead of just admitting it's a C-style
    >> struct and making all the fields public, means they're probably
    >> not aware of it.

    >
    > Or they may have read a book about J2EE (including the
    > section about DTO pattern).
    >


    I agree-- in one version of my post, I included as a footnote
    the idea that the dev team may be something clever to
    deal with the accidental difficulties of J2EE.

    I deleted it. I don't see any evidence from the original
    poster that his team is making sophisticated decisions, and
    I decided not to confuse the issue.

    (No insult intended. I don't think your point is wrong, I'm
    just moving toward the idea that talking about "patterns"
    to people who haven't gotten a good grip on the basics may
    actually be counter-productive.)

    --
    Mark Jeffcoat
    Austin, TX
     
    Mark Jeffcoat, Oct 17, 2006
    #10
  11. Dave

    Chris Uppal Guest

    Dave wrote:

    > I would be staying long term and
    > maintaining what is being written now in addition to doing further
    > development.


    If this project is in anything like the state I'm imagining, then I fear that
    you are wrong. You may be staying long-term, but it doesn't sounds as though
    you'll be doing a lot of "further development".

    Here are two specific suggestions.

    1) See if you can isolate all the data-only classes, put them all into one (or
    maybe several) special packages with names like xxx.dataobjects.whatever; and
    see if there's any structure at all in what's left. If you are lucky there
    will be some decent structure which the clouds of brain-dead "structs" have
    been obscuring.

    2) Quit now.

    -- chris
     
    Chris Uppal, Oct 17, 2006
    #11
  12. Dave

    Dave Guest

    Thank you all for your answers, they are very helpful. Unfortunately
    the developers I am working with have come from the schools in India
    where they teach you the syntax but you don't know how to really apply
    it. They've worked a few months or a little longer at other projects
    but are not really medium to high level J2EE programmers. I narrowly
    averted our initial Production rollout from being a disaster when I
    found in some code they weren't handling JDBC connection resources
    properly (or at all), and then had to do a rapid scan of a few hundred
    long DAOs, list everywhere it wasn't handling connections properly, get
    it out to the team leads and then with management behind me, forced the
    changes to be fixed over a week. I then verified every single one of
    them. Up to that point they had been having max cursor errors
    constantly during load testing but hadn't told me until I found that
    out. There hasn't been one since.

    I have been doing this type of development for over six years now, and
    have a list of around 20 best practices that I do my code reviews on.
    I used to have closer to 30, but I updated it a couple of months ago
    for JDK 1.4.2. The goal is to start out with me doing a few initial
    code reviews, then have the team leaders start doing them as well, and
    get to the point where the developers are doing them for each other. I
    have also installed Hammurapi, customized the inspector list and
    modified existing inspectors and am running those automated code
    reviews once a week. The violations are starting to get fixed more
    now.

    But they aren't experienced and do not make sophisticated decisions.
    In fact, if it is not written out in a functional spec, they will not
    even go ask the question. They will just make an assumption (usually
    wrong) and it isn't caught until the QA cycle where it becomes a defect
    and then the spec gets updated. I'm trying to get some of them to just
    go ask the question, but it is hard.

    I never bothered with getters and setters that didn't have logic either
    in my previous projects. I knew a heavily OO guy whose code was pure
    OO. I remember him having lines like this:
    getSomeFactory().getSomeClass().getSomeMethod().getSomeField()
    ..getSomeOtherField().getSomeList().getSomeField().getYetAnotherField().setSomething()

    And sometimes he'd have fifty or sixty lines like that in a row. No
    one could ever follow
    the logic. And every method was just a pure getter, no logic at all.

    Also, I am quite familiar with the various patterns, I have Design
    Patterns and have used quite a few of them, and have also passed the
    various Sun J2EE certifications, including the J2EE Architect
    certification.

    The number of objects may not be a problem, but part of Java is the
    idea of re-use. When I see the exact same 10 fields over and over in
    dozens of objects, that looks to me like there should have been a
    single class with those 10 fields, and all of the others should have
    inherited from that class. And considering that back in January there
    were only around 30-40 classes (from the current project architect) and
    that now we have 240 more just 9 months later looks to me like out of
    control object creation, especially when so many are so similar in
    various ways.

    Mark Jeffcoat wrote:
    > Arne Vajhøj <> writes:
    >
    > > Mark Jeffcoat wrote:
    > >> "Dave" <> writes:
    > >>> Thank you for your answers.
    > >>> When a class has private fields, getters and setters and no logic, I
    > >>> call this an object. It is certainly a class.
    > >>
    > >> That this sort of class should exist at all is a red flag--
    > >> it usually indicates you've got a lot of old-school procedural
    > >> programmers who are just faking the whole OO thing. Using
    > >> getters and setters, instead of just admitting it's a C-style
    > >> struct and making all the fields public, means they're probably
    > >> not aware of it.

    > >
    > > Or they may have read a book about J2EE (including the
    > > section about DTO pattern).
    > >

    >
    > I agree-- in one version of my post, I included as a footnote
    > the idea that the dev team may be something clever to
    > deal with the accidental difficulties of J2EE.
    >
    > I deleted it. I don't see any evidence from the original
    > poster that his team is making sophisticated decisions, and
    > I decided not to confuse the issue.
    >
    > (No insult intended. I don't think your point is wrong, I'm
    > just moving toward the idea that talking about "patterns"
    > to people who haven't gotten a good grip on the basics may
    > actually be counter-productive.)
    >
    > --
    > Mark Jeffcoat
    > Austin, TX
     
    Dave, Oct 17, 2006
    #12
  13. Dave

    Dave Guest

    I hear what you are saying, but I also enjoy the challenge of what I am
    facing. I love solving hard problems and working with other people,
    and this is actually fun for me. The reason I posted here was because
    I have just been having the hardest time grasping a non-time-intensive
    way to compare all of these objects to see what is similar. I know one
    thing I could just do is open each class and print it, then group
    similar objects together in piles. Or I could write something that
    would look at all of the classes, pull out the fields and try to
    compare each of them to each other to find what is similar.

    We had a wonderful framework package in one module that the architect
    created where these classes were supposed to go. But he didn't follow
    up on this and after three development cycles in 9 months, the
    additional 240 classes were created in so many modules and so many
    different packages it is unbelievable. Also, the number wouldn't be
    that much of a problem if so many of the classes (objects) weren't very
    similar in various ways.

    I really believe in the product being created, it is for a very, very
    good cause. So for that, I want the project to succeed and I want to
    be a part of it. If I don't do as much development any more, it is
    okay because I get to help solve some very difficult problems which I
    enjoy doing.


    Chris Uppal wrote:
    > Dave wrote:
    >
    > > I would be staying long term and
    > > maintaining what is being written now in addition to doing further
    > > development.

    >
    > If this project is in anything like the state I'm imagining, then I fear that
    > you are wrong. You may be staying long-term, but it doesn't sounds as though
    > you'll be doing a lot of "further development".
    >
    > Here are two specific suggestions.
    >
    > 1) See if you can isolate all the data-only classes, put them all into one (or
    > maybe several) special packages with names like xxx.dataobjects.whatever; and
    > see if there's any structure at all in what's left. If you are lucky there
    > will be some decent structure which the clouds of brain-dead "structs" have
    > been obscuring.
    >
    > 2) Quit now.
    >
    > -- chris
     
    Dave, Oct 17, 2006
    #13
  14. Dave

    Dave Guest

    In one of the extreme examples, one of the 'simple' classes I looked at
    yesterday (just fields, getters and setters) without any logic, was
    1560 lines. Fun, eh? That one is pretty extreme though.

    The problem isn't as much the number, as how to get the developers to
    re-use what is there when it is scattered everywhere, not named
    properly, not documented and they don't make much of an effort to look
    for a class to re-use or inherit from unless you make it really easy
    for them. It takes them five minutes to create a new one, so they all
    do that instead. In one month we added 30 more.

    So I am trying to get a handle on this by trying to find a way to
    reduce the number of classes to a more manageable level and would like
    to bring them all back into a few packages in our framework module.
    But figuring out a good way to do this a hard problem, so I thought I
    would try this group to see if anyone has dealt with similar problems
    and how they resolved it. The answers have been very helpful, so I
    will probably have to try looking into the UML software to see if it
    will help.

    I would love to have all of their current relationships mapped out,
    have all of their fields listed and fill a wall with it to illustrate
    to the developers what they are doing.


    Mark Jeffcoat wrote:
    > "Dave" <> writes:
    >
    > > Some objects are small, around 4-10 fields, others are much larger
    > > (dozens of fields) and some inherit from other objects. I cannot come
    > > up with a good way to find the similar objects so that the number can
    > > be brought back under control. I also cannot come up with a good way
    > > for developers to find objects that have what they need, since they
    > > have spread the objects out from the initial framework package into
    > > packages and modules all through the code. A way to compare objects
    > > would also be very helpful.
    > >

    >
    >
    > I suspect that if I looked at your project, I'd suggest breaking
    > up some of the larger classes (dozens of fields?) into smaller
    > classes with fewer responsibilities.
    >
    > That's clearly not the direction you want to go.
    >
    > What difficulty is having too many classes causing? Alternately,
    > what Good Thing would you gain by having fewer classes that you
    > don't have now?
    >
    >
    > --
    > Mark Jeffcoat
    > Austin, TX
     
    Dave, Oct 17, 2006
    #14
  15. On 17.10.2006 14:40, Dave wrote:
    <snip/>

    It seems you are on a good track though. Circumstances are certainly
    less than ideal but since you enjoying it...

    > I never bothered with getters and setters that didn't have logic either
    > in my previous projects. I knew a heavily OO guy whose code was pure
    > OO. I remember him having lines like this:
    > getSomeFactory().getSomeClass().getSomeMethod().getSomeField()
    > .getSomeOtherField().getSomeList().getSomeField().getYetAnotherField().setSomething()


    I would not consider that "pure OO". That's plain nonsense. You can
    achieve the same level of encryption by nesting function calls that deep
    in other languages.

    <snip/>

    > The number of objects may not be a problem, but part of Java is the
    > idea of re-use.


    I would even go as far as to say reuse is a major goal whatever language
    you use. OO languages are generally considered to be better suited to
    facilitating reuse, but you can do that in all languages.

    > When I see the exact same 10 fields over and over in
    > dozens of objects, that looks to me like there should have been a
    > single class with those 10 fields, and all of the others should have
    > inherited from that class.


    .... or used that as a member (delegation).

    > And considering that back in January there
    > were only around 30-40 classes (from the current project architect) and
    > that now we have 240 more just 9 months later looks to me like out of
    > control object creation, especially when so many are so similar in
    > various ways.


    I'd like to make two requests: please stop using the word "object" when
    in fact you mean "class". This is bound to cause confusion. We have
    some terms with pretty clear meaning in CS and it helps communication
    greatly if everybody sticks to them.

    And please do not top post. :)

    Kind regards

    robert
     
    Robert Klemme, Oct 17, 2006
    #15
  16. Dave

    Dave Guest

    I will certainly try not to top post, I apologize for that. It has
    been a while since I've used newsgroups so I have to try to remember
    the proper posting rules.

    > I would not consider that "pure OO". That's plain nonsense. You can
    > achieve the same level of encryption by nesting function calls that deep
    > in other languages.


    He called himself a 'pure OO' programmer, which is why I used that
    term. He was also fired for trying to refactor everyone else's code on
    that project into the same garbage, and then when I caught it during
    code reviews and management and I explained why that was a bad idea for
    maintenance, he deleted everything he'd ever written including out of
    VSS and then he was fired. Luckily there were recent backups of that
    drive.

    > I would even go as far as to say reuse is a major goal whatever language
    > you use. OO languages are generally considered to be better suited to
    > facilitating reuse, but you can do that in all languages.
    >
    > ... or used that as a member (delegation).


    Agreed.

    > I'd like to make two requests: please stop using the word "object" when
    > in fact you mean "class". This is bound to cause confusion. We have
    > some terms with pretty clear meaning in CS and it helps communication
    > greatly if everybody sticks to them.


    Sorry, when they are being called DAOs or Data Access Objects and that
    is how I hear them called all day long by everyone including our
    architect, I've kind of adopted that term. I know it is a class, but
    it is a hard habit to break.

    > And please do not top post. :)
    >

    Did I do any better on this?

    Thanks,
    Dave
     
    Dave, Oct 17, 2006
    #16
  17. On 17.10.2006 15:52, Dave wrote:
    > I will certainly try not to top post, I apologize for that. It has
    > been a while since I've used newsgroups so I have to try to remember
    > the proper posting rules.


    No prob. And: yeah, it is a quite unique community. :) You'll
    probably easy remember once you tried to dug yourself through a lengthy
    posting with multiple quotes. :))

    >> I would not consider that "pure OO". That's plain nonsense. You can
    >> achieve the same level of encryption by nesting function calls that deep
    >> in other languages.

    >
    > He called himself a 'pure OO' programmer, which is why I used that
    > term.


    Ah, I see.

    > He was also fired for trying to refactor everyone else's code on
    > that project into the same garbage, and then when I caught it during
    > code reviews and management and I explained why that was a bad idea for
    > maintenance, he deleted everything he'd ever written including out of
    > VSS and then he was fired. Luckily there were recent backups of that
    > drive.


    Wow!

    >> I'd like to make two requests: please stop using the word "object" when
    >> in fact you mean "class". This is bound to cause confusion. We have
    >> some terms with pretty clear meaning in CS and it helps communication
    >> greatly if everybody sticks to them.

    >
    > Sorry, when they are being called DAOs or Data Access Objects and that
    > is how I hear them called all day long by everyone including our
    > architect, I've kind of adopted that term. I know it is a class, but
    > it is a hard habit to break.


    I see. Maybe then stick with DAO - but then again, Microsoft's version
    is dead (replaced by ADO, they still have some permutations left :)).
    But yes, old habits die hard...

    >> And please do not top post. :)
    >>

    > Did I do any better on this?


    Perfect! Bottom posting and truncated quotes. :)

    I wish you luck - and fun!

    Kind regards

    robert
     
    Robert Klemme, Oct 17, 2006
    #17
  18. Dave wrote:

    > We had a wonderful framework package in one module that the architect
    > created where these classes were supposed to go. But he didn't follow
    > up on this and after three development cycles in 9 months, the
    > additional 240 classes were created in so many modules and so many
    > different packages it is unbelievable. Also, the number wouldn't be
    > that much of a problem if so many of the classes (objects) weren't very
    > similar in various ways.
    >

    Sounds to me as if the system designer (architects design buildings so I
    won't call him that) didn't decompose his design to a deep enough level
    to recognize these classes.

    The design sounds incomplete. I wonder about the following:
    1) was the designer prevented from or unwilling to do that
    2) why didn't the programming manager put rules in place for adding
    classes to the framework package
    3) did the project manager unleash the coders before the design
    was complete

    Regardless of what happened, it sounds like a mess.

    I've been there, done that. A long time back an organization I was in
    started two similarly sized projects at the same time. Both were online
    database systems that ran on the same mainframe. Mine took the time to
    get the requirements, functional spec and the application structure
    right before we started coding. The other project rushed those stages
    and started system testing while we were still integrating modules for
    our first, simplest set of user screens. We got jeered at then, but we
    had the last laugh: our entire system was live with additional users
    demanding access to it while the other bunch, having failed entirely to
    complete system testing, were starting a major redesign and junking code
    right left and center. I changed jobs at that point, so don't know what
    happened to the other project. Mine was in use for 14 years and only
    shut down because its originally mandated platform (COBOL/IDMS/ICL 3900
    mainframe) was being replaced with UNIX servers and an RDBMS database.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Oct 17, 2006
    #18
  19. Dave wrote:
    >
    > The problem isn't as much the number, as how to get the developers to
    > re-use what is there when it is scattered everywhere, not named
    > properly, not documented and they don't make much of an effort to look
    > for a class to re-use or inherit from unless you make it really easy
    > for them. It takes them five minutes to create a new one, so they all
    > do that instead. In one month we added 30 more.
    >

    Two words Javadocs and cvs.

    Can you and your management force them to code to adequately documented
    Javadocs standards and place source files in a central source repository
    once it clean compiles?

    The repository could be cvs, subversion or even PVCS if development is
    on PCs rather than a central server.

    This would allow you to run an overnight source extract and compilation
    against the repository (which may smoke out some more problems ahead of
    time) as well as generating Javadocs output and making it available to
    the developers via an intranet web server. This would remove their "we
    can't find it" excuse for not re-using existing classes as well as
    improving documentation.

    > I would love to have all of their current relationships mapped out,
    > have all of their fields listed and fill a wall with it to illustrate
    > to the developers what they are doing.
    >

    Using Javadocs, as described above, would be a start.

    That will, at least index all publically declared constants, variables,
    methods, classes etc. If you need more help it should be simple enough
    to do further custom processing on its index pages.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Oct 17, 2006
    #19
  20. Dave

    Daniel Dyer Guest

    On Tue, 17 Oct 2006 14:52:17 +0100, Dave <> wrote:
    >
    > He called himself a 'pure OO' programmer, which is why I used that
    > term. He was also fired for trying to refactor everyone else's code on
    > that project into the same garbage, and then when I caught it during
    > code reviews and management and I explained why that was a bad idea for
    > maintenance, he deleted everything he'd ever written including out of
    > VSS and then he was fired. Luckily there were recent backups of that
    > drive.


    Sounds like you are well rid of him.

    Are you still using SourceSafe? That's really going to bite you on the
    arse with your developers are working remotely, let alone in separate
    timezones. SourceSafe is well... actually not safe for putting your
    source in, it sucks for remote access and it cannot handle commits from
    different timezones without doing scary things to your repository.

    This is required reading:
    http://www.highprogrammer.com/alan/windev/sourcesafe.html

    An alleged quote from an unidentified Microsoft employee:

    "Visual SourceSafe? It would be safer to print out all your code, run
    it through a shredder, and set it on fire."

    Dan.

    --
    Daniel Dyer
    http://www.uncommons.org
     
    Daniel Dyer, Oct 17, 2006
    #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. Guadala Harry

    Consolidating Sites - DNS Implications

    Guadala Harry, Feb 6, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    340
    bruce barker
    Feb 6, 2004
  2. =?Utf-8?B?cG11ZA==?=

    Consolidating images in one folder in wwwroot

    =?Utf-8?B?cG11ZA==?=, Apr 5, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    389
    =?Utf-8?B?cG11ZA==?=
    Apr 5, 2005
  3. lbrtchx
    Replies:
    1
    Views:
    362
  4. 7stud
    Replies:
    11
    Views:
    717
    Dennis Lee Bieber
    Mar 20, 2007
  5. Steve Drach
    Replies:
    3
    Views:
    221
    Thomas E Enebo
    Jun 20, 2004
Loading...

Share This Page