1 2 3 Previous Next 31 Replies Latest reply: Mar 17, 2008 2:16 PM by 843853 Go to original post RSS
      • 15. Re: DAO Design pattern
        843853
        valooCK wrote:
        >
        LMAO! Am I really as bad as Valoo? You gotta give me more credit than that.
        duffy will transfer his abstract purple object to you as credit. but before that can happen, you need to understand what encapsulation is. simply wrap up something so that others dont have write their own code is not always encapsulation. one good way of checking is this:

        encapsulation produces abstraction.

        does a DAO produces abstraction? lets see: here you have a chickenDAO, and a duckDAO. what are the differences: the duckDAO has more functions than the chickenDAO, and thats it. you have only one abstraction. so thats not encapsulation.

        what is the difference between chickenDTO and a duckDTO? the former has more slots so that you can put more bits in it, and thats it. there is no chicken abstraction nor duck abstraction. so that's not encapsulation.
        Are you trying to talk again? It's not your forte.
        • 16. Re: DAO Design pattern
          796254
          wpafbuser1 wrote:
          duffymo wrote:
          ValooCK versus wpafbuser1. Oh, my.

          Wow, it's like Godzilla versus Mothra, or Predator versus Alien!

          It's the Battle of the Trolls for forum domination!

          %
          LMAO!
          So friendly...
          Am I really as bad as Valoo?
          It's kinda like ebola versus bubonic plague or the Black Death. Which would you say is "worse"?
          You gotta give me more credit than that.
          Do I? Earn it.

          %
          • 17. Re: DAO Design pattern
            843853
            valooCK wrote:
            wpafbuser1 wrote:
            But the primary advantages of the DAO pattern are encapsulation, a clean separation of business logic from data logic, and centralized access (to name a few).
            this clearly indicates that you have no idea of what encapuslation is. DAO is merely a collection of procedurals, nothing is encapuslated at all, everything is wide open.
            But daffy, we've already established that you've lost all your "you don't understand OO" privileges. Remember? That thread where you openly admitted to not understanding the fundamentals of inheritance or polymorphism? Here it is, in case you forgot

            http://forum.java.sun.com/thread.jspa?threadID=5273397&start=0&tstart=0

            The term "procedurals" is utterly meaningless, by the way
            • 18. Re: DAO Design pattern
              843853
              valooCK wrote:
              duffymo wrote:
              ValooCK versus wpafbuser1. Oh, my.

              Wow, it's like Godzilla versus Mothra, or Predator versus Alien!

              It's the Battle of the Trolls for forum domination!

              %
              as for you, man, gateways, datamappers are not what you think. dont use dao as a pattern in your code, its a shitiey way of doing things.
              But daffy, you're forgetting that you've recently "come out" as being completely ignorant of the most basic of OO concepts. Remember? Here it is, in case you forgot

              http://forum.java.sun.com/thread.jspa?threadID=5274699&start=38
              • 19. Re: DAO Design pattern
                843853
                valooCK wrote:
                >
                LMAO! Am I really as bad as Valoo? You gotta give me more credit than that.
                duffy will transfer his abstract purple object to you as credit. but before that can happen, you need to understand what encapsulation is. simply wrap up something so that others dont have write their own code is not always encapsulation. one good way of checking is this:

                encapsulation produces abstraction.

                does a DAO produces abstraction? lets see: here you have a chickenDAO, and a duckDAO. what are the differences: the duckDAO has more functions than the chickenDAO, and thats it. you have only one abstraction. so thats not encapsulation.

                what is the difference between chickenDTO and a duckDTO? the former has more slots so that you can put more bits in it, and thats it. there is no chicken abstraction nor duck abstraction. so that's not encapsulation.
                But daffy, you don't even understand what abstraction is! You told us so, just the other day in the following thread, remember?

                http://forum.java.sun.com/thread.jspa?threadID=5274699&start=38

                You really ought to stop now. You've admitted you don't understand these matters, stop trying to fit in
                • 20. Re: DAO Design pattern
                  jschellSomeoneStoleMyAlias
                  valooCK wrote:
                  NANDA wrote:
                  Hi,
                  what is the advantages of DAO Design pattern over other design patterns?
                  Can anybody tel me
                  the answer is none!

                  DAO stands for data access object, it is a non oo pattern, oo is data centric, it makes sense for data to access data. it is something created by poor procedural minds who can never understand what oo is.

                  you may occasionary use it as a collection of functionalities or utilities, but thou shalt never use in as a pattern in oop!
                  Note that dafei/valooCK is an ignorant idiot that revels in his absolute ignorance in absolutely everything.

                  Quite amazing really how he can be wrong on so many different topics.
                  • 21. Re: DAO Design pattern
                    jschellSomeoneStoleMyAlias
                    valooCK wrote:
                    wpafbuser1 wrote:
                    But the primary advantages of the DAO pattern are encapsulation, a clean separation of business logic from data logic, and centralized access (to name a few).
                    this clearly indicates that you have no idea of what encapuslation is. DAO is merely a collection of procedurals, nothing is encapuslated at all, everything is wide open.
                    Which simply demonstrates that you don't know how to implement them. And that you can't understand the pattern description either although you have probably never even read it.
                    • 22. Re: DAO Design pattern
                      3004
                      jschell wrote:
                      valooCK wrote:
                      wpafbuser1 wrote:
                      But the primary advantages of the DAO pattern are encapsulation, a clean separation of business logic from data logic, and centralized access (to name a few).
                      this clearly indicates that you have no idea of what encapuslation is. DAO is merely a collection of procedurals, nothing is encapuslated at all, everything is wide open.
                      Which simply demonstrates that you don't know how to implement them. And that you can't understand the pattern description either although you have probably never even read it.
                      implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                      • 23. Re: DAO Design pattern
                        843853
                        valooCK wrote:
                        jschell wrote:
                        valooCK wrote:
                        wpafbuser1 wrote:
                        But the primary advantages of the DAO pattern are encapsulation, a clean separation of business logic from data logic, and centralized access (to name a few).
                        this clearly indicates that you have no idea of what encapuslation is. DAO is merely a collection of procedurals, nothing is encapuslated at all, everything is wide open.
                        Which simply demonstrates that you don't know how to implement them. And that you can't understand the pattern description either although you have probably never even read it.
                        implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                        But daffy, we know you don't know anything about OO - you admitted it in the following thread, remember:

                        http://forum.java.sun.com/thread.jspa?threadID=5273397&tstart=0

                        Stop trying to fit in, go learn something
                        • 24. Re: DAO Design pattern
                          3004
                          georgemc wrote:
                          valooCK wrote:
                          jschell wrote:
                          valooCK wrote:
                          wpafbuser1 wrote:
                          But the primary advantages of the DAO pattern are encapsulation, a clean separation of business logic from data logic, and centralized access (to name a few).
                          this clearly indicates that you have no idea of what encapuslation is. DAO is merely a collection of procedurals, nothing is encapuslated at all, everything is wide open.
                          Which simply demonstrates that you don't know how to implement them. And that you can't understand the pattern description either although you have probably never even read it.
                          implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                          But daffy, we know you don't know anything about OO - you admitted it in the following thread, remember:

                          http://forum.java.sun.com/thread.jspa?threadID=5273397&tstart=0

                          Stop trying to fit in, go learn something
                          in that thread, i raised a question about the approperiateness of returning a discreationary concreate instance as an abstract instance. and i suggested that abstract objects be created.

                          part of that thread is advanced. if you are confused, i am not surprised.
                          • 25. Re: DAO Design pattern
                            843853
                            valooCK wrote:
                            georgemc wrote:
                            valooCK wrote:
                            jschell wrote:
                            valooCK wrote:
                            wpafbuser1 wrote:
                            But the primary advantages of the DAO pattern are encapsulation, a clean separation of business logic from data logic, and centralized access (to name a few).
                            this clearly indicates that you have no idea of what encapuslation is. DAO is merely a collection of procedurals, nothing is encapuslated at all, everything is wide open.
                            Which simply demonstrates that you don't know how to implement them. And that you can't understand the pattern description either although you have probably never even read it.
                            implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                            But daffy, we know you don't know anything about OO - you admitted it in the following thread, remember:

                            http://forum.java.sun.com/thread.jspa?threadID=5273397&tstart=0

                            Stop trying to fit in, go learn something
                            in that thread, i raised a question about the approperiateness of returning a discreationary concreate instance as an abstract instance. and i suggested that abstract objects be created.

                            part of that thread is advanced. if you are confused, i am not surprised.
                            Advanced stupidity, yes. There is no such thing as an abstract instance, it's a meaningless term. I'm not confused, it's pretty easy to work out you're rambling in an effort not to appear idiotic. It isn't working, by the way

                            But anyways, the opener of that thread:

                            >
                            since there can not be an instance out of an abstract class, and with the calendar class being abstract, what exactly does Calendar.getinstance() return?
                            >

                            You're not raising any questions about the appropriateness of anything there, daffy. You simply don't understand what a subclass is

                            >
                            hmm, i think it merely initilizes the fields and then create an oobject out of Object, and casts it to Calendar, and returns it.
                            >

                            Again, you're not raising any questions at all, other than "How come daffy still doesn't understand polymorphism, after 5 years?". All due respect, but surely even a rank amateur would have picked up some of this stuff simply by being here for 5 years
                            • 26. Re: DAO Design pattern
                              jschellSomeoneStoleMyAlias
                              valooCK wrote:

                              implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                              Gibberish.
                              • 27. Re: DAO Design pattern
                                3004
                                jschell wrote:
                                valooCK wrote:

                                implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                                Gibberish.
                                what gibberish? it is a matter so simple i would not say yo dont understand; you probablly just forgot when trying to be smart.
                                • 28. Re: DAO Design pattern
                                  843853
                                  valooCK wrote:
                                  jschell wrote:
                                  valooCK wrote:

                                  implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                                  Gibberish.
                                  what gibberish? it is a matter so simple i would not say yo dont understand; you probablly just forgot when trying to be smart.
                                  But daffy, there's no such thing as simple in your eyes. Whenever you discuss even the most fundamental of topics, you're convinced that there's something incredibly complicated going on behind the scenes, that only you know about, or understand, yet you're unable to provide any proof of this. For instance, exception handling: apparently, when the runtime encounters a try/catch block, it runs the code within the block twice, to see if any exceptions are thrown. Of course, in order to do this, it has to simulate any arbitrary external resources - sockets, files and suchlike - so that the real ones are not affected, and it also has to both throw and not throw an exception at the same time. Remember? Then there's this beauty

                                  http://forum.java.sun.com/thread.jspa?threadID=5273397&tstart=0

                                  Where, rather than simply return a subclass, a factory method constructs an instance of java.lang.Object, and uses voodoo to add members to it, then magickally casts it to Calendar before returning it

                                  Don't talk to us about things being simple
                                  • 29. Re: DAO Design pattern
                                    jschellSomeoneStoleMyAlias
                                    valooCK wrote:
                                    jschell wrote:
                                    valooCK wrote:

                                    implementations should not alter specifications. you can not distinguish wrapping APIs from encapsulation, which indicates you have no idea of what oo is all about. so trash your DAOs and DTOs, and stop passing references by bits. or go back to your institution.
                                    Gibberish.
                                    what gibberish? it is a matter so simple i would not say yo dont understand; you probablly just forgot when trying to be smart.
                                    Yes I know that you don't understand why it is gibberish. There is no need for you to point your lack of understanding out.