This discussion is archived
1 2 Previous Next 22 Replies Latest reply: Nov 13, 2010 11:59 AM by 796440 Go to original post RSS
  • 15. Re: Factory Pattern
    jduprez Pro
    Currently Being Moderated
    I don't consider the Java API as an authoratative source of anything except describing how the API works. And it doesn't always get that right either.
    ;o)
    Yes, but I meant, with my two posts, that several people, smarter than "yours truly jduprez", have understood that derived meaning from the "fatory" patterns.

    Your quote from the GoF book is a strong point, in that it is the book by which most people know the pattern. I verified on a copy at work this morning, and the book does not mention caching and reusing in either Abstract Factory and Factory Method's Motivations, Applicability, Consequences nor Implementation section.

    Since the book's version of the patterns makes no such opening, and this is the text by which most people know the pattern, then one doing caching/reusing should not call that a factory, even if some constructs might tolerate mixing the approaches.
    In that latter case, and if someone is interested in documenting such constructs as a proposed pattern, he should use a new term to define that concept (e.g. "Object Provider: Defines an interface for providing an object, but let subclasses decide whether and how they create a new instance, or they reuse a cached instance").

    I stand corrected.

    Yours truly,

    J.
  • 16. Re: Factory Pattern
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    If one is going to mix them then I think it would better to use a factory in a pool rather than using a pool in a factory.
  • 17. Re: Factory Pattern
    269490 Newbie
    Currently Being Moderated
    jverd wrote:
    ttb999 wrote:
    Try saying in an interview that the main thing is to get a functioning application and you can always go back and optimize and see if you get the job.
    Irrelevant. The answer I gave is correct. I can't help it if your interviewer doesn't know that.

    If your interviewer is asking you to comment on the "efficiency" of a pattern, then either he doesn't know what he's talking about, or he's giving you a sneaky test.

    Additionally, that is exactly what I would say, and it's the answer I look for when I ask those sorts of questions when giving interviews. If someone were to not hire me because I gave that correct answer and he didn't realize it was correct, it's most likely not an environment I'd care to work in anyway.

    Edited by: jverd on Oct 28, 2010 11:43 AM
    I told some guy that most .0 version of applications are slower because they have just introduced new functionality and that sometimes they have to go back and improve performance at some areas of the code for the .1 release.
    People today seem to think you have to use the most efficient collection or whatever each and every time, rather than making things work and keeping the code clean and as simple and straightforward as possible.
  • 18. Re: Factory Pattern
    796440 Guru
    Currently Being Moderated
    ttb999 wrote:
    jverd wrote:
    ttb999 wrote:
    Try saying in an interview that the main thing is to get a functioning application and you can always go back and optimize and see if you get the job.
    Irrelevant. The answer I gave is correct. I can't help it if your interviewer doesn't know that.

    If your interviewer is asking you to comment on the "efficiency" of a pattern, then either he doesn't know what he's talking about, or he's giving you a sneaky test.

    Additionally, that is exactly what I would say, and it's the answer I look for when I ask those sorts of questions when giving interviews. If someone were to not hire me because I gave that correct answer and he didn't realize it was correct, it's most likely not an environment I'd care to work in anyway.

    Edited by: jverd on Oct 28, 2010 11:43 AM
    I told some guy that most .0 version of applications are slower because they have just introduced new functionality and that sometimes they have to go back and improve performance at some areas of the code for the .1 release.
    People today seem to think you have to use the most efficient collection or whatever each and every time, rather than making things work and keeping the code clean and as simple and straightforward as possible.
    You seem to be oversimplifying, or skipping a step or two entirely.

    When you write code, you don't do stuff like "I won't use a factory here because it will be faster," or "I'll do - - i instead of i - - because it will be faster." You write code that reflects your design. You write that code in a way that is easy to read, understand, test, debug, maintain, and enhance. You do keep performance in mind, for things like preferring O(n) algorithms over O(n^2), using buffers where appropriate for I/O, etc. And throughout the development cycle, you do test for performance and scalability, and make improvements where needed.

    Anybody who tells you to microoptimize the bejebus out of your code from day one and not worry about maintainability doesn't know squat about software development.

    And even in cases where performance requirements are exceptionally stringent, the question,"Is a factory pattern really more efficient?" is just nonsense.

    Edited by: jverd on Nov 3, 2010 1:55 PM
  • 19. Re: Factory Pattern
    jwenting Journeyer
    Currently Being Moderated
    ttb999 wrote:
    Try saying in an interview that the main thing is to get a functioning application and you can always go back and optimize and see if you get the job.
    If you don't, count yourself lucky as the company would haver seriously flawed ideas about software development.
    If you do, refuse the job offer because they offered to hire a moron.

    You see, the truth as always is somewhere in the middle.
    Yes, the main thing is to get a functioning application out the door on schedule and on budget, and that may mean corners need to be cut.
    But part of the definition of "functioning application" is that it meets performance requirements.

    And of course, as stated, choosing one pattern over another (in case there are several logical options) is unlikely to be the cause of serious performance problems. Forcing a pattern on an application that's inappropriate for it however can very well cause serious problems, not just (or not as much even) performance problems as major headaches in the development process, causing delays, cost overruns, bugs, slipping delivery schedules, unhappy customers.

    That's why someone making the claim you state should never get a job, and any company offering to hire someone like that is not a company you'd want to work for.
  • 20. Re: Factory Pattern
    jwenting Journeyer
    Currently Being Moderated
    jverd wrote:
    When you write code, you don't do stuff like "I won't use a factory here because it will be faster," or "I'll do - - i instead of i - - because it will be faster." You write code that reflects your design. You write that code in a way that is easy to read, understand, test, debug, maintain, and enhance. You do keep performance in mind, for things like preferring O(n) algorithms over O(n^2), using buffers where appropriate for I/O, etc. And throughout the development cycle, you do test for performance and scalability, and make improvements where needed.
    yes and no. If you know in advance that a specific code construct will cause a performance bottleneck you'd best avoid it. This of course will be specific to specific points in an application, and not a sweeping general statement like "factories are bad for performance so we never use them".
    Anybody who tells you to microoptimize the bejebus out of your code from day one and not worry about maintainability doesn't know squat about software development.
    Depends. If it's a one-off extremely time critical application with very limited expected lifetime (say something that's going to be loaded onto a sounding rocket or an interplanetary space probe) that may well be the thing you need.
    In general though, you're right.
    And even in cases where performance requirements are exceptionally stringent, the question,"Is a factory pattern really more efficient?" is just nonsense.
    Probably. A discussion about whether a specific implementation is efficient enough of course may well be appropriate.
  • 21. Re: Factory Pattern
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jwenting wrote:
    jverd wrote:
    When you write code, you don't do stuff like "I won't use a factory here because it will be faster," or "I'll do - - i instead of i - - because it will be faster." You write code that reflects your design. You write that code in a way that is easy to read, understand, test, debug, maintain, and enhance. You do keep performance in mind, for things like preferring O(n) algorithms over O(n^2), using buffers where appropriate for I/O, etc. And throughout the development cycle, you do test for performance and scalability, and make improvements where needed.
    yes and no. If you know in advance that a specific code construct will cause a performance bottleneck you'd best avoid it. This of course will be specific to specific points in an application, and not a sweeping general statement like "factories are bad for performance so we never use them".
    That however should be part of the design phase not the implementation phase.
  • 22. Re: Factory Pattern
    796440 Guru
    Currently Being Moderated
    jwenting wrote:
    jverd wrote:
    When you write code, you don't do stuff like "I won't use a factory here because it will be faster," or "I'll do - - i instead of i - - because it will be faster." You write code that reflects your design. You write that code in a way that is easy to read, understand, test, debug, maintain, and enhance. You do keep performance in mind, for things like preferring O(n) algorithms over O(n^2), using buffers where appropriate for I/O, etc. And throughout the development cycle, you do test for performance and scalability, and make improvements where needed.
    yes and no. If you know in advance that a specific code construct will cause a performance bottleneck you'd best avoid it.
    Of course. But how often do you know in advance that a factory will cause a performance bottleneck? Actually know, not just assume. It's reasonable to be concerned that it might, but if a factory fits the design, then don't just not use one because you assume it will be a performance problem. Test it.
    Anybody who tells you to microoptimize the bejebus out of your code from day one and not worry about maintainability doesn't know squat about software development.
    Depends. If it's a one-off extremely time critical application with very limited expected lifetime (say something that's going to be loaded onto a sounding rocket or an interplanetary space probe) that may well be the thing you need.
    In general though, you're right.
    Yeah, I was talking about "always microoptimzie the bejebus out of your code" as a general approach (which, IIRC, seemed to be what the OP said he was being told) as opposed to "microoptimize the bejebus out of this particular code because of these valid reasons."
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points