strategies for managing long class files in php

前端 未结 6 803
野的像风
野的像风 2021-02-09 08:37

I\'ve got a bunch of functions that I want to move into a class. They\'re currently split into a couple of fairly long files. I\'d prefer not to have one 2500 line file, but as

相关标签:
6条回答
  • 2021-02-09 08:51

    Usually I do something like this:

    class one
    {
        public function __get($key)
        {
            // require __DIR__ / $key . php
            // instanciate the sub class
        }
    
        public function mainMethod()
        {
        }
    }
    
    class one_subOne extends one
    {
        public function otherMethod()
        {
        }
    }
    
    class one_subTwo extends one
    {
        public function anotherMethod()
        {
        }
    }
    
    $one->mainMethod();
    $one->subOne->otherMethod();
    $one->subTwo->anotherMethod();
    
    0 讨论(0)
  • 2021-02-09 09:00

    If you want to do OOP, separate the concerns and encapsulate them into appropriate classes. Combine them either by extending them or by composition or better aggregation. Remove any duplicate code. Dont repeat yourself.

    In your case, separate the stuff that is about any Form from the stuff that is about your specific form. The code that can be used for any Form is the code you want to place into a generic Form class. You can reuse this in later projects. For an example of a very complex Form class, check out Zend_Form.

    Anything in your code related to the/a specific form gets into a class of it's own that extends the generic form. Assuming from the type property given in your code, you might end up with multiple special purpose form classes (instead of one-type-fits-all-form), which will likely eliminate the complexity from the getSection methods and make your code a lot easier to maintain because you can concentrate on what a specific type of form is supposed to look like and do.

    Lastly, if you got code in there that fetches data for the form from within the form or is otherwise not directly related to form building, remove it and make it into a separate class. Remember, you want to separate concerns and your form classes' concern is to build a form, not get it's data or something. Data is something you will want to pass to the form through the constructor or a dedicated setter.

    0 讨论(0)
  • 2021-02-09 09:00

    They are all in different files, which means that they were different enough to group by file. Just take the same logic when building them into classes. I have a Page object that deals with building the page. Technically the HTML for my page header is part of the page, but I separate it into a Page_HTML class for maintaining my sanity and not creating gigantic classes.

    Also, I tend to make the sub_classes, like Page_HTML in this case, static, instead of instantiating it. That way I can access the $this variables in the Page class, but still group it into another class.

    class Page
    {
        function buildPage($content)
        {
            $content = Page_HTML::getHeader() . $content;
        }
    }
    
    class Page_HTML
    {
        function getHeader()
        {
        }
    }
    
    0 讨论(0)
  • 2021-02-09 09:07

    As far as building the view is concerned, you might like to try the CompositeView pattern.

    Here's a small example of how it could look in PHP. Pretend, for the sake of this example, that View::$html is encapsulated in a Template class that can load html from disk and allows you to inject variables, handles output escaping, etc.

    interface IView {
        public function display();
    }
    
    class View implements IView {
        public $html = ''; 
    
        public function display() {
            echo $this->html;
        }   
    }
    
    class CompositeView implements IView {
        private $views;
        public function addPartial(IView $view) {
            $this->views[] = $view;
        }   
        public function display() {
            foreach ($this->views as $view) {
                $view->display();
            }   
        }   
    }
    

    The reason for the IView interface is to allow you to build composite views with other composite views.

    So now consider a form with three parts: header, body and footer.

    class HeaderView extends View {
        public function __construct() {
            $this->html .= "<h1>Hi</h1>\n";
        }   
    }
    
    class BodyView extends View {
        public function __construct() {
            $this->html .= "<p>Hi there.</p>\n";
        }   
    }
    
    class FooterView extends View {
        public function __construct() {
            $this->html .= "<h3>&copy; 2012</h3>\n";
        }   
    }
    

    (Again, you wouldn't just write HTML into that public variable and handle output escaping yourself. You'd likely reference a template filename and register your data via the template's interface.)

    Then, to put it all together you would go:

    $view = new CompositeView();
    // here you would make decisions about which pieces to include, based
    // on your business logic.  see note below.
    $view->addPartial(new HeaderView());
    $view->addPartial(new BodyView());
    $view->addPartial(new FooterView());
    $view->display();
    

    So now your views can be composed and the fragments reused, but you can easily make a mess with the code that builds them, especially if you have a lot of conditions and many different possible outcomes (which it sounds like you do.) In that case, the Strategy pattern will probably be of some help.

    If you haven't already read UncleBob's SOLID article, do it before anything else! At least the Single Responsibility Principle. I would also recommend reading Refactoring to Patterns by Joshua Kerievsky at some point.

    0 讨论(0)
  • 2021-02-09 09:11

    This class/set of functions outputs the html for a complex form.

    Why not remove PHP from the equation? It seems you're using PHP to organize views which can be done easily with the filesystem. Just write the views in HTML with as little PHP as possible. Then use PHP to map requests to views. I'm assuming you're processing forms with PHP, and you could continue to do so. However, your classes will become much smaller because they're only accepting, verifying and presumably saving input.

    0 讨论(0)
  • 2021-02-09 09:13

    I'd split them up into as many classes as you want (or as many that make sense) and then define an autoloader to obviate inclusion headaches.

    EDIT

    Ok, after seeing more of your code - I think you're approaching subclasses wrong. You have lots of if statements against $type, which signals to me that that is what the polymorphism should be based on.

    abstract class MyForm
    {
      protected
          $mode
        , $read_only
        , $values
      ;
    
      public function __construct( $mode, $read_only=false, array $values = array() )
      {
        $this->mode      = $mode;
        $this->read_only = (boolean)$read_only;
        $this->values    = $values;
      }
    
      abstract function get_section_A();
    
      abstract function get_section_B();
    
      abstract function get_section_C();
    
      //  final only if you don't want subclasses to override
      final public function get_sections()
      {
        return $this->get_section_A()
             . $this->get_section_B()
             . $this->get_section_C()
        ;
      }
    }
    
    class FooForm extends MyForm
    {
      public function get_section_A()
      {
        // whatever
      }
    
      public function get_section_B()
      {
        // whatever
      }
    
      public function get_section_C()
      {
        // whatever
      }
    }
    
    0 讨论(0)
提交回复
热议问题