Поговорим о паттернах.
Вводная статейка. Скорее как заголовок.
Смотивировать создать ветку не удалось. Посему могу инкапсулировать идеологические холиворы в своем блоге.
Начинаю цикл статей по паттернам.
Вводная:
Нашелся наконец-то человек, который в двух словах смог сказать чем синглтон противоречит принципам ООП.
Итак.
Один из основных принципов фен-шуй в ООП - Один класс, одна задача, один уровень абстракции.
В случае с синглтоном мы на один класс возлагаем две задачи: Выполнение его собственннно предназначения функционального + контроль кол-ва экземпляров в системе (абстракция на уровень выше, задача другого уровня).
Соответственно косяк.
В случае со статик манагерами, которые я тоже уважаю, ситуация другая, хотя результат практически тот же.
У нас есть сущность которая контролирует кол-во и уникальность инстансов в своем пуле. А инстанс сам себе инстанс. Делает свое дело.
Я и раньше предпочитал какой-то внешний манагер классическому синглтону. Но как-то внятно объяснить почему так - не мог. Теперь вот всё стало на свои места.
UPD:
Нашел вот такое вот на хабре.
Писалось не оченнь крутым чуваком потому неточности есть, но в общем и целом как вводная покатит.
Всего комментариев 24
Комментарии
09.11.2013 17:02 | |
Цитата:
(это может создать проблемы,
|
14.11.2013 21:22 | |
Цитата:
Простите пропустил начало беседы.
Цитата:
Основная причина использования синглтона это: ОДИН экземпляр на всю систему
Цитата:
И контроль своего кол-ва - это нифига не основное в синглтоне, основное в нем как раз то, что этот экземпляр умеет делать
Цитата:
Цель
Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа - гарантия единственности экземпляра - глобальная точка доступа По вашему мнению: - гарантия единственности экземпляра - собственный функционал класса Все равно, ни моя, ни ваша точка зрения не противоречат ни тексту из википедии, ни друг другу. Когда уже о каком-нибудь Посетителе будет топик? А то такое чувство, что кроме этого паттерна/антипаттерна других во флеше не применяется. Ах да, MVC еще. А всё остальное - не наше, не flasher-овское |
|
Обновил(-а) expl 14.11.2013 в 21:32
|
14.11.2013 22:15 | |
expl, я бы дополнил твою мысль. Никто здесь не умеет ООП.
|
14.11.2013 22:19 | |
Ну так значит надо нести разумное доброе вечное в массы.
|
15.11.2013 03:07 | |
Еще почитал про визитор.
Это часом не оно? Но все примеры что нагуглил - на плюсах. Там перегрузка методов, потому калька по описанию не работает, а некий аналог есть. Автор творения не я, если че |
15.11.2013 03:38 | |
Цитата:
Это часом не оно
|
15.11.2013 03:39 | |
Ну во флеше перегрузки методов нету, так что вообще никак, по техническим причинам соответственно
|
15.11.2013 17:30 | |
Перегрузка методов здесь совершенно не мешает
http://www.youtube.com/watch?v=KSEyIXnknoY Просто сложно найти ситуацию, в которой этот паттерн аправдан. (там ещё всё упирается в налаживание взаимодействия между реализатором IVisitor и классом в котором он используется, в Java с этим по проще благодаря анонимным и внутренним классам - в том же Eclipse его активно используют). А в as3 это выливается в кучу кода по передаче параметров в реализатор IVisitor(еще сам по себе паттерн не лаконичный ни разу). Да и в Java едва ли посетитель - лучшее решение для большинства ситуаций. Правда то что делают вместо, а именно цепочка ифов "if (value is X)... else if (value is Y) else if (...", тоже создаёт кучу проблем при правках и рефакторинге. Но если в базовом классе наделать методов AsX, AsY, As... и сравнивать их - получается вполне поддерживаемо. А по объемам кода и запутанности это в разы лучше Визитора. Хотя и не даёт его жёсткой проверки на этапе компиляции. |
15.11.2013 17:35 | |
Цитата:
цепочка ифов "if (value is X)... else if (value is Y) else if (..."
|
15.11.2013 17:38 | |
Угу, это то что делают вместо визитора, но никак не визитор
В визиторе это бы выглядело так: ... object:IAcceptor = ... var visitor:IVisitor = new ConcreteVisitor(param0, param1, param3...); object.accept(visitor)// Это вместо if (object is X) else if (... var a = visitor.a; ... // А это то, что было написано внутри функции: public class Visitor implements IVisitor { public function Visitor(param0:... ... public visitX(object:X):void { // тот код, который был внутри ветки if (object is X), только здесь уже не надо приведений } ... public visitY(object:Y):void { // тот код, который был внутри ветки if (object is Y) } } pulbic class X implements IAcceptor { public accept(IVisitor visitor):void { visitor.visitX(this); } } - статической проверки реализации обработки для каждого подтипа (т.е. компилятор ткнёт пальцем куда надо добавить обработчик для нового подтипа или убрать, если подтип удалили) - скорости исполнения (но это либо только для С++, либо когда число if-ов перевалило за десяток - ибо в as3 вызов функции дорогой) |
|
Обновил(-а) expl 15.11.2013 в 17:51
|
Последние записи от Dukobpa3
- Strategy (Стратегия) (27.12.2013)
- State (Состояние) (27.12.2013)
- State-machine (конечный автомат, машина состояний) (25.12.2013)
- Медиатор, Прокси (14.11.2013)
- Инкапсуляция объекта vs инкапсуляция поведения (14.11.2013)