Interpreter

Интерпретатор есть интерпретатор. Нужен он если
1. Необходимо парсить алгебраические выражения (см Origin, Mathematica, Matcad и пр.).
2. Необходимо "понимать" команды пользователя или выполнять определенные сценарии. Пример - скрипты в играх.
3. Нужно менять вывод данных, например, парсить команду юзера и выдавать необходимые столбцы БД, отсортированные по к-л признаку.

Вот собственно, и все. Примеров здесь не будет, так как их можно найти где угодно, в том же Страуструпе, и переделать под нужный язык.

 Iterator
Позволяет скрыть внутреннюю структуру и бизнес логику коллекции данных, предоставляя стандартный интерфейс для клиента. Думаю, тут особо объяснять не нужно, так как итераторы являются неотъемлимой частью Java и C#.
В Java есть интерфейс Iterator с методами hasNext, next, remove; C# - IEnumerator (Move, Reset, Current). Кроме того, в шарпе есть также индексеры, идея которых та же.
 Пример
Java

Без комментариев, все очевидно.

Код

import java.util.*; public class Test {  public static void main(String[] args)  {     Employees e = new Employees();     Iterator i = e.iterator();     while(i.hasNext())     {      System.out.println(i.next());     }  } } class Employees { private String[] data; private EmployeeIterator iter; Employees() {  data = new String[] {"John Smith", "Pablo Picasso", "Stephen Spielberg"}; } public Iterator iterator() {                 // lazy evaluation  if (iter == null)   iter = new EmployeeIterator();  else   iter.reset();  return iter; } public class EmployeeIterator implements Iterator {  private int index;    public boolean hasNext()  {   return index < data.length;  }    public Object next()  {   index++;   return data[index - 1];  }    public void remove() throws UnsupportedOperationException  {                        // птичка Обломинго - нема у нас такого метода   throw new UnsupportedOperationException();  }    public void reset()  {   index = 0;  }   } }

 Преимущества

Предоставляет стандартный интерфейс, чем и напоминает паттерн Bridge. Преимущества те же - реализация скрыта от клиента.

 State
Предположим, что нужно создать некий объект, который будет вести себя по-разному, в зависимости от его текущего состояния. Примером может служить объект типа логгер, который можно "переключать" между состоянием "писать в файл" и "выводить на консоль".
Нетрудно догадаться, что реализация такого объекта включала бы множество конструкций if-else, что-то вроде

Код

if (currentState.equals("toFile"))      // writeToFile() else if (currentState.equals("toConsole"))    // writeToConsole() else //.........

Чем больше возможный состояний, тем сложнее становится класс, тем труднее его менять и поддерживать.
Чтобы исправить ситуацию, используем State паттерн. Вот одна из возможных реализаций :
1. Пишем абстрактный класс State с нужными нам методами
2. Пишем конкретные сабклассы State с реализацией этих методов.
3. Пишем класс, содержащий указатель на текущий сабкласс State.

Для нашего случая (самого элементарного) логгера см. пример.

 Пример
Java

Код

import java.util.*; import java.io.*; public class Test {    public static void main(String [] ar) throws Exception    {       LogManager lm = new LogManager();       lm.setToFile();       lm.log("Hello!");       lm.setToConsole();       lm.log("I'm a log manager");       lm.dispose();    } } class LogManager { private State currentState; private ConsoleState cs = new ConsoleState(); private FileState st = new FileState(); public void setToConsole() {  currentState = cs; } public void setToFile() {  currentState = st; } public void log(String s) {  currentState.log(s); } public void dispose() {  st.dispose(); } } abstract class State { public abstract void log(String s); public void dispose() {}; } class ConsoleState extends State { public void log(String s) {  System.out.println(new Date().toString() + "   " + s); } } class FileState extends State { private FileWriter filew; public FileState() {  try  {   filew = new FileWriter("log.txt");  }  catch (IOException ioe)  {   ioe.printStackTrace();  } } public void log(String s) {  try  {   filew.write(new Date().toString() + "   " + s);   filew.flush();  }  catch (IOException ioe)  {   ioe.printStackTrace();  } } public void dispose() {  try  {   filew.close();  }  catch (IOException e)  {   e.printStackTrace();  } } }

 Strategy
Strategy паттерн очень похож на State, но назначение у него иное. State паттерн означает что возможно переключение между состояниями, поэтому состояния сосуществуют. Strategy, как следует из названия, - это выбор стратегии поведения, алгоритма вычислений. Алгоритм выыбирается и используется чаще всего один раз, ингда даже не пользователем а автоматически.
Примером является сохранение текста в редакторе - его можно сохранить в разных форматах - то есть, нужно выбрать алгоритм записи текста на диск.

Различие между паттернами довольно тонкое - то, что в одной ситуации может выглядеть как "состояние", в другой окажется "стратегией". Все зависит от намерений программиста.

 Пример
C#

Код

namespace ConsoleApplication1 { class Class1 {  [STAThread]  static void Main(string[] args)  {   Console.WriteLine("Enter 1 or 2");   Strategy strategy = new Strategy();          string s = Console.ReadLine();   if (s == "1")    strategy.SetToSqr();   else    strategy.SetToSqrt();   strategy.DoOutput();  } } internal class Strategy {  private Output activeStrategy;    public void SetToSqrt()  {   activeStrategy = new SqrtOutput();  }  public void SetToSqr()  {   activeStrategy = new SqrOutput();  }  public void DoOutput()  {   activeStrategy.DoOutput();  } } internal abstract class Output {  internal abstract void DoOutput(); } internal class SqrOutput : Output {  internal override void DoOutput()  {   for (int i = 0; i < 10; i++)    Console.WriteLine(i + "*" + i + " = " + i*i);  } } internal class SqrtOutput : Output {  internal override void DoOutput()  {   for (int i = 0; i < 10; i++)    Console.WriteLine("sqrt(" + i + ") = " + Math.Sqrt(i));  } } }

А почему некоторые сообщения скрыты?
Где можно про паттерны более подробно почитать? (желательно учебник)

Так надо.


Вот тут обсуждалось.

про одиночку кто-то тут писал

код неверный...в этом случае GetInstance() в случае уже однажды созданного объекта Singleton instance вернет нулл...
тут надо убрать else..
а метод Dispose вообще следует применять очень аккуратно, ведь удалив одиночку его можно будет создать потом еще - создастся уже другой одиночка...но опять же он будет один в системе..
вот так правильно:

Я пробывал в компиляторе запустить код для Factory, что ты приводил. И он особо не запускался. Вот код который я написал на основании твоего.

    
Что я сделал не так?

Это сообщение отредактировал(а) zaletskyy - 18.4.2008, 11:59

zaletskyy, какое отношение  код  сишарпа  имеет к  Java ? 

При реализации одиночки мне кажеться надо метод getInstance описывать как synchronized