SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)

    class library first, app second?

    I think the open source community would be a lot more productive if they built class libraries for their apps, and maintained them in a separate tree or repository, and then built the app using the class library, instead of just building the app and mixing it all together.

    Lastcraft touched on this here: http://www.sitepoint.com/forums/show...2&postcount=41

    If you have a class library as a foundation you can pretty much assemble the app however you want, or more easily customize it to fit your needs.

    I'd like to know everyone's thoughts on this as I'm thinking of starting an open source project for a class library for Amazon web services. I may create two trees -- one for the class library, another for an app that uses the class library.


    Thoughts?

    --ed

  2. #2
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As Marcus said: "The community has bogged itself down redoing each others work."

    I'm sure there are Amazon PHP classes out there - perhaps you could lend a hand there? If there is a PHP app that does this, try and help break it apart into "coherant classes"?

    I don't know what's out there - though I'm sure there's something...

    Douglas
    Hello World

  3. #3
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by coo_t2
    I think the open source community would be a lot more productive if they built class libraries for their apps, and maintained them in a separate tree or repository, and then built the app using the class library, instead of just building the app and mixing it all together.
    That is really really hard to do. The first time around you get a class library that is tuned to that app. only. It is not even obvious which parts are the library and which parts are the app. A good class library is distilled and should really come from more than one author, or if not at least from an author that has written a lot of client code in that field.

    That said you have to start somewhere and just getting feedbaclk from users will get you a better library . Don't forget to remove stuff when no one wants it. Good libraries are small.

    Now the rant...

    Regarding the bogging down point, part of this I think comes from the PHP communities infatuation with frameworks. The're a bit like template engines. PHP is already a flexible framework. I don't need someone to build an application skeleton for me to fill in the blanks as app. skeletons are easy to write in PHP. Why restrict myself to someone's plug-in architecture when I can instantaite a class in a single line?

    Writing frameworks is even harder than writing libraries and takes an enormous amount of experience. Also you can only ever use one framework in your application.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  4. #4
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Also you can only ever use one framework in your application.
    Now that is the best point I've read all day.

    Douglas
    Hello World

  5. #5
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Software patterns give a different spin to the idea of software libraries. With patterns you custom build the application with the same ideas rather than the same libraries. That's not saying that you don't reuse code; you do and that is a goal. It's just a different spin.

    Writing good, reuseable code is hard, writing a good framework from good reuseable code is even harder. Looking around, I think PHP is making a lot of progress on this front. I am seeing much more consistency from library to library and from framework to framework in how things are done.

    PHP5 is helping because as the rewites are happening people are looking around and moving towards a smaller set of solid solutions. In a year or so I think the PHP5 library/framework landscape will be looking pretty good.

  6. #6
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Also you can only ever use one framework in your application.
    In fact that may be the very definition of the distinction between library and framework.

  7. #7
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    coo_t2: yes I think that's a good idea. If you get to the stage where you have several different apps all sharing the same core library, it ought to be easy to deploy a library update once for all (with tests to make sure it integrates properly into each specific app). Validation code for example is likely to be eminently sharable. A common core ought to make maintenance easier by avoiding umpteen different flavours of the same thing in different apps.

  8. #8
    SitePoint Addict pointbeing's Avatar
    Join Date
    Jun 2004
    Location
    London, UK
    Posts
    227
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    A common core ought to make maintenance easier by avoiding umpteen different flavours of the same thing in different apps.
    This is exactly what I've been trying to achieve in practice - I want that all our apps (public facing, site-facing, intranet, even the SOAP stuff) should be little more that homogeneous interfaces to the same core.

    It's probably unprofessional to say this but we really do have millions of lines of legacy code - some of it of an appalling standard. It really has been a case of 'just building the app and mixing it all together'. And since there is no consistency or shared libraries or common framework, it's almost entirely impossible to refactor. And I'm not willing to let that continue, not on my watch

    To be honest, I don't know which parts of it all would described as class libraries and which as framework but I think what you're talking about is not just a good idea - it's a business necessity.

  9. #9
    Non-Member coo_t2's Avatar
    Join Date
    Feb 2003
    Location
    Dog Street
    Posts
    1,819
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...



    That is really really hard to do. The first time around you get a class library that is tuned to that app. only.
    But wouldn't this still be an improvment over not having a class library for the app? Would it make life easier, in as much as it relates to that one app?

    --ed

  10. #10
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is a little bit of a chicken and egg question because often libraries come from building several applications using the same conceptal framework and having the common code fall out as you refactor. I find that my common code evolves over time as well. My one concern about base libraries is that sometimes they cause you to code to librariy instead of coding to the needs of the app.

  11. #11
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by coo_t2
    But wouldn't this still be an improvment over not having a class library for the app? Would it make life easier, in as much as it relates to that one app?
    I think the best approach is to think small at first and not to be too ambitious. For example the SPL allows classes to work in foreach loops. Great idea and everybody would use that. A tightly focused library.

    Then they added a rewind() method and now every iterator has to implement it, loading all their data as they go. Not everyone wants to do that just so they can use foreach. If you don't implement rewind() then you have to state it in the documentation, because now you are breaking the interface. The solution got grander and just caused everyone more work.

    Then came RecursiveIteratorIterator and now you have to wade through a load of docs just to figure out what it's for. Next is trying to map every standard exceptions . Programmers love telling each other how to code so why not tell every programmer how to code .

    Had it just stopped at the foreach behaviour and added the other stuff as separate libraries, we would have something people would actually want. They could have put heir own iterators over the top if they didn't want the ones supplied.

    The bigger the vision, the more useless the vision.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #12
    SitePoint Zealot
    Join Date
    Dec 2003
    Location
    with my kids
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A common core ought to make maintenance easier by avoiding umpteen different flavours of the same thing in different apps.
    but a common core has its own set of problems. when you go that common route, you end up with two dozen apps all dependent on the same core code, and it starts to harden in to place. if you're not super careful with tests, builds, etc., it easily becomes a house of cards. refactor the core to enhance one app or enable a new one, and watch apps #18 and #23 crumble. some functionality in the core gets welded into place for just one minor piece of one app, and there it lives through all legacy.

    it's a tough balance.

  13. #13
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by josheli
    refactor the core to enhance one app or enable a new one, and watch apps #18 and #23 crumble.
    It's a known problem with a known solution: DependencyInversion...

    http://www.phplondon.org/wiki/DependencyInversion.

    Slightly more work, but worthwhile if rework is significant. Basically you put an interface and an adapter in pace to isolate some application code you don't want to refactor. You definitely want to be free to refactor the library, because that is how it becomes more powerful.

    A large chunk of the book Domain Driven Design (Eric Evans) is devoted to this problem.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  14. #14
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's probably unprofessional to say this but we really do have millions of lines of legacy code - some of it of an appalling standard.
    Isn't that what Service Oriented Architecture is all about? So you do not need to get into the guts of legacy code...


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •