Rapid Prototyping: Prototype To Code, del 2

Det tidigare inlägget visar mycket arbete med att ta något som en gång var en snabb prototyp och ta den prototypen till kod. Om du inte har följt med har vi gjort följande:

1. pratade om och byggde en prototyp för ett plugin,
2. i diagrammet kan ett objektorienterat tillvägagångssätt fungera,
3. och refaktorerade vår prototyp till faktisk kod.

Vid det här laget finns det några fler saker vi kan göra för att förbättra vår kod. Vi kan nämligen introducera begreppet namnrymder. Detta tar organisationen ett steg längre och kan ge utdelning för större projekt.

Så här är en titt på hur detta ser ut i vårt nuvarande projekt.

Prototyp att koda: Namnutrymmen

Jag har täckt namnutrymmen på djupet i tidigare inlägg. Om du inte har läst den rekommenderar jag den. Kom sedan tillbaka och kolla in resten av inlägget.

Om du väljer att hoppa över artikeln, här är en kort definition av ett namnområde :

Namnområden är designade för att lösa två problem som författare till bibliotek och applikationer stöter på när de skapar återanvändbara kodelement som klasser eller funktioner…

Och den allmänna tanken är att vi organiserar våra klasser utifrån en logisk relation de har med varandra.

Dessutom organiserar vi även filerna i kataloger som matchar namnområdet. Detta är inget som måste göras, men jag tycker att det hjälper att ha klasserna logiskt organiserade på disken på det sätt som de är virtuellt organiserade i namnutrymmet.

Med det sagt, låt oss organisera filerna.

Organisera filerna

Istället för att börja med huvudpluginfilen, låt oss börja med att organisera våra filer först.

• Filerna Meta Box och Meta Box Display kommer att finnas i en katalog som heter Display. Detta är helt godtyckligt, men eftersom det är vad dessa filer gör, verkar det vara logiskt att det är där de skulle ligga.
• Vi kan också placera filerna message-description.php och no-post-list.php i den katalogen, men låt oss placera dem i en underkatalog som heter Views. Du kanske vill kalla detta för mallar eller partier eller något liknande.
• Därefter har vi klasserna som ansvarar för att fråga databasen och klassen som ansvarar för att koordinera meddelanden. Låt oss placera var och en av dessa i Utility. Det finns andra ställen de kan gå till, men kom ihåg att syftet är att visa hur man använder namnutrymmen. Så om du känner dig så sugen, justera gärna dina filer så att de passar dig.

Om du har följt det vi har ovan bör du ha en katalogstruktur som ser ut ungefär så här:

Ett sätt att organisera dina filer.

Nu är det dags att definiera namnutrymmen för var och en av klasserna. Eftersom vi har organiserat dem alla i deras kataloger blir det lätt att ange ett namnområde; Det är dock viktigt att inse att vi måste använda nyckelordet use när vi använder klasser som finns i andra namnutrymmen.

Låt oss gå igenom alla våra filer och börja med filerna i Utility. Först börjar vi med Post Messenger :

<?php
/**
 * Display content for the meta box when requested.
 *
 * @author Tom McFarlin
 * @since  0.2.0
 */

namespace McFarlinTRPUtility;
use McFarlinTRPUtilityPost_Query;

/**
 * Retrieves information from the class responsible for querying the database and
 * renders it in the context of our meta box when called via the Meta Box Display.
 *
 * @author Tom McFarlin
 * @since  0.2.0
 */
class Post_Messenger {
  // Snip for brevity. 
}

Du kommer att märka att namnutrymmet för filen visas i rubriken tillsammans med en deklaration om att använda klassen Post Query som vi skapade. Jag har lagt till namnet på klassen i slutet av namnutrymmet, så jag behöver inte använda det i hela kodbasen.

Lägg märke till att konstruktören nu ser ut så här :

<?php

/**
 * Instantiates the class by setting a reference to the query.
 *
 * @param string $plugin_dir The path to the root of the plugin directory.
 */
public function __construct( $plugin_dir) {

    $this->query      = new Post_Query();
    $this->plugin_dir = trailingslashit( $plugin_dir );
}

Jag har lagt till ett $plugin_dir- argument eftersom vi måste använda detta för att visa resultaten av frågan korrekt. Och eftersom de nu finns i ett annat område av applikationen ser funktionerna ut så här :

<?php

/**
 * Displays the description of the content of the meta box.
 *
 * @access private
 */
private function get_post_message() {
    include_once $this->plugin_dir. 'Display/Views/post-list.php';
}

/**
 * Displays the description of the content of the meta box.
 *
 * @access private
 */
private function get_description() {
    include_once $this->plugin_dir. 'Display/Views/message-description.php';
}

/**
 * Displays a message of there are no recent posts.
 *
 * @access private
 */
private function get_no_posts_message() {
    include_once $this->plugin_dir. 'Display/Views/no-post-list.php';
}

Låt oss sedan titta på klassen Post Query. Ingenting mycket har förändrats i den här klassen förutom att vi har gett den ett namnutrymme, och vi har också uppdaterat frågan för att bara dra tillbaka tre inlägg (enligt den här kommentaren ).

<?php

namespace McFarlinTRPUtility;

/**
 * Queries the database for three most recent posts. Returns the query to the
 * caller so that it can be interrogates for posts or not.
 *
 * @author Tom McFarlin
 * @since  0.2.0
 */
class Post_Query {

  // Snip for brevity.

    private function get_posts() {

        $args = array(
            'post_type'        => 'post',
            'post_status'      => 'publish',
            'posts_per_page' => 3,
            'orderby'          => 'date',
            'order'            => 'desc',
        );
        $this->query = new WP_Query( $args );

        return $this->query;
    }
}

Lägg märke till i koden, jag har också förfixat WP_Query med ett snedstreck eftersom det är en del av det globala namnområdet.

Låt oss gå in i Display – katalogen och ta en titt på Meta Box-klassen. Detta har också fått ett namnutrymme och använder också det fullt kvalificerade namnet på Meta Box Display -klassen som vi kommer att titta på ett ögonblick.

<?php

 namespace McFarlinTRPDisplay;
 use McFarlinTRPDisplayMeta_Box_Display;

/**
 * Registers the Meta Box with WordPress. Defines the ID, title, display function,
 * and the post type on which it will live.
 *
 * @author Tom McFarlin
 * @since  0.2.0
 */
class Meta_Box {

    /**
     * A reference to the class that will display the contents in the meta box.
     *
     * @access private
     * @var    Meta_Box_Display
     */
    private $meta_box_display;

    /**
     * Instantiates the class by setting its property equal to a reference to its display.
     *
     * @param string $plugin_dir A reference to the root of the plugin's directory.
     */
    public function __construct( $plugin_dir) {
        $this->meta_box_display = new Meta_Box_Display( $plugin_dir );
    }

    // Snip for brevity.
}

Lägg märke till att den här konstruktören också accepterar plugin-katalogen som ett argument och skickar den till Meta Box Display -klassen också. Detta är för att de funktioner som ansvarar för att visa meddelanden kan hittas på rätt plats i katalogen Views .

Låt oss slutligen se över Meta Box Display -klassen. Det här är en enkel klass som inkluderar namnutrymmet och refererar till Post Messenger som vi har granskat ovan.

<?php
/**
 * Defines the display for the meta box.
 *
 * @author Tom McFarlin
 * @since  0.2.0
 */

namespace McFarlinTRPDisplay;
use McFarlinTRPUtilityPost_Messenger;

/**
 * Defines the display for the meta box that will render the content in the
 * context of its meta box.
 *
 * @author Tom McFarlin
 * @since  0.2.0
 */
class Meta_Box_Display {

    /**
     * A reference to the class that will display the contents in the meta box.
     *
     * @access private
     * @var    Post_Messenger
     */
    private $messenger;

    /**
     * Instantiates the object by setting a property equal to that of the class
     * responsible for rendering the messages from the post query.
     *
     * @param string $plugin_dir A reference to the root of the plugin's directory.
     */
    public function __construct( $plugin_dir) {
        $this->messenger = new Post_Messenger( $plugin_dir );
    }

    /**
     * If there are posts to display, renders them in the metabox. Otherwise, displays
     * a note that there are no posts to display.
     */
    public function display() {
        $this->messenger->get_message();
    }
}

Vid det här laget har vi kommit en runda genom plugin-programmet. Med ett undantag: Bootstrap-filen. Vi har lagt till ett namnområde till det och måste uppdatera sättet som det instansierades på :

<?php

namespace McFarlinTRP;
use McFarlinTRPDisplayMeta_Box;

include 'Display/class-meta-box.php';
include 'Display/class-meta-box-display.php';
include 'Utility/class-post-messenger.php';
include 'Utility/class-post-query.php';

add_action( 'add_meta_boxes', __NAMESPACE__. 'trp_start' );
/**
 * Starts the plugin.
 */
function trp_start() {

    $meta_box = new Meta_Box( dirname( __FILE__) );
    $meta_box->init();
}

Vi har nämligen:

• definierade namnutrymmet,
• referera till platsen för Meta Box -klassen,
• uppdaterade sökvägarna för att inkludera var man kan hitta filerna (vilket i slutändan kan göras med en autoloader),
• och uppdaterade add_action -anropet.

Det här är grejen med add action-anropet: Eftersom WordPress behöver hitta den här funktionen och funktionen finns i ett namnområde, måste det fullständiga namnet på funktionen identifieras så att WordPress kan anropa den. Därav behovet av NAMESPACE i funktionens namn.

Nu är vi organiserade (med ett undantag)

Som du märker lägger namnutrymmen och kataloger som matchar dem mycket organisation till ett projekt. Det är lättare att följa, lättare att förstå var saker och ting tar vägen (för både befintliga och nya filer). Och det ger mindre känsla att bara samla många filer på en enda plats.

Även om en klass är lite av en monolit, kan den fortfarande organiseras på ett sådant sätt som gör underhållet enkelt.

Med det sagt finns det fortfarande något jag skulle ändra på det här pluginet: Att gå runt i katalogen för plugin-programmet så här är inte något som hjälper till med låg sammanhållning och det kopplar ihop klasserna tätare eftersom bootstrap-filen måste skicka ett värde till en klass som skickar den till en annan klass som använder den för att ladda filer och så vidare.

Så finns det sätt att fixa detta? Absolut. Och det kanske vi tar en titt på i det sista inlägget.

Tills dess, kom ihåg att den senaste versionen av insticksprogrammet är tillgängligt på huvudgrenen, taggad som 0.3.0, på GitHub.

Serie inlägg

1. Snabb prototyping med WordPress: från koncept till plugin
2. Snabb prototyping med WordPress: konceptanalys
3. Rapid Prototyping: Prototype To Code, del 1
4. Rapid Prototyping: Prototype To Code, del 2
5. Rapid Prototyping: Introduktion av Autoloading