Большая Конфигурация для класса, предложения по реализации - PullRequest
Новая
       13

Большая Конфигурация для класса, предложения по реализации

2 голосов
/ 23 мая 2011

Итак, у меня большой класс, который я реорганизую, чтобы быть более гибким.

более 100 настраиваемых свойств (переменных) в файле INI. Некоторые из них являются настройками разработчика, а другие - производственными настройками.

В настоящее время я использую флаг среды, чтобы получить нужные настройки INI (dev или prod).

Все поля INI являются обязательными и должны быть установлены. (в настоящее время для этого используются сеттеры).

Так что имеет больше смысла?

  • A: сохранить текущие настройки
  • B: перейти к настройке конфигурации другого типа (например, xml или что-то еще)
  • C: переместить все настройки в сам скрипт и удалить код синтаксического анализа и проверки INI (сеттеры)
  • D: предложения?

Бонусный вопрос:

Я читал это в выходные дни: http://berryllium.nl/2011/02/getters-and-setters-evil-or-necessary-evil/ и хотел знать, как я мог бы больше следовать этому стилю разработки такого типа, но был озадачен тем, как не использовать функциональность getter / setter с установкой обязательных полей? Я понимаю необходимость получения / установки и хотел бы знать, правильно ли я их реализую?

Я использую INI для таких вещей, как настройки БД, лимиты проверки (допустим, лимит расходов составляет 100 долларов, но он может измениться), большой массив (статические значения, такие как 50 штатов США, но с возможностью добавления территорий США)

Ответы [ 2 ]

2 голосов
/ 23 мая 2011
  • Если вы хотите сохранить настройки читать, сохранить текущие настройки или перенести настройки в PHP-скрипт (но сделать не кодировать их жестко в классы).
  • Если Вы хотите увеличить производительность - использовать формат JSON или скрипт PHP - json_decode работает быстрее, PHP скрипт работает быстрее и легко кэшируется по БТР.
  • Как вариант, вы можете разобрать файл настроек один раз и поставь все настройки в кеше (APC или memcache).

Также. Я думаю, что никого не волнует, но у меня есть свое мнение о добытчиках и установщиках :) Геттеры и сеттеры не злые. Идея инкапсуляции заключается не только в том, чтобы скрыть поля, но и скрыть, как работает класс. Методы получения и установки могут быть объявлены в интерфейсе, так что вы можете заменить один объект другим - и именно для этого была изобретена инкапсуляция!

Давайте возьмем пример из статьи Берри Лангерака - withdraw и deposit это сеттеры. Весь этот код можно успешно выполнить методом setBalance, практически ничего не изменится. Все эти проверки, сравнения - это обычная работа сеттеров.

Почему публичные поля злые? Потому что объект не может контролировать их изменение и потому что они не могут быть объявлены в интерфейсах. Геттеры и сеттеры могут это делать, так что это идеальный инструмент ООП.

Аксессоры, конечно, могут быть написаны глупо, но это не значит, что они злые. Любой метод в классе может быть написан глупо.

1 голос
/ 23 мая 2011

Интересный вопрос.

Я очень сомневаюсь, что все эти переменные могут / могут отличаться в вашей области разработки и вашей области производства. Не все переменные, которые вы можете изменить при отладке, должны храниться в файле конфигурации.

Я бы посоветовал использовать константы для большинства переменных. У вас есть автозаполнение, множество вариантов IDE, и его легко редактировать. Не говоря уже о том, что логичнее разбивать их на разные файлы, чем разбирать тонны ini.

...