SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 63
  1. #1
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    netherlands
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    'Representing' roles (noun classnames) a sign of bad design?

    I often see classes having a role stated as: 'a representation of ...'
    I'm always having doubts when seeing this kind of classes, and I tend to agree with this feeling more and more. This representation roles are mosly passive nouns from a domain language. I found that these nouns attract a lot of responsibilitys.

    For example; An airplane, a noun, representing an airplane (hoho). Now, the application needs responsibilitys of shipping the airplane with all kind of passengers, needs to fly, land and unload. You can store the airplane class with all these responsibilitys, because, well, because it all has something to do with an airplane. The 'representation' role is too vague, and the noun as classname makes it even worse.

    I'm wondering if it's possible to create an application without nouns as classnames, without passive classes and therefor only with do-ers. I'm wondering if a design would be rather bad when it has these passive classes.
    I'm wondering if you should reconsider a design when you just wrote a classname as a noun.

    While I'm still tending to agree with these upcoming thoughts, I get locked down by phrases and designs all around me. For instance, Object design: RRC mentions the following:

    "On further examination, Paragraph proves a design gold mine! We can envision Paragraphs to be composed of text objects amd various kinds of nontextual objects representing graphics, drawings, figures, or even ParagraphBreak objects. Text is composed of characters that form Word objects that compose sentence objects"

    Design goldmine? These are just nouns collecting other nouns. They represent a normal paragraph but don't have any distinguise behaviour at all.
    The book even states 'information holder' as a good role. I already start putting questions when I see a class that has that role. Even though I can imagine some advantages for an information holder (lazy loading and others), it seems too passive, and more a sign of bad design.

    Furthermore, Domain Driven Design promotes the idea of designing in a way of the domain language. You'll see almost only noun classes.

    But then, mostly noun classes question your idea of allocating responsibilitys among them, and tend to end up as only a collection or a data holder. I might be wrong, but I think these representation classes are a sign of bad design, and I'd like to see what others think of this subject.

    Any thoughts?

  2. #2
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Manor,

    I agree with you pretty strongly for PHP, but I feel this is due to the transient nature of the language.

    Specifically, in Java or C++ it may make sense to model the interactions of a series of persistent objects based on the objects themselves. The idea has the obvious attraction of being easy to explain to beginners, and since the objects are going to persist, it makes a fair amount of sense to map the domain space to the object space.

    But then you start looking at other objects: "IOStream", "Writer", "SaxFilter".

    Those objects aren't domain objects, mostly. Instead, they're objects that have been factored out as design patterns.

    IMO, PHP suffers from this, since people tend to try to map Java or .NET patterns onto PHP, when the underlying semantics are different.

    Specifically, in PHP the code itself is transient -- it's going to run, perform a single step, and then exit. Accordingly, the interesting objects are not things like "airplane", "passenger", "special meal" in the so-called "airline domain", but more specific things like "seat request", "credit card authorization", "flight selection criteria" used in the "airline web reservation system" domain.

    Accordingly, my applications have objects like "XXX_Criteria" or "DB_Updater" instead of having "XXX" or "DB" objects. This may just be my own weird way of optimizing design, but if you think in terms of code flow, I think you want classes that are going to execute a significant fraction of their methods (maybe 40%) if they are loaded at all.

    There are some classes that violate this logic. ADODB springs to mind. But they do so because they are an overgeneralization of the problem space. I think it would be interesting to see what the performance difference would be if classes like ADODB contained code like:
    PHP Code:
     if (ADODB_LOAD_DELETE) {
       include_once(
    'adodb_delete.php');
     }
     if (
    ADODB_LOAD_INSERT_UPDATE) {
       include_once(
    'adodb_insert_update.php');
     }
     if (
    ADODB_LOAD_SELECT) {
       include_once(
    'adodb_select.php');
     }
     if (
    ADODB_LOAD_DDL) {
       include_once(
    'adodb_ddl.php');
     } 
    although I understand that they have started in that direction, at least so far as ddl is concerned.

    =Austin

  3. #3
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm wondering if it's possible to create an application without nouns as classnames, without passive classes and therefor only with do-ers. I'm wondering if a design would be rather bad when it has these passive classes.
    I'm wondering if you should reconsider a design when you just wrote a classname as a noun.

    While I'm still tending to agree with these upcoming thoughts, I get locked down by phrases and designs all around me. For instance, Object design: RRC mentions the following:

    "On further examination, Paragraph proves a design gold mine! We can envision Paragraphs to be composed of text objects amd various kinds of nontextual objects representing graphics, drawings, figures, or even ParagraphBreak objects. Text is composed of characters that form Word objects that compose sentence objects"

    Design goldmine? These are just nouns collecting other nouns. They represent a normal paragraph but don't have any distinguise behaviour at all.
    The book even states 'information holder' as a good role. I already start putting questions when I see a class that has that role. Even though I can imagine some advantages for an information holder (lazy loading and others), it seems too passive, and more a sign of bad design.

    Furthermore, Domain Driven Design promotes the idea of designing in a way of the domain language. You'll see almost only noun classes.

    But then, mostly noun classes question your idea of allocating responsibilitys among them, and tend to end up as only a collection or a data holder. I might be wrong, but I think these representation classes are a sign of bad design, and I'd like to see what others think of this subject.

    Any thoughts?
    Hi Manor,
    You will always need containers though. for example, I'm working in some image processing software and the business rules require that while the display of a collection of images is in one area of the view, it must be seperated into sides within a page, and pages within a group, and groups within the collection. And its requirements include moving a page from one place to another (possibly from a place in one group to a place in another group). The logical way is of course to have an ImageGroupCollection containing ImagePage's, and a ImagePageCollection containing ImageSide's and an ImageCollection to manage the control of it. Without these 'noun' classes to break the problem down into its logical domain types the code would be far more difficult and unnatural to read.

    I have read that a class without verbs is just an empty class, but i've found that sometimes you just need containers.

    Specifically, in PHP the code itself is transient -- it's going to run, perform a single step, and then exit. Accordingly, the interesting objects are not things like "airplane", "passenger", "special meal" in the so-called "airline domain", but more specific things like "seat request", "credit card authorization", "flight selection criteria" used in the "airline web reservation system" domain.
    Hi Austin,
    That's really what all applications do - perform functionality and then stop until another command is entered. It's not just php-based applications. But you still need to represent the domain/business objects to make your code represent your system in a unified language. You probably know how i feel about people saying php and other OOP lanagues have nothing to do with eachother, so I'll leave that alone...

    Regards,
    Eli

  4. #4
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lazy_yogi
    Hi Austin,
    That's really what all applications do - perform functionality and then stop until another command is entered. It's not just php-based applications. But you still need to represent the domain/business objects to make your code represent your system in a unified language. You probably know how i feel about people saying php and other OOP lanagues have nothing to do with eachother, so I'll leave that alone...

    Regards,
    Eli
    Eli,

    Granted that's what all applications do, but I think the "transactional" nature of PHP emphasizes the different perspective, at least for me.

    I don't think that "PHP and other OO languages have nothing to do with each other", but on the other hand I think it's a huge mistake to think that "PHP is just java with dollar signs in front".

    There's a discussion about a PHP Servlet Engine that I think shows this distinction -- people who like PHP like it because of the paradigm, not because of any innate quality of the language. (I find PHP-as-a-language frustrating at least once each day that I work with it. But it's still fun, just as my favorite video games are frustrating but fun.)

    =Austin

  5. #5
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Arrow

    Quote Originally Posted by lazy_yogi
    The logical way is of course to have an ImageGroupCollection containing ImagePage's, and a ImagePageCollection containing ImageSide's and an ImageCollection to manage the control of it. Without these 'noun' classes to break the problem down into its logical domain types the code would be far more difficult and unnatural to read.
    Eli, tell me truthfully: how many alternative ways have you explored to solve or describe this problem? Because it's easy to say that other solutions are more unnatural or difficult to read, but so far I haven't seen any serious attempts at finding alternatives from the OOP purists. There may now be dozens of ways to build a User object, but too few people are willing to entirely let go of the idea of a User object.

    Quote Originally Posted by lazy_yogi
    That's really what all applications do - perform functionality and then stop until another command is entered. It's not just php-based applications.
    I think Austin is trying to point out the difference in application runtime between PHP/Perl and languages for 'real' applications: a Java object may have a lifetime of several hours, even if the user is not interacting with the application, and a single object will use a large part of its behaviour during one session. But PHP applications are intended to have a lifetime of less than 100 milliseconds, because otherwise your site would get too slow. This means that the vast majority of PHP objects have a lifetime of less than 100 milliseconds, which puts a significant limit on the amount of behaviour that is used during each lifetime.

    That's the big difference between Java/C++ and PHP/Perl, and surely it must have an impact on how we perceive the objects within our applications.

    Quote Originally Posted by lazy_yogi
    But you still need to represent the domain/business objects to make your code represent your system in a unified language.
    IMO the application is the system. The implementation of the application is completely hidden from the client/user by the (user) interface, just like the interfaces within the application encapsulate the implementation of each object. I find it quite saddening how the OO community manages to strongly embrace encapsulation at the object level, but to totally abandon it when it comes to the application itself: by encouraging developers to build their applications around concepts that only have meaning in the user's reality, instead of using concepts that make sense within the application.

  6. #6
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    netherlands
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Eli, tell me truthfully: how many alternative ways have you explored to solve or describe this problem? Because it's easy to say that other solutions are more unnatural or difficult to read, but so far I haven't seen any serious attempts at finding alternatives from the OOP purists. There may now be dozens of ways to build a User object, but too few people are willing to entirely let go of the idea of a User object.
    I share the same thought. I have the feeling that most of these passive classes are only used because they are a known solution to a given problem. I think that other, more intelligent classes can be designed to accomplisch the same thing, or most likely, provide an even better and clearer solution.

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

    One of my favourite topics. There is no way I could keep out of this for long .

    Quote Originally Posted by Manor
    Any thoughts?
    At random...

    I definitely tend to find that the top level problems are more efficiently solved when I start thinking in terms of doing stuff. If you are scraping links from a page, it is easy to think of a structure straight away (programmers are good at that): Parser, Page, Link, Connection, Request, Response. You spend ages on five of those objects so that you can start work on the Parser, only to find that's where all of the work is. Structure by itself doesn't get the problem solved. It should be the servant of the solution.

    If you start with the idea of a LinkSucker (working title) you are on more fertile ground. You can also knock up a prototype of this as a single object to help you think about it. Likely you could get the whole job done with just a very few classes. I pretty much always tackle the top level problem this way nowadays. You get tighter solutions from taking code out, not putting it in.

    So roles became king. Spurred on by the success of this approach, and the use of MockObjects, I started to be really hardcore about this. It's surprising how far you can go. It's a shame we never finished that RBAC thread (anyone still got the link). There were some good discussions skirting this issue. You cannot always figure it out this way (at least I can't) so I have run into a bunch of exceptions so far.

    The most dramatic is when objects brush up against another system, such as a database. You have a load of classes which are pretty passive when looked at by the rest of the system. "DataObject" is a giveaway. However they have the job of transferring data to and from the external system. A sort of marshall that caches the data. Which leads me onto...

    Documents that are parsed one way and read back another will tend to be pretty passive. Again they are an alternate data representation, so the entirety of their role (parsing) is hidden inside the interface. You usually fill the DOM with a text stream, and then use accessors to collect aggregate unordered data. You could call the DOM a DocumentTranslator or DocumentAccessor, but most would just call it a Document. It would likely have internal data structures as well (such as pages). If you want to swap sources then you will want the parsing external, and the DOM ends up with a SAX interface. It is even less obvious that it has a role becuase that although the interface implies parsing, the implementation has made it external. You just get the object from some kind of builder pattern and don't care.

    Other pretty passive items are Adapters and Facades. Again these are gateways to another system of sorts, here another segment of a large application or one that is remote.

    One other type of word is an adverb: saying how something is done. This is great for strategies and decorators. For example you could have a caching policy that refuses to cache items with errors in the content. You could call this NoErrorsPolicy (noun) or WithNoErrors() or Errorless. The code would look like this...
    PHP Code:
    $cache = new Cache(new NoErrorsPolicy());
    $cache = new Cache(new WithNoErrors());
    $cache = new Cache(new Errorless()); 
    Each naming has it's plusses and minuses and my names could be improved, but I think it shows a bit of imaginative naming can make the code feel less cluttered.

    Here are some really tricky ones...

    Another possibly good noun is one which is a step of the solution. For example the Action (Command) in a framework like Mojavi. As the Action is rebuilt it's mutations track progress. Sometimes the existence of this information is itself progress. For example a Voyage in a shipping application. A delivery would accumulate Voyages until the location matched the destination.

    When we built the Changes library (a group of three of us) we built it around the UnitOfWork pattern. Our Change object was to represent a (transactional) step in a domain/business process. Everyone hates the name, but at least it got us thinking about progressing the solution rather than observing passive/structural characteristics such as persistence. Like Mojavi, that library is small (18K).

    By summary of sorts:
    1) I agree.
    2) There are some marshall like nouns I cannot figure out.
    3) There are some step like nouns I cannot figure out.
    4) Adverbs are an area of research for me.

    Uhm...not much help am I?

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

  8. #8
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    netherlands
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...
    You cannot always figure it out this way (at least I can't) so I have run into a bunch of exceptions so far.
    Would you include passive domain objects as one of your exceptions? The most of the noun classes I've seen are built on the idea of presenting something in the domain concept, and therefor, be 'valid'. This is a situation where I have some mixed feelings about.

    Quote Originally Posted by lastcraft
    You could call the DOM a DocumentTranslator or DocumentAccessor, but most would just call it a Document.
    If it's possible to give it a more active name, I wouldn't really think of it as a problem. Maybe it's bad to give these kind of active classes passive names, I don't know.

    Quote Originally Posted by lastcraft
    One other type of word is an adverb: saying how something is done.
    Interesting, I haven't thought about it yet. Though, can't you include the decorated classname in the name of the decorator? For instance: ErrorlessChacher?
    So:

    PHP Code:
    <?php
    $cacher 
    = new ErrorLessCacher(new Cacher());
    ?>
    Hmm, it does seem a little strange, 2 time the name Cacher. But hey, its just an idea

    Quote Originally Posted by lastcraft
    Other pretty passive items are Adapters and Facades. Again these are gateways to another system of sorts, here another segment of a large application or one that is remote.
    This is even trickyer. I'm not sure how to deal with this one either, maybe we'll figure this one out at a later stadium (i hope )

    Another possibly good noun is one which is a step of the solution. For example the Action (Command) in a framework like Mojavi. As the Action is rebuilt it's mutations track progress. Sometimes the existence of this information is itself progress. For example a Voyage in a shipping application. A delivery would accumulate Voyages until the location matched the destination.
    Another exception I cant think of any solution for at the moment. Argh, I hate exceptions

    Quote Originally Posted by lastcraft
    When we built the Changes library (a group of three of us) we built it around the UnitOfWork pattern. Our Change object was to represent a (transactional) step in a domain/business process.
    I'm eager to know if you made that naming/design discision because an active class would be worse? Was it a clear advantage to use this passive class above an active one? Would it be possible to create the same library without the passive Change class?

    Quote Originally Posted by lastcraft
    Uhm...not much help am I?
    Enough for new insights

  9. #9
    ********* 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 Manor
    Would you include passive domain objects as one of your exceptions?
    Maybe on a temporary basis if that was the language of the client. I would reckon on these being the first ones to be redesigned though.

    Quote Originally Posted by Manor
    If it's possible to give it a more active name, I wouldn't really think of it as a problem. Maybe it's bad to give these kind of active classes passive names, I don't know.
    Then DocumentAccessor is about right, because it even hides the idea that there may be an internal representation of the document. Trouble is constantly adding accessor is going to be a bit tedious.

    Quote Originally Posted by Manor
    PHP Code:
    <?php
    $cacher 
    = new ErrorLessCacher(new Cacher());
    ?>
    Hmm, it does seem a little strange, 2 time the name Cacher. But hey, its just an idea
    How about WithErrorRejection or WithoutErrorWriting. Also the cache may change as well, so you could end up with...
    PHP Code:
    $cache = &new WithoutErrorWriting(new DbmCache()); 
    I think Cache is a role just as much as Cache is. After all you have to call read() and write() on it rather than it going off and finding stuff. More interesting is if the cache is itself a decorator...
    PHP Code:
    $report = &new MysqlReportCaching(new ReportAggregator()); 
    Though this may just be a phase I am going through.

    Quote Originally Posted by Manor
    I'm eager to know if you made that naming/design discision because an active class would be worse? Was it a clear advantage to use this passive class above an active one? Would it be possible to create the same library without the passive Change class?
    I cannot think of a good alternate name. Perhaps QueryBatcher? Because it's a kind of wrapper (actually Aggregate pattern) on the database transaction I think it is inclined to drift from ideal domain model OO. It does have a job to do, namely the commit() method.

    Maybe the underlying concept is not roles, but classes that can contribute to progress. That's tricker to define though and probably not helpful.

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

  10. #10
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Eli, tell me truthfully: how many alternative ways have you explored to solve or describe this problem? Because it's easy to say that other solutions are more unnatural or difficult to read, but so far I haven't seen any serious attempts at finding alternatives from the OOP purists. There may now be dozens of ways to build a User object, but too few people are willing to entirely let go of the idea of a User object.
    I tried it without objects until the requirements changed and the complexity made it too dificult to code properly. Once i used logical objects that represeneted the domain entities, it's simplicity has made this chore easy to deal with since i am dealing with objects in the code as if they were fathomable entities that can be manipulated. I'm pretty lazy and try to code somehting quickly to get it done if i can, but often end up converting it to objects when the complexity becomes and issue.

    Quote Originally Posted by Azmo
    I think Austin is trying to point out the difference in application runtime between PHP/Perl and languages for 'real' applications: a Java object may have a lifetime of several hours, even if the user is not interacting with the application, and a single object will use a large part of its behaviour during one session. But PHP applications are intended to have a lifetime of less than 100 milliseconds, because otherwise your site would get too slow. This means that the vast majority of PHP objects have a lifetime of less than 100 milliseconds, which puts a significant limit on the amount of behaviour that is used during each lifetime.

    That's the big difference between Java/C++ and PHP/Perl, and surely it must have an impact on how we perceive the objects within our applications.
    Perl, as well as .net and java all have web application frameworks. So really there is little difference. It's not about speed. It's about managable code that you can deal with where the code reflects what is going on in the business entities and their relationships

    Quote Originally Posted by Azmo
    IMO the application is the system. The implementation of the application is completely hidden from the client/user by the (user) interface, just like the interfaces within the application encapsulate the implementation of each object. I find it quite saddening how the OO community manages to strongly embrace encapsulation at the object level, but to totally abandon it when it comes to the application itself: by encouraging developers to build their applications around concepts that only have meaning in the user's reality, instead of using concepts that make sense within the application.
    I've been talking about the model (ie processing) aspect of the system, so will continue on that line. That part has had nothing to do with the interface. Using a multi-tired app means that all the processing is encapsulated within the model which is hidden from the view. I dont encourage developers to build their apps around concepts that only users can understand. It's about developing around concepts that other developers can understand so the system is more easy to understand and hence maintain. And i find breaking things down into small modules that represent entities in the business model help other developers understand the system far more easily.

    Regards,
    Eli

  11. #11
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I definitely tend to find that the top level problems are more efficiently solved when I start thinking in terms of doing stuff. If you are scraping links from a page, it is easy to think of a structure straight away (programmers are good at that): Parser, Page, Link, Connection, Request, Response. You spend ages on five of those objects so that you can start work on the Parser, only to find that's where all of the work is. Structure by itself doesn't get the problem solved. It should be the servant of the solution.
    This sounds like a use case or task based approach. Methods are like little use cases and do well with imperative verb names:

    add(element)
    write(item)

    However, sometimes a task is too big for a method, then the task can be represented by an class. In this case the 'er' names seem to work well:

    CodeWriter
    Parser

    A good example of this from WACT is the CodeWriter class. This could just have easily have been named CodeFile.

    $CodeWriter->writePHP(..);
    $CodeFile->writePHP(..);

    Six of one, half dozen of the other. I think the CodeWriter name is a little better because it subtly limits speculative thinking to the task at hand.

    The problem with the Change class is that the word change is both a noun and an imperative verb. I think this makes it confusing. Also what does an SQL select change? Additionally, the word change eschews the established name in the domain, "Transaction."

    Your explanation here helps me understand the variable naming used to hold Change instances. I found this a bit confusing/awkward.

    PHP Code:
    $creating_parent = &new Change(Environment::instance());
    $confirm_no_red = &new Change(Environment::instance());
    $reading_join = &new Change(Environment::instance());
    $build_sample =& new Change(Environment::instance());
    $create_one = &new Change(Environment::instance()); 
    Its seems hard to name an instance of a change. I guess if you were lucky, your domain would have some names.
    PHP Code:
    $withdrawl = &new Change(Environment::instance());
    $deposit = &new Change(Environment::instance()); 
    Just some thoughts off the top of my head.

  12. #12
    ********* 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 Selkirk
    I think the CodeWriter name is a little better because it subtly limits speculative thinking to the task at hand.
    Exactly. It is also a more emphatic description of what it does. That in turn allows you to understand the higer process that uses it.

    Quote Originally Posted by Selkirk
    The problem with the Change class is that the word change is both a noun and an imperative verb. I think this makes it confusing. Also what does an SQL select change? Additionally, the word change eschews the established name in the domain, "Transaction."
    I am not going to be allowed to forget this one am I?

    We were taking the ball and running with it just to see how far we could go. Once back in production code (the library is still mostly untested) the name will probably become Transaction. The published version was very much a proof of concept showing that you could ditch Java style PersistenceBroker and the like (our previous version).

    Although if you keep complaining I'll call it DataTwiddler and publish it again...

    Quote Originally Posted by Selkirk
    Its seems hard to name an instance of a change. I guess if you were lucky, your domain would have some names.
    PHP Code:
    $withdrawl = &new Change(Environment::instance());
    $deposit = &new Change(Environment::instance()); 
    That was actually an example we had on the whiteboard when we were initially groping.

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

  13. #13
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    That was actually an example we had on the whiteboard when we were initially groping.
    Hopefully abandoned due to poor spelling...


  14. #14
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    netherlands
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What Im still curious about, is the role of domain driven design in this 'problem subject'. Designing around a domain forces a unified language which leeds to objects that model the real world around the problem, including the passive names.

    Should you translate the domain model into more appropriate names and roles? Iif you would do that, the problem exists that the developers will use those names and terms instead of the unified one, so communicating will become more of a problem. But I think that directly copying a domain model to the actual programming world, can/will cause some of the problems I mentioned in the openingspost, like vaque roles that can lead to wrong responsibility allocations.

    Hmm.. am I too progressive now?

  15. #15
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Do you really need all actions to be in their own objects? Can't you have a mix, and use what is appropriate for that situation?

    How would you update a flight for example? You could use mostly static noun objects:
    PHP Code:
    $flight // get a flight object representing the flight
    $flight->capacity 500// update an attribute
    $flight->save(); 
    or you could use purely service objects:
    PHP Code:
    flight_update_service = new FlightUpdateService($flight_id);
    flight_update_service->updateCapacity(500); 
    Some cases are appropriate for one and some are appropriate for the other. (Or in this case you could use the second whose method implmentation implements the first) Do you really need to only use one and exclude the other?

    Unless I'm misunderstanding exactly what the problem is that you're expressing?

  16. #16
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Definitions:
    BusinessDomain - all the stuff that makes sense at the business (human) level. Like airplanes, meetings, and users.
    ApplicationDomain - all the stuff that makes sense at the application level. Like Databases, Iterators, and Requests.

    Quote Originally Posted by Manor
    Designing around a domain forces a unified language ...
    I've read this statement before, and I have three comments:
    • IMO this statement is far too strong: the domain may facilitate or encourage the emergence of a unified language, but it doesn't force it. And a unified language might still be possible without the use of a domain.
    • A unified language might just be a muddy boot instead of a silver bullet. Using the terminology from the wrong domain is not likely to help much: if I mention my 'User' object, nobody will be any the wiser about its structure or behaviour. But if I mention some object being an Iterator or Observer, people will get some idea about both structure and behaviour.
    • This statement is often read as 'designing around the domain...', where the domain is the real world, i.e. the BusinessDomain. I believe that there are many domains (or conceptual layers), and that it's important to use each domain at the right time. Limiting our view of software to only one domain seems rather restrictive to me.


    Quote Originally Posted by Manor
    ... which leads to objects that model the real world around the problem.
    Yeah right. They may be named after real world objects, but they generally have none of the millions of characteristics that are so important to 'real' objects. Instead, they have a limited number of methods that generally only make sense in the ApplicationDomain.

    Maybe that's the problem: most people seem to believe that the BusinessDomain is the most important, and the ApplicationDomain is just implementation. But maybe the ApplicationDomain should be the core model of an application's structure. Like bottom-up conceptualization instead of top-down...


    Off Topic:

    I'm glad you started this topic, because these are the type of discussions that are IMO truly 'advanced'. Which is probably why I spent an entire evening writing so little text... I did learn some new things though

  17. #17
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    netherlands
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lazy_yogi
    Some cases are appropriate for one and some are appropriate for the other. (Or in this case you could use the second whose method implmentation implements the first) Do you really need to only use one and exclude the other?
    I understand that your first solution also has a clean solution to the problem. But Im wondering if the second one is cleaner (since thats the one which clearifies the role, and does not take the domain language as example); I think it causes less problems than the first. If I would examine the first and second situation, I would say this:

    The first does not have a clear role, or if it has, the classname does not reveal it. It would seem like a representation of an airplane. This, ofcourse, does seem obvious and nice at first, but may gets more difficult when assigning the necesary responsibilitys (imo). What if we need to allocate a responsibility to an object which calculates the free seats left. It does not seem wrong to write $flight->getFreeSeats(). Why? The name/role is too vague, and does not isolates any wrong responsibilitys to go there, just because there is no real role and therefor, there are no wrong responsibilitys that shouldn't go there. This way, it gets unnecesary difficult to determine which responsibility should go where, and you can almost never defend your discision why you had put it there, and not anywhere else.

    Taking the second solution you mentioned, you can see clearly without any doubt where the class is build for, and what it should do. Therefor, calculating free seats can not be allocated to that class, just because the role does not let you too. It is simply wrong to put it there. This makes design discisions less hard to do, and, maybe even more important, it makes the application more clear and easier to understand.

    Probably I missed a crucial point somewhere, because the second solution sounds by my reasoning better than the first, and still people use the first. Therefor I would like to see what others think about this case, and maybe can even point me to that crucial point Im missing.

  18. #18
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    netherlands
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    IMO this statement is far too strong: the domain may facilitate or encourage the emergence of a unified language, but it doesn't force it. And a unified language might still be possible without the use of a domain.
    I agree with you, but why do I see the real world language as classes over and over again then?

    Quote Originally Posted by Azmo
    If I mention my 'User' object, nobody will be any the wiser about its structure or behaviour.
    It does for the domain experts. Thats the argument for naming classes this way.

    Dont get me wrong, Im not trying to defend a unified language which is presented in classnaming, but Im trying to understand the idea behind it, just because I would like to know why they do it this way, while they can do it the other way around. Renaming 'user' to the role its playing will clear a lot things up.

    Quote Originally Posted by Azmo
    Yeah right. They may be named after real world objects, but they generally have none of the millions of characteristics that are so important to 'real' objects. Instead, they have a limited number of methods that generally only make sense in the ApplicationDomain.
    See my post above (#17), I think that naming will cause a lot of trouble. Or maybe the name is from the domain, but the role is clear and well defined: in that case, looking at the names will cause a lot of confusion while trying to understand the application, which is the last thing you would want as a developer. The naming just gives the wrong impression of what the class is doing then.

    Quote Originally Posted by Azmo
    I'm glad you started this topic, because these are the type of discussions that are IMO truly 'advanced'. Which is probably why I spent an entire evening writing so little text... I did learn some new things though
    Glad to hear that

  19. #19
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Manor
    What if we need to allocate a responsibility to an object which calculates the free seats left. It does not seem wrong to write $flight->getFreeSeats(). Why? The name/role is too vague, and does not isolates any wrong responsibilitys to go there, just because there is no real role and therefor, there are no wrong responsibilitys that shouldn't go there. This way, it gets unnecesary difficult to determine which responsibility should go where, and you can almost never defend your discision why you had put it there, and not anywhere else.

    Taking the second solution you mentioned, you can see clearly without any doubt where the class is build for, and what it should do. Therefor, calculating free seats can not be allocated to that class, just because the role does not let you too. It is simply wrong to put it there. This makes design discisions less hard to do, and, maybe even more important, it makes the application more clear and easier to understand.
    Yes, in this instance it would make it clearer. And I agree that there are times when functionality is service based. But often these are just a facade to offer a simple interface for the UI to call, which would implement it using the flight object (and probably with other relted objects). Sometimes you would create the service facade, and other times you would just implement it with no service if the business object can logically do it itself in a couple of lines of code.

    Actually, now that i read over what i just wrote (and recalling austins post #2 which i replied to in post #3), web based systems are generally all service based - as he pointed out. So maybe you could create a whole service layer of facade objects to carry out these services and only call those from the UI code. But in any case, either the service facade calls the business objects to carry out the processing, or the UI code does it directly - so you will have the business entities doing the same work in the same way. And some of these business entities may be simple containers and others will have more functionality with them.

    I'm thinking that the guts of the issue is really whether to put service performing code into the business objects, service objects, or the UI (ie controller). And yes, it often doesn't seem quite right to put it in the business object - which is why I either put it in the controller if it is simple, or if it is more than a few lines, I create a service object to do it.

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

    What follows is mainly about domain driven design, rather than the roles naming. This is partly, but not quite, orthogonal.

    Quote Originally Posted by Azmo
    Definitions:
    BusinessDomain - all the stuff that makes sense at the business (human) level. Like airplanes, meetings, and users.
    ApplicationDomain - all the stuff that makes sense at the application level. Like Databases, Iterators, and Requests.
    I think this is going to cause more confusion than resolution. The literature (Ok, Evans and Fowler) seems to be moving toward...

    1) Presentation layer (MVC and the like).
    2) Application layer, which is the glue and top level scripts binding the code together.
    3) Domain, which is concepts shared across the apps. within the business.
    4) Infrastructure, such as persistence, parsers and the like. Techy stuff in other words.

    I think your "application" includes both 2 and 4 (and possibly 1).

    The application layer can be made to look pretty much like the original requirements with a bit of work. The domain objects execute the code corresponding to this language. It's really nice when this happens because you know you are hitting the requirements, or if not then any mismatch is in the detail of the domain object concerned and thus encapsulated. I have seen this work a couple of times and I try to post code in this forum that follows that model. It's just clearer (in some immeasurable way).

    In an imaginary application script...
    PHP Code:
    $preferences = new SeatPreferences();
    if (
    $form->isSelected('window')) {
        
    $preferences->preferWindowSeat();
    }
    if (
    $form->isChecked('wheelchair')) {
        
    $preferences->requireWheelchairAccess();
    }
    $allocator = new SeatAllocator();
    $seat $allocator->findBestSeat($flight$preferences);
    if (
    $seat->isReservable()) {
        
    $seat->reserve();
        require(
    'payment.php');
        exit();
    }
    require(
    'seat_selection_form.php'); 
    And in the domain object...
    PHP Code:
    class SeatAllocator() {
        ...
        function 
    findBestSeat($flight$preferences) {
            
    $available $flight->getAvailableSeats();
            
    $candidate = new NoSeat();
            foreach (
    $available as $seat) {
                if (
    $seat->score($preferences) > $candidate->score($preferences)) {
                    
    $candidate $seat;
                }
            }
            return 
    $candidate;
        }

    What's interesting about this is that "seat" is the wrong word. We don't post the buyer the actual aeroplane seat to thier home address. The "seat" here is the point of contact with the passengers bum that carries them over the atlantic ocean. The aeroplane is an implementation detail here and pollutes the name with regard to our narrow purpose. They don't buy a seat, but future access to a transporter. I.e. a journey, or rather the token that records that option. This is an example of where there is an English noun which is a common shorthand. If it doesn't cause confusion then I think that this is OK.

    Another noun that has slipped in there is the "preferences". This is a strategy or a policy. Alternatively I could have called it Selector and inverted the scoring system to $selector->score($seat). Thinking about it now, I actually prefer this.

    Quote Originally Posted by Azmo
    the domain may facilitate or encourage the emergence of a unified language, but it doesn't force it. And a unified language might still be possible without the use of a domain.
    A language mismatch is a broken requirement. Unfortunately there is always some degree of mismatch, and so we are always not quite following the requirements. Thus the lanaguage evolves. Actually so do the requirements, because the unified language is an asset to the business as well. It's co-evolved by developers and business in the absence of a specialist business analyst.

    Quote Originally Posted by Azmo
    A unified language might just be a muddy boot instead of a silver bullet. Using the terminology from the wrong domain is not likely to help much: if I mention my 'User' object, nobody will be any the wiser about its structure or behaviour. But if I mention some object being an Iterator or Observer, people will get some idea about both structure and behaviour.
    The unified language should be happening anyway whether we are concious of it or not, be it the requirements document or the whiteboard. If it isn't then the developers are making decisions on behalf of the client with all the ramifications that this brings. One of the advantages of highlighting the process, as we are here, is that we can choose the degree of formalism in the process and hopefully become better at diagnosing when we need to invest more time in it.

    Quote Originally Posted by Azmo
    This statement is often read as 'designing around the domain...', where the domain is the real world, i.e. the BusinessDomain. I believe that there are many domains (or conceptual layers), and that it's important to use each domain at the right time. Limiting our view of software to only one domain seems rather restrictive to me.
    Yes, in this context I mean "business domain", i.e. objects that fulfill business events, rather than the many little problem domains alongside, such as parsing.

    However describing objects as "doers" cuts across this. For example iterator gives access to a collection. We don't actually need to even code the collection as the iterator is often sufficient. E.g. a MySql table in memory isn't very useful, but a RecordSet you can call next() on is. If you have the doers, you often don't need the structures at all (except for random access).

    Quote Originally Posted by Azmo
    Instead, they have a limited number of methods that generally only make sense in the ApplicationDomain.
    Absolutely, and I think this pushes us even more to narrow doers. For the airplane example you could use SeatAllocator rather than Airplane exactly because Airplane carries...er...excess baggage. I would doubt we need an Airplane class at all in a flight booking application (I haven't coded such an application).

    Quote Originally Posted by Azmo
    Maybe that's the problem: most people seem to believe that the BusinessDomain is the most important, and the ApplicationDomain is just implementation.
    I just need to do a translation into the terms above. The infrastructure and presentation code usually dwarfs the domain and application code. By this I mean database stuff, RPC, configuration, sessions, MVC, etc, etc. However there are some things askew with this and I think this is at the core of what we are groping towards. Here are the problems...

    1) Firstly my statement is not even correct, because hopefully we use libraries for the infrastructure and so we as application programmers should be writing less of it's. In practice we still churn out rakes of the stuff though, so this dream never seems to materialise.
    2) As I improve I write far less infrastructure code. I see newer developers leap straight to a structural decomposition, almost like data modelling, but with in memory objecs. As a piece of circumstantial evidence this makes me suspicious of the stuff. Next week I may have switched back to doing the same thing.
    3) We don't get paid for techy work, we get paid for business automation. Techy stuff and structure is waste (although it may be fun).

    Quote Originally Posted by Azmo
    But maybe the ApplicationDomain should be the core model of an application's structure. Like bottom-up conceptualization instead of top-down...
    A domain modelling approach is usually heavily requirements driven. If the requirements are simple to express, such as a bulletin board, then a coordinated attempt to build a model may be overkill. This stuff really pays for itself in communication of evolving business cases to developers and the programs they look after. Developers know what a bulletin board is an dthe concept won't change much. A database driven approach is likely more efficient in this case.

    Also domain modelling is only a small percentage of the programmer's day to day work, because of all that damn infrastructure/presentation stuff.

    Now at last I finally get back to the point. By building our model in terms of doers we hopefully end up with a much more minimal and tightly focused model. One built around actions rather than data. This at least lays the groundwork for YAGNI with the lower layers (another argument for top down I think). The earlier we can prune, the more effective it will be. That first translation of requirements to code is the earliest pruning opportunity.

    OO is a pretty good fit for business problems. As you exit the domain layer a few things happen though...

    1) You hit non-OO impedences such as storage and page granular requests.
    2) Getting the classes a bit wrong is less damaging because you are dealing with pretty isolated bits of technical code.
    3) If you get something wrong in techy space, you can refactor it immediately without going back to the client.

    This is why I think domain modelling problem and the "doer" language problem are not quite orthogonal. It's in the domian language where there is the biggest pay off.

    Quote Originally Posted by Azmo
    I'm glad you started this topic, because these are the type of discussions that are IMO truly 'advanced'. Which is probably why I spent an entire evening writing so little text... I did learn some new things though
    Here, here.

    yours, Marcus

    p.s. I had to edit this long post several times to get it right. This is a really tricky subject.
    Last edited by lastcraft; Dec 18, 2004 at 22:39.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  21. #21
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Talking about service layering earlier I have this PDF on CD which I've attached. Just not sure how helpful it's going to be, that's all

  22. #22
    ********* 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 lazy_yogi
    Actually, now that i read over what i just wrote (and recalling austins post #2 which i replied to in post #3), web based systems are generally all service based - as he pointed out.
    This could be a risky categorisation. Different people have different architectural styles, and you can often morph a style so that it looks like every project follows that style. As a counter example to service facades, consider a project built around Mojavi. Likely the application (not the domain code ) will be written into the Action classes. That's much more of an event driven style. You could say the web is event driven too.

    Mojavi seems great for lot's of forms (e.g. wizards and the like) although I've yet to test it in battle. My current main work project has the core functionality available as both a web site and a web services API. Because the UI is swapped out we have used service layer approach. I can easily imagine complex business process pages (e.g. Workflow apps.) needing a domain model to work with.

    I bet there are more approaches still and we should start another thread aimed at listing them all.

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

  23. #23
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    This statement is often read as 'designing around the domain...', where the domain is the real world, i.e. the BusinessDomain. I believe that there are many domains (or conceptual layers), and that it's important to use each domain at the right time. Limiting our view of software to only one domain seems rather restrictive to me.
    ...
    Maybe that's the problem: most people seem to believe that the BusinessDomain is the most important, and the ApplicationDomain is just implementation. But maybe the ApplicationDomain should be the core model of an application's structure. Like bottom-up conceptualization instead of top-down...
    For anyone who hasn't already read it, there's a study of design "altitude" in:

    Guindon, Raymonde. "Designing the Design Process: Exploiting Opportunistic Thoughts". Human and Computer Interaction 5, 1990, pp 305-344.

    Her work is included in Mary & Tom Poppendieck's book, "Lean Software Development An Agile Toolkit" (Part of the Addison Wesley 'Agile Software Development Series').

    Quote Originally Posted by Poppendieck
    She [Guindon] found that when experienced designers are presented with ill-defined problems, their design activities are not at all top-down. They move repeatedly between scenario examination, requirements elucidation, high-level solution segmentation, and low-level design of difficult elements. (See figure 2.1.)

    ... [ Figure omitted, sorry ] ...

    Guindon found that cycling between high-level design and detailed solution was typical of good designers when dealing with ill-structured problems, that is, problems that do not have a single right answer or a best way to arrive at a solution. She theorized that this unstructured approach is necessary to understand and ultimately give structure to such problems.
    I think it's worth paying close attention to the adjective in the last paragraph: "ill-structured" problems.

    I think it's important because it reflects on what we've been discussing here. If the existing code imposes or provides a structure, then it reduces our overall flexibility -- some of the design is already done for us -- while presumably also reducing the design time.

    In Marcus' last post he mentions the event driven Mojavi approach, and mentions that his current work project has a complete model because it is available both in a web application and a web service format.

    Obviously, his application is several iterations beyond the "first cut" implementation . Every iteration that is completed adds a another brick to the wall. ("For love of God, Marcus-sor!")

    I suspect that "action/command" classes are the trilobytes of the evolutionary cycle for PHP applications. Early on, you're doing data-gateway work implementing specific commands or actions. As your site / application succeeds, you'll invest more and more in your object model. As you invest in your object model, your "nouns" accumulate more and more code -- this is the "model formalization" process.

    Just as with other forms of human endeavor, we start out writing in simple declarative statements. As time goes on, we evolve into bureaucratic doublespeak and begin using the passive voice.

    Eventually, you reach a sort of "object 4gl" where everything is achievable through existing method calls, and none of the underlying infrastructure is visible.

    At that point, light cannot escape. Nobody who doesn't live in that world can understand how to make changes to it. There's probably a big bang and a rewrite. (This last is just optimistic speculation...)

    =Austin

  24. #24
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    I think it depends on how said class is to be used. A simple single-record level class use only for assembling and validating field values, then inserting or updating the record is a good candidate for a noun-name, such as 'Employee', while a collection class, which maintains a set of 'Employee' objects, could be called 'Employees'. On the other hand, more generic, multi-use classes, or those designed as abstracts or task based classes, could, and should in my opinion, a more descriptive name, such as an 'EmployeeTimeTracker' class, which exposes functions that perform tasks upon 'Employee' and 'Empoyees' class instances. If you are going to dedicate an entire class to one task (guilty myself at times) to a single task, that task is better off as a standalone function.

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

    I thought I would break down the class names in SimpleTest (RC1) to see how they fell. I've marked public classes with a *.

    Doers (24 classes = 32%):
    HtmlReporter*, RemoteTestCase*, RunnableTest, ShellTestCase*, SimpleDumper, SimpleReporter*, SimpleRunner*, SimpleTestCase, SimpleTestXmlParser, TextReporter*, UnitTestCase*, XmlReporter*, Mock*, Stub*, SimpleAuthenticator, SimpleBrowser*, SimpleLexer, SimplePageBuilder, SimpleSaxListener, SimpleSaxParser, SimpleUserAgent, WebTestCase*, TestCase*, PhpUnit_TestCase*.

    Mock and Stub are static code generators that could just as easily be Mocker and Stubber. Mock::generate() read better. Most of these classes are significant components.

    Containers (16 classes = 21%):
    GroupTest*, SimpleErrorQueue, ParallelRegex, SimpleBrowserHistory, SimpleCheckboxGroup, SimpleCookieJar, SimpleForm, SimpleFrameset, SimpleHttpHeaders, SimpleHttpResponse, SimplePage, SimpleRadioGroup, SimpleRealm, SimpleStateStack, CallMap, SimpleTestOptions.

    Four of these are composite pattern artifacts. It's surprising how many important classes are in this category.

    Commands (12 classes = 16%):
    SimpleExpectation*, EqualExpectation*, IdenticalExpectation*, IsAExpectation*, MethodExistsExpectation*, NotAExpectation*, NotEqualExpectation*, NotIdenticalExpectation*, UnwantedPatternExpectation*, WantedPatternExpectation*, ParametersExpectation, WildcardExpectation*.

    I'd forgotten about commands. These aren't very well named as really they should be verbs. It's just that they sound better when coupled with the new keyword (the're public classes).

    Value objects (21 classes = 28%):
    SimpleQueryString, SimpleFrameTag, NestingCaseTag, NestingGroupTag, NestingMethodTag, NestingXmlTag, MultipleSelectionTag, SimpleAnchorTag, SimpleCheckboxTag, SimpleCookie, SimpleFormTag, SimpleOptionTag, SimpleRadioButtonTag, SimpleSelectionTag, SimpleSubmitTag, SimpleTag, SimpleTextAreaTag, SimpleTextTag, SimpleTitleTag, SimpleUrl, SimpleWidget.

    All of these are low level parsing and marshalling objects.

    Flex points/patterns (7 classes = 9%):
    SimpleRoute, SimpleProxyRoute, SimpleSecureSocket, SimpleSocket, SimpleHttpPostRequest, SimpleHttpRequest, SimpleRunnerDecorator*.

    These would be adverbs in my current naming preference or have "with" or "as" attached. Most are strategies.

    Other (5 classes = 7%):
    SimpleMock*, SimpleStub*, SimpleShell, StickyError, SimpleTestCompatibility.

    I couldn't classify these at all.

    It was surprisingly easy to come up with categories for all of these classes, although SimpleTest is a pretty small application. It's also obvious that patterns don't really figure at all in my naming, and yet I would probably find a hefty percentage of GoF patterns in the code. the code has had a year of churn and a lot of that has been refactoring work.

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


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
  •