開発スタッフがアプリ関連の最新技術やニュースをご紹介します。

In software engineering, a design pattern is a general solution to a common problem in software design. A design pattern is not a finished design that can be directly transformed into code. It is a description or template for how to solve a problem that can be used in many different situations.

Design patterns can speed up the development process by providing tried and tested development paradigms. Effective software design requires considering issues that may not be visible until later in implementation. Reusing design patterns helps prevent subtle problems that can cause major problems and improves code readability for coders and architects familiar with the patterns.

Generally , there are 23 kinds of design patterns under three main groups called creational, structural and behavioral.

Under the creational design pattern.

• Abstract Factory
• Builder
• Factory Method
• Object Pool
• Prototype
• Singleton

Structural design pattern

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Private Class Data
• Proxy

Behavioral design pattern

• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Null Object
• Observer
• State
• Strategy
• Template method
• Visitor

I will talk about those patterns one by one in the coming weeks, see ya.

By Yuuma.

Tweet

Factory Method is a creation design pattern that provides an interface for creating objects and allows subclasses to alter the type of objects that will be created.

Imagine that you’re implementing a mailing feature . At first you are sending email with mailgun and all of your business source code are all in one place.

Later you have to implement using another service called mailchimp. So you have to overwrite you source code again. If you are going to use both of the services, your code will be messy to be able to work for both services.

At this point , we can use factory design pattern, by creating objects for both service classes. So, we gonna build a mailing interface with an abstract function `sendmail` first. Then we will have two sub classes to implement that interface (mailgun and mailchimp classes for now). Inside these classes, there will be a function to override the abstract function from interface called `sendmail` which will be different in implementation according to classes.

At the final step, we will create factory classes and return mail implementation concrete classes. The client just has to choose which factory to be used, doesn’t has to know the detail implementation of the concrete classes which is the main theme of this factory pattern.

So I will create code samples for the above scenarios. I will write in PHP & C#.

PHP Sample Code

<?php

abstract class MailerFactory
{
    abstract function mailDriver();
}
class MailchimpFactory extends MailerFactory
{
    public function mailDriver()
    {
        return new MailchimpMailer();
    }
}
class MailgunFactory extends MailerFactory
{
    public function mailDriver()
    {
        return new MailgunMailer();
    }
}

interface Mailer
{
    function sendmail($message);
}
class MailchimpMailer implements Mailer
{
    public function sendmail($message)
    {
        echo("Mailchimp email > " . $message . "<br/>");
    }
}
class MailgunMailer implements Mailer
{
    public function sendmail($message)
    {
        echo("mailgun email > " . $message . "<br/>");
    }
}

//Client code
$client = new MailchimpFactory();
$client->mailDriver()->sendmail("This is from Mailchimp");
$client = new MailgunFactory();
$client->mailDriver()->sendmail("this is from mailgun");
?>

C# sample code

using System;

namespace HelloWorld
{
    abstract class MailerFactory
    {
        public abstract Mailer mailDriver();
    }

    class MailchimpFactory : MailerFactory
    {
        public override Mailer mailDriver()
        {
            return new MailchimpMailer();
        }
    }

    class MailgunFactory : MailerFactory
    {
        public override Mailer mailDriver()
        {
            return new MailgunMailer();
        }
    }

    public interface Mailer
    {
        string sendmail(string message);
    }

    class MailchimpMailer : Mailer
    {
        public string sendmail(string message)
        {
            return "sending from mailchimp";
        }
    }

    class MailgunMailer : Mailer
    {
        public string sendmail(string message)
        {
            return "sending from mailgun";
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var mailgun = new MailgunFactory();
            Console.WriteLine(mailgun.mailDriver().sendmail("sending from mailgun"));


            var mailchimp = new MailchimpFactory();
            Console.WriteLine(mailchimp.mailDriver().sendmail("sending from mailchimp"));
        }
    }

}

Pros

• loosely coupling as classes are not depending on each other.
• easy to maintain (extend or remove) concrete classes.

Cons

• Code might be nasty when many concrete classes are implementing to one interface.

By Yuuma

Tweet

今回は前回作成したコマンドの処理をLinuxのタスクスケジュール(cron)に登録をおこない、指定した日時で自動的に実行させる方法について紹介したいと思います。

Tweet

最近Twitter等でPSPのバッテリーについて少し話題になっていました。

Tweet

神姫バスが兵庫県三田市で自動運転バスの運行実験を開始したそうです。

Tweet