Announcement Announcement Module
Collapse
No announcement yet.
Spring != OO support ... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by yatesco
    I think it is to do with responsibilities. Sometimes, whilst trying to avoid the anemic model it is too easy to go to a fat model (excuse the terrible analogy ).
    An O/O model is what I like to call those - Overweight/Overachieving.

    Originally posted by yatesco
    The good old example I always use is bank accounts, should a bankAccount be created (account.create()), or should a Bank create an account (Bank.create(account)).

    I personally think account.create, or someObject.storeOn() is a leakage of concerns. An object should do *one thing*, but do it very, very well
    I'm not sure those two examples are analogous to one another. Account and Bank are domain objects with an owning/managing relationship. A create() method on both of them, with the domain/business logic pertaining to their own particular scope of concerns, makes a lot of sense to me. Account.create() would be responsible for the logic necessary to mave an Account instance to a "created" state. Then that scope is enclosed by that of Bank.create(), responsible for the account creation logic a Bank instance should be concerned with (and cannot/should not be concerned by an Account instance), e.g., validating that the account to be created conforms to certain Bank rules. And to make it more mind-numbing, don't forget there is likely to be a service layer, say, BankingService, around the domain that defines/addresses a yet larger scope of concerns.

    On the other hand, the relationship between SomeObject and Media is entirely different from that between Account and Bank. The scopes of SomeObject and Media are orthogonal to each other - We could as well replace Media with ARandomVisitorDoingRandomThingsWithSomeObject. This orthogonality becomes a lot clearer once we look at "object persistence" as a use of the object, rather than a characteristic of the object.

    Comment


    • #32
      Originally posted by jladd
      Consider a Book and a Library.
      If you ask the Library to put the Book on a shelf then the library must ask the book which category its in. Doing so means some sort of 'get' from the book. However, if you ask the Book to return to a shelf in the library 'book.returnToShelfIn(library)' then book which has the information about its category can ask the library to do the work: library.putBookInCategory(book, category)'
      This approach decouples the book and the library. If you asked the library to put the book on a shelf without the category then it has no choice but to ask the book for the category. This 'asking' will bind it to the book and possibly the type of category object returned.
      I actually thought it would be quite the contrary - having a book concerned about returning itself to the shelf would actually couple the book and the library more tightly. The concept of "shelf" is entirely a concern of a library, and completely orthogonal to a book. Coupling book to library or shelf is limiting its reusablity - a book could as well be for sale on eBay and has nothing to with any library, let alone "shelf". On the other hand, it's quite OK to bind a library to books and categories, because a library is supposed to be about books and categories, isn't it?

      Comment


      • #33
        More good replies ...

        manifoldronin those are good points.

        I guess its really hard to find the perfect example but what I am trying to say is that:

        1. Orthangonal. good.

        2. Having set/get of a Category on book binds the concept of a category
        to a book. bad.

        The subtle point I was trying to make in my poor example was that by asking book to return to a shelf in a library meant it was upto the book how to get there. Asking the library to put the book on a shelf and it explicitly asking the book for a category (get) meant that book must now always have a category.
        Which may be the case now and for all time but the first approach didnt make this binding so.

        Asking book to be put on a shelf in a library means it is upto book how that is done without imposing attributes of book to do so. Yes this does depend on the interface of library and maybe the same problems apply but I think the range of libraries is a little smaller than books.

        This is probably another subtle point but I hope it isnt lost.

        Thanks again for the great responses. This thread is great because of your participation.

        Rgs, James.

        Comment


        • #34
          I just wanted to say "thank you!" to all people posting to this thread. It is certainly one of the most interresting threads I've read in this forum.

          Regards,
          Peter

          Comment


          • #35
            Your welcome ....

            Im really glad that what the thread which I purposly started with a rather contraversial statement "Spring != oo" worked out so well.

            Spring people must be genuine as no one has shot me down for making the statement but instead worked through various discussions which many have found useful.

            Now if i could get an answer to my thread on spring and soap then maybe there would be another thread we could all enjoy

            Thanks all.

            Rgs, James.

            Comment


            • #36
              I think Spring is MUCH MORE than OO, I won't say it is not OO, and even it is, I won't feel uncomfortable.
              OO is NOT the ultimate answer of programming, it is here for decades, and it misses a lot of things.
              For example, OO want polymorphism, it is supposed that many concrete classes can replace each other. But in the old OO way, like struts's Action, you must extend its Action to write your own, and EJB want you extend his class too, and much much more frameworks want you extend their class. So how could you reuse your business logic code? Spring's pojo is a much better solution.
              I am currenlty reading "Component Software:Beyond Object-Oriented Programming(second edition)". It points out many (partly)false claims of OO.
              Spring and other IOC frameworks are a new way, and AOP is also.
              I remeber that an author of UML said that UML can't model some real requirements in computer readable way (logging, security etc). Spring's AOP can be the solution.
              We need more than OO to build a decent framework.

              Comment


              • #37
                Ill have to get that book and see what it says.
                Thanks for the response.

                Rgs, James.

                Comment


                • #38
                  Originally posted by siberian
                  For example, OO want polymorphism, it is supposed that many concrete classes can replace each other. But in the old OO way, like struts's Action, you must extend its Action to write your own, and EJB want you extend his class too, and much much more frameworks want you extend their class. So how could you reuse your business logic code? Spring's pojo is a much better solution.
                  Just because you are extending a class does not mean you are implementing an OO design; Sitting in a garage doesn't make me a car

                  Yes, one of the main principles of OO is polymorphism which Spring *does* encourage by its best practice of using interfaces to define collaborator contracts; yes, implementing an interface is also a form of polymorphism.

                  I also think Spring does the right thing with most of it's internal hierarchies; AbstractController, BaseController etc.

                  You have found excellent examples of how to abuse inheritence, but that does not mean inheritence is a flawed concept

                  Originally posted by siberian
                  We need more than OO to build a decent framework.
                  I think it would be more correct to say a good framework doesn't need to follow OO (although I would find it quite unnatural to use).

                  HTH.

                  Comment


                  • #39
                    Originally posted by yatesco
                    Just because you are extending a class does not mean you are implementing an OO design; Sitting in a garage doesn't make me a car

                    Yes, one of the main principles of OO is polymorphism which Spring *does* encourage by its best practice of using interfaces to define collaborator contracts; yes, implementing an interface is also a form of polymorphism.

                    I also think Spring does the right thing with most of it's internal hierarchies; AbstractController, BaseController etc.

                    You have found excellent examples of how to abuse inheritence, but that does not mean inheritence is a flawed concept


                    I think it would be more correct to say a good framework doesn't need to follow OO (although I would find it quite unnatural to use).

                    HTH.
                    sorry but I think you don't understand my point, or I haven't make it clear.
                    I didn't mean inheritence is a flawed concept. I mean in the old OO way, it is easy to abuse inheritence, indeed, we have to. I don't think authors of struts or EJB don't understand OO, they have no choise. Many OO guide line is not flawed on its own, but they are hard to implement in real program using exist tools, so I call them "flawed"
                    I belive that to avoid unneeded inheritence is introduce by gang of four's design pattern, and now most programmars agree with that.
                    I should not have mention the (component) book here, since most of us don't have a copy. But there are another examples which is missed in (old) OO:

                    (OLD)OO use interface to enforce polymorphism. but interface is far from a contract. How about the pre conditions, how about the post conditions, and even if there is pre and post conditions(there are indeed hard to write), it is not enough. Since a method invoked on different context can cause different result. If it is enough, why we need state charts to model a system's behavior? Maybe ejb's stateless bean is a good idea.
                    polymorphism needs something other than interface, that is factories, without them, you can't switch between concreate classes without hard code IFoo foo = new ConcreateFoo(); I think factories is not introduce by oo languages themselves, but soon the programmer found they are important. I was writing configuration driven factories in almost very my projects, but now I throw all of them in favor of Spring's configuration driven beans.
                    (OLD)OO has no solution for logs or other crosscut requirements, that is why spring and others introduces AOP.

                    Before OO, there is procedure-oriented. when they invent it, they said it is enough, but it is not. The work of procedure-oriented still affect today's programming, at least no one want to use goto or other bizarre flow controls anymore.

                    Then it is OO. To use OO doesn't means all the guide lines of procedure-oriented is wrong, OO inherite them, not replace them.
                    So my point is: spring has some "new" ideas and guide lines. Some think it is not OO, but I don't think so, I think those are next generation of OO which is missed in old OO way. So "is spring OO" is somewhat hard to answer, but "is spring encourage polymorphism" is YES.
                    If you think any correct thing based on "old OO" should be called OO too, I won't disagree.
                    But for me, I won't mind if the authors (maybe you)say spring if more than OO.Indeed I think spring have so many new ideas that it is a revolution, not evolution.

                    And maybe I didn't get the main point of this thread? I was fooled by the title and look through the posts too quick. I was thinking your are discussion "if using spring is a OO way", but maybe your are talking about "if spring itself is OO"?
                    If it is the case, I am sorry.
                    But if we read the classes one by one of every container, you can find some "non-oo" code.
                    Last edited by siberian; Apr 26th, 2006, 12:10 AM.

                    Comment


                    • #40
                      Originally posted by siberian
                      But for me, I won't mind if the authors (maybe you)say spring if more than OO.Indeed I think spring have so many new ideas that it is a revolution, not evolution.
                      No, I am not an author.

                      The OP original question was whether Spring encouraged the use of non-OO techniques, not whether Spring itself was OO.

                      You raise some interesting points, but I am not convinced that they are orthoganal to OO. Is AOP defined in the OO "spec"? No, but does that mean it isn't an OO implementation? Also no. To put it another way; what is it about AOP (for example) that *isn't* OO? If done correctly you are creating objects that do one thing and one thing well (logging, security, transaction, caching etc.), are internally consistent, reusable etc. (I use AOP because you mentioned it)

                      You also mentioned IoC/Factories as distinct from OO. Again, I am not sure I see the problem; OO didn't define the concept of factories, but that doesn't mean the factory pattern is not an OO compatable pattern....

                      I see OO more as a style of development; a set of guidelines on how to design "things" in your model. That is not to say it isn't prescriptive or definitive; it is, but I do not see OO as a framework, or toolkit itself; just because people are doing things that aren't explicitly defined in the OO spec (which I still cannot find BTW ) doesn't exclude those things from being OO.

                      Maybe I have a more general definition of OO than you, not sure. I think that is one of the problems, that OO means so many things to so many people. I know a lot of people that equate EJBs with OO! Others think that that stateless service facades with value objects are OO; even though that is actually the most common anti-pattern ever, and is actually just procedural programming implemented in an OO language.

                      Maybe I should get hold of a copy of your book and read that. It sounds very interesting.

                      I still maintain that while a decent framework *may* contain non OO code, it certainly *isn't* the case that a decent framework cannot be used, or implemented in an OO way.

                      After writing all this I thing we actually agree on most things. I think where we differ is in the use of "old OO". I just don't see the existance of "old OO". I see lots of new patterns being implemented in an OO fashion

                      P.S. I think this is an excellent thread, and would really benefit from some real OO/domain design gurus joining us (apologies to you if you already have )

                      Comment


                      • #41
                        Originally posted by yatesco
                        After writing all this I thing we actually agree on most things. I think where we differ is in the use of "old OO". I just don't see the existance of "old OO". I see lots of new patterns being implemented in an OO fashion
                        well, this is the point.I don't mind if we have to lable spring as "OO inside", or call it "real OO", but I won't insist on it.
                        When I was learning GOF's design patterns, some argued that it is not OO. But no one will say this anymore.
                        Originally posted by yatesco
                        (I use AOP because you mentioned it)
                        AFTER I metioned it??So soon?
                        I am monitoring the AOP poineer aspectj for years, indeed the authors are very worry about the fact that some says it is not OO. I saw they write documents to insist that it is OO. But they also point out the
                        mutil-dimension idea is not there is old OO(sorry can't find a better word) And another dead AOP poineer HyperJ uses a parable to describe its idea: AOP to OO is like 3D space to 1D space( a string). but they still have to publish their paper on a OO conference.
                        To my view, every technique is changing, PO-OO, and then design patterns, tons of frameworks and now IOC and AOP. they inherient much of past techniques, but introduce something new.
                        If something is cool but does not introduce new ideas in the basic theory, like struts, I would call it another (boring) OO framework.
                        If something is cool and introduce new ideas in the basic theory, I won't mind we call it OO or not. And Spring(IOC) and AOP is the case.

                        About the book, I was very regreted after I bought it based on other's review, after all, its title looks boring, just like another book on inheritance, MVC etc. But after I read it, I think it is superb(but somewhat outdated). It point out that many oo concepts is very hard to implement in real programs, and to my own experience, it is true:
                        Encapsulation: supposed to hide underline state from the callers, but too easy to be broken, inheritance can break it, and if A call C, then C call A, some re-entrance will happen and everything become mess.
                        for example, B has B.open and B.close.
                        in A.foo:
                        B.open
                        // some stuff
                        B.close
                        seems to be OK, but if those stuff call C.foo which call other method of A which call B.open/B.close, then it crushes. So A MUST care what C is doing.
                        it is just a simple sample, maybe we are told to avoid this cross-layer cycle, but in a real program, it can trace many classes to form a cycle chain. And the event/listener pattern doesn't solve it, it make things worse(just this problem, don't mean it is a bad idea), since no matter what event you use, the code will be called.
                        Polymorphism: interfaces are far from a complete contract. The UML state chart with UML's OCL is a example which is more likely a complete contract, In the best case, interface can model a stateless module, but any serious program needs state.
                        "Wiring" the components: components(classes) are hard to be connected. It list many issues, here is one: a real framework need its applications to inherit
                        some common interface/class, which is a nightmare.
                        and much more...

                        The book argues that CO(component oriented) is more than OO, it even claims that OO "has failed". I am not quite sure about that since most its idea is based on the lessons learned from OO, not a rework, and it doesn't give some silver bullet to solve the problems it lists. But anyway, I don't mind.

                        It seems that the author knows little about spring, it was not there when he wrote his book, I think some of his problems can be resolved by spring(and AOP), but still, there are tons of them.

                        Comment


                        • #42
                          Originally posted by siberian
                          well, this is the point.I don't mind if we have to lable spring as "OO inside", or call it "real OO", but I won't insist on it.
                          The topic seems to be moving from "does spring force you not to use OO" to "is Spring *itself* OO". That is a different (although equally) valid discussion.

                          Originally posted by siberian
                          I am monitoring the AOP poineer aspectj for years, indeed the authors are very worry about the fact that some says it is not OO. I saw they write documents to insist that it is OO. But they also point out the
                          mutil-dimension idea is not there is old OO(sorry can't find a better word) And another dead AOP poineer HyperJ uses a parable to describe its idea: AOP to OO is like 3D space to 1D space( a string). but they still have to publish their paper on a OO conference.
                          I can see that the concept of cross cutting concerns has no vocabularly within "traditional" OO, but I still do not see that as the same as saying AOP is incompatable with OO.

                          Originally posted by siberian
                          To my view, every technique is changing, PO-OO, and then design patterns, tons of frameworks and now IOC and AOP. they inherient much of past techniques, but introduce something new.
                          If something is cool but does not introduce new ideas in the basic theory, like struts, I would call it another (boring) OO framework.
                          If something is cool and introduce new ideas in the basic theory, I won't mind we call it OO or not. And Spring(IOC) and AOP is the case.
                          I think we agree on this one

                          Originally posted by siberian
                          Encapsulation: supposed to hide underline state from the callers, but too easy to be broken, inheritance can break it, and if A call C, then C call A, some re-entrance will happen and everything become mess.
                          for example, B has B.open and B.close.
                          in A.foo:
                          B.open
                          // some stuff
                          B.close
                          seems to be OK, but if those stuff call C.foo which call other method of A which call B.open/B.close, then it crushes. So A MUST care what C is doing.
                          it is just a simple sample, maybe we are told to avoid this cross-layer cycle, but in a real program, it can trace many classes to form a cycle chain. And the event/listener pattern doesn't solve it, it make things worse(just this problem, don't mean it is a bad idea), since no matter what event you use, the code will be called.
                          I would argue that this is probably badly designed anyway. If B is a resource with an open and close, then I would suggest it be responsible for it's own management and implement a callback approach:
                          Code:
                            interface ResourceCallback {
                              void doWithResource(Resource resource);
                            }
                          
                            class ResourceManager {
                              void execute(ResourceCallback cb) {
                                openManagedResource();
                                try {
                                  cb.doWithResource(managedResource);
                                }finally {
                                  closeManagedResource();
                                }
                              }
                            }
                          That whole pattern of otherClass.start(), otherClass.end() seems to be a code smell. Seems to close to the "don't ask; tell" principle. Spring BTW uses this callback mechanism to good effect (HibernateTemplate etc.).

                          Originally posted by siberian
                          In the best case, interface can model a stateless module, but any serious program needs state.
                          Why? What is it about interfaces that prevent you modelling state?

                          Originally posted by siberian
                          "Wiring" the components: components(classes) are hard to be connected. It list many issues, here is one: a real framework need its applications to inherit
                          some common interface/class, which is a nightmare.
                          and much more...
                          Again, who defines this restriction? Why *must* a "real" framework insist application components inherit common interfaces? Certainly struts has it's ActionForm and JSF has (whatever it has; I don't know ) but that isn't a core OO principle by any means.

                          I don't think I am understanding your point.

                          Originally posted by siberian
                          It seems that the author knows little about spring, it was not there when he wrote his book, I think some of his problems can be resolved by spring(and AOP), but still, there are tons of them.
                          This I can believe It is quite common that people cite a failing of a certain piece of technology/concept merely because they do not have the foresight to see the solution. "I cannot get X to work like this, therefore X must be flawed".

                          Please don't think I am being argumentative; I think this kind of discussion is really healthy.

                          I can however feel the ice under my feet becoming very thin though, and to quote a well used English phrase am starting to talk (a little bit) out of my butt

                          Comment


                          • #43
                            The post has become too long. so I don't quote them.
                            First of all. I always belive that struts/EJB/JDBC are not bad designed. Yes there are bad ideas, but in their time, they don't have much choice. So what is important is why it is so hard to implement the OO ideas, polymorphism, encapsulation etc. If so many guys who should be call gurus wrote some bad code, we should ask why?
                            I think PO has the same problem, it encourages reuse( don't know they use which word, but it is the idea), they think module is enough, but it is far from enough. So we need more theroy to make it work, then there is OO, but after decades, reuse is still somewhat a dream. So we need more theory.
                            For my example of encapsulation broken by code cycle, I don't think call back resovle the problem, call back is a good idea, but after all, the code get to be called. Indeed the author use a callback as one of the examples to explain the problem.if cb.doWithResource(managedResource); call another class with call another and finally one of them also call a ResourceCallback, it happens.
                            I don't mean open ... open ... close is a problem, I mean
                            open...open...close... close is also a problem, some resource can't be opened twice.
                            Maybe my example is a too simple to explain the problem. He(author of the book, again) use a real example which exist in real editors, that is the caret of the editor. I would like to explain it here, but is tooo long, so maybe you won't mind try this url(I just google for it)
                            http://www.softwareresearch.net/site...omponentSW.pdf
                            it is not the chapter itself, but a rework.
                            My experience don't come from the book, it is just they do a better work to explain it. If I said I have to do this in my code, well

                            For my argue that interface is far form a contract, I think it is a little more obvious. (this indeed has little connection with spring, but they are some projects work on this)
                            connection.open connection.close
                            how do you tell your client that don't forget call close after a open(you can say their understand open/close, but not only open/close must be called one by one)? The only way is to use plain English to write it in your javadoc, I think to use a plain English is suggest that the syntax has failed. And in most time they won't care, they just write their code until their get an Exception and "ohh!". sure spring's template is a solution in this case, but this is just the extreme simple case, and still a extra interface is needed.
                            If you have some interface like ATM, it has many states, in one state, 5 methods are valid, in another, 3 other methods are valid. In real programs, the only "solution" is to throw an Exception when the programmar makes a mistake.
                            the language should enforce the rule, we write the rules in script, then if the client don't do that, the compiler fails. I think this is only a type of context-sensitive thing.
                            Maybe you should try to translate a state chart with OCL to a interface, you can see the power of human language, and the weakness of (OLD) OO languages.
                            For my argue that containers which want we to subclass its class. Well, we can say it is a but idea and not suggested by OO. But why they do it? And why they don't call it "not OO" before spring is there? Because without it, the container can't control the contained objects(wiring objects with container). It ask the contained object to inherit some interface, so that it can call the interface when it want to. Even apache's lastest j2ee server geronimo do this, it want its module(not the applications) to inherit a common interface, sure many users are blaming them, but without spring, we won't blame them.
                            So I think we need more theory, just like the PO days, when we be told to reuse, we need more theory to really do reuse (and the result theory is polymorphism, encapsulation etc).
                            I think AOP introduce some new thoery(about crosscut), and spring(IOC) indeed introduce new theory about how to organize tons fo classes(I do think they should write some papers in a mathematics way, but I won't understand anyway. But spring is new, even newer then AOP). Before spring and other IOC containers, there are not thoeries about this, they are just "best practice" like to group them in layers.
                            With them, polymorphism and encapsulation become more practical.
                            Originally posted by yatesco
                            I can however feel the ice under my feet becoming very thin though, and to quote a well used English phrase am starting to talk (a little bit) out of my butt
                            what do you mean? Sorry but my English is not good enough to understand a parable(should be one?)
                            Last edited by siberian; Apr 26th, 2006, 10:42 PM.

                            Comment


                            • #44
                              Just want to say more about interface as a contract(contract between two classes).
                              An interface can model something about the contract, like method names, but it is not enough. A client using the interface can easily write a program which follow the rules enforced by the interface's computer part(javadoc is not computer readable, thus can't be used by java runtime), but still make it crush.
                              A contract is a contract. In a real word, a contract defines all the rights or the two sides, if anyone try anything not allowed by the contract, it is illegal. But if something is not defined "wrong" in the contract, it can be done.
                              The same is computer languages' syntax, if a program follow the syntax, it is a program, no matter how ugly it is.
                              Indeed, there are some languages try to make a interface a real contract, it adds pre conditions and post conditions to its syntax, so called DBC(design by contract). Java's assert can be used as a rough form of DBC, but you can't use it in interface.
                              And spring's template can be used as rough form of case sensitive rule. But it is not powerful enough to treat more complex cases. And this type of "callback" is one reason why the containers want its objects to inherit a interface
                              Still it is not enough, since context sensitive rules can't be model in pre condtions. State chart can do this. But an UML state chart is not readable by java compiler, yet.
                              There are projects try to do this.

                              Comment


                              • #45
                                Originally posted by siberian
                                what do you mean? Sorry but my English is not good enough to understand a parable(should be one?)
                                I mean I am not an expert on these things. While I have opinions, they are formed by some academic study (Bsc (Hons) Software Engineering) and some commercial experience (9 years developing mostly web based J2EE applications).

                                "Skating on thin ice" means I can not necessarily back up my claims with academically consistent proof.

                                "Talking out of my butt" means I have no idea what I am talking about (which is not quite true as I do know what I am talking about). For example, I could try and explain why gravity is strong enough to hold us on this planet, but weak enough to be broken by a tiny magnet, but given that I have absolutely no idea why; I would be on *extremely* thin ice, and absolutely talking out of my butt

                                HTH

                                Comment

                                Working...
                                X