Объектная нормализация
Вы должны проверить, использовалось ли действие POST:
if ( Вы должны проверить, использовалось ли действие POST:
[110] в вашем случае
...
if ($this->loginService->check()) {
if ( Вы должны проверить, использовалось ли действие POST:
[110] в вашем случае
[111]SERVER['REQUEST_METHOD'] == 'POST') {
if (!empty( Вы должны проверить, использовалось ли действие POST:
[110] в вашем случае
[111]POST['title'])) {
...
}
}
}
SERVER['REQUEST_METHOD'] == 'POST')
в вашем случае
...
if ($this->loginService->check()) {
if ( Вы должны проверить, использовалось ли действие POST:
[110] в вашем случае
[111]SERVER['REQUEST_METHOD'] == 'POST') {
if (!empty( Вы должны проверить, использовалось ли действие POST:
[110] в вашем случае
[111]POST['title'])) {
...
}
}
}
10 ответов
Я предполагаю, что Единственный Ответственный Принцип, по крайней мере, связан с этим. Или по крайней мере, нарушение SRP подобно отсутствию нормализации до некоторой степени.
(Возможно, что я говорю мусор. Я довольно устал.)
Нормализация имеет математическую основу в логике предикатов и ясную и определенную цель что та же информация никогда не быть представленной дважды в единственной модели; цель этой цели состоит в том, чтобы устранить возможность непоследовательной информации в модели данных. Это можно показать через математическое доказательство, что, если модель данных имеет определенные определенные свойства (что это проходит тесты для 1-й нормальной формы (1NF), 2 нФ, 3 нФ, и т.д.), что это лишено избыточного представления данных, т.е. это Нормализовано.
Объектная ориентация не имеет такого базового математического основания, и действительно, никакой ясной и определенной цели. Это - просто дизайнерская идея для представления большего количества абстракции. Принцип DRY, Разделение Запроса Команды, принцип замены Лисков, Открыто закрытый Принцип, Tell-Don't-Ask, Принцип Инверсии Зависимости и другая эвристика для улучшения качества кода (многие из которых применяются к коду в целом, не только объектно-ориентированным программам) не являются абсолютными по своей природе; они - инструкции, которые программисты нашли полезными в улучшающейся понятности, пригодности для обслуживания и тестируемости их кода.
С реляционной моделью данных можно сказать с абсолютной уверенностью, "нормализована" ли она или нет, потому что она должна пройти ВСЕ тесты для нормальной формы, и они довольно конкретны. С объектной моделью, с другой стороны, потому что цель "понятного, удобного в сопровождении, тестируемого, и т.д." довольно неопределенна, Вы не можете сказать ни с какой уверенностью, удовлетворили ли Вы той цели. Со многой из эвристики дизайна Вы не можете даже сказать наверняка, следовали ли Вы за ними. Вы следовали за принципом DRY при применении шаблонов к дизайну? Конечно, повторным использованием шаблона не является DRY? Кроме того, часть этой эвристики или принципов является не всегда даже обязательно хорошим советом все время. Я действительно пытаюсь следовать за Разделением Запроса Команды, но такие полезные вещи как Стек или Очередь нарушают то понятие, чтобы дать нам довольно изящный и полезный результат.
Интересный.
Можно также интересоваться рассмотрением Закона Demeter.
Другой вещью, которой можно интересоваться, является FearOfAddingClasses c2, как, возможно, то же обоснование, что ведущие программисты для денормализовывания баз данных также приводят к классам бога и другим запахам кода. И для OO и для нормализации DB, мы хотим анализировать все. Для баз данных это означает больше таблиц, для OO, больше классов.
Теперь, стоит принять во внимание объектное реляционное несоответствие импеданса, то есть, вероятно, не все переведет чисто.
Объектные реляционные модели или 'слои персистентности', обычно имейте 1 к 1 отображения между полями базы данных и атрибутами объектов. Так, мы можем нормализовать? Скажите, что мы сделали, чтобы отдел возразил с employee1, employee2... и т.д. приписывает. Очевидно, это должно быть заменено списком сотрудников. Таким образом, мы можем сказать работы на 1 нФ.
Имея это в виду, давайте пойдем прямо для уничтожения и взгляда на проектирование баз данных на 6 нФ, хорошим примером является Моделирование Привязки, (проигнорируйте соглашение о присвоении имен). Modeling/6NF привязки предоставляет высоко анализируемые и гибкие схемы базы данных; как это переводит в OO 'нормализацию'?
Моделирование привязки имеет эти виды отношений:
- Привязки - идентификаторы уникального объекта.
- Атрибуты, которые переводят в атрибуты объектов: (Привязка, значение, метаданные).
- Связи - отношения между двумя или больше объектами (самими привязки): (Привязка, Привязка..., метаданные)
- Узлы, приписанные Связи.
Метаданные атрибута могут быть чем-либо - кто изменил атрибут, когда, почему, и т.д.
Перевод OO этого является чрезвычайно гибкими взглядами:
- Привязки предлагают заполнителей атрибута меньше, как прокси, который знает, как иметь дело с составом атрибута.
- Атрибуты предлагают классы, представляющие атрибуты и чему они принадлежат. Это предлагает применить повторное использование к тому, как атрибуты ищутся и имели дело с, например, автоматическая ограничительная проверка, и т.д. От этого у нас есть основание, чтобы в общем реализовать GOF-стиль Структурные шаблоны.
- Связи и Узлы предлагают классы, представляющие отношения между объектами. Основание для универсальной реализации Поведенческих шаблонов разработки?
Интересные и желательные свойства Привязки, Моделируя, которые также переводят через:
- Все это требует наследования замены с составом (хорошим) в выставленных объектах.
- Атрибут имеет владельцев, а не владельцев, имеющих атрибуты. Хотя это делает поиск атрибута более сложным, он аккуратно решает определенные проблемы искажения, поскольку может только когда-либо быть один владелец.
- Никакая потребность в ПУСТОМ УКАЗАТЕЛЕ. Это переводит в более четкую ПУСТУЮ обработку. Классы атрибута пустого ящика могли предоставить методы для обработки отсутствия конкретного атрибута, вместо того, чтобы выполнить ПРОВЕРКУ ПУСТОГО УКАЗАТЕЛЯ везде.
- Метаданные атрибута. Уровень атрибута полный historisation и обвинение: 'воспроизведите' объекты вовремя, посмотрите то, что изменилось, когда и почему, и т.д. (при необходимости - метаданные являются совершенно дополнительными),
Вероятно, было бы много очень простых классов (который хорош), и стиль очень декларативного программирования (также хороший).
Спасибо за такой вопрос о вызове мысли я надеюсь, что это полезно для Вас.
Возможно, Вы берете это с реляционной точки зрения, но я установил бы это, принципы интерфейсов и наследования соответствуют нормализации в мире ООП.
Например, a Person абстрактный класс, содержащий FirstName, LastName, Gender и BirthDate может использоваться классами такой как Employee, User, Member и т.д. как допустимый базовый класс, без потребности повторить определения тех атрибутов в таких подклассах.
Принцип DRY, (базовый принцип Andy Hunt и книги Dave Thomas Прагматически настроенный Программист), и постоянный акцент объектно-ориентированного программирования на повторном использовании, также соответствует эффективности, предлагаемой Нормализацией в реляционных базах данных.
На первый взгляд я сказал бы, что цели Рефакторинга Кода подобны абстрактным способом к целям нормализации. Но это довольно абстрактно.
Обновление: Я почти записал ранее, что "мы должны привести Jon Skeet на этом". Я отправил свой ответ и кто избил меня? Вы предположили это...
Объектное Ролевое Моделирование (чтобы не быть перепутанным с Объектным Реляционным Отображением) является самой близкой вещью, о которой я знаю к нормализации для объектов. Это не имеет столь же математической основы как нормализация, но это - запуск.
Довольно специальным и неизученным способом, который, вероятно, заставит пуристов насмехаться, и возможно справедливо, я думаю о таблице базы данных, как являющейся рядом объектов конкретного типа, и наоборот. Затем я беру свои мысли оттуда. Просматриваемый этот путь, это не кажется мне, любят существует что-либо особенно специальное, которое необходимо сделать для использования нормальной формы в повседневном программировании. Идентификационные данные каждого объекта сделают для начинающих как его первичный ключ, и ссылки (указатели, и т.д.) сделают посредством внешних ключей. Затем просто следуйте тем же правилам.
(Мои объекты обычно заканчиваются в 3 нФ, или некоторое приближение этого. Я рассматриваю это все больше как инструкции, и, как я сказал, "неизученный".)
Если правила сопровождаются правильно, каждый бит информации затем оказывается в одном месте, взаимосвязи ясны, и все структурировано таким образом, что представление несоответствий берет некоторую работу. Можно было сказать, что этот подход приводит к хорошим результатам на этой основе, и я согласился бы.
Одна оборотная сторона - то, что конечный результат может чувствовать немного как путаница спагетти, особенно через какое-то время далеко, и трудно встряхнуть постоянную непрекращающуюся сенсацию, даже при том, что это обычно - ложь, это, конечно, несколько из всех этих ссылок могли быть удалены...
Объектно-ориентированное проектирование рационально, но оно не имеет того же математически четко определенного основания как Реляционная модель. Нет ничего точно эквивалентного четко определенным нормальным формам проектирования баз данных.
Является ли это силой, или слабость Объектно-ориентированного проектирования является вопросом интерпретации.
Я второй SRP. Открыть Closed Principle применяется также к "нормализации", хотя я мог бы расширить значение слова, в котором должно быть возможно расширить систему путем добавления новых реализаций, не изменяя существующий код. objectmentor о OCP
хороший вопрос, извините я не могу ответить подробно
Я работал над объектной нормализацией прочь и над больше 20 лет. Это глубоко и сложно и красиво, и является предметом моей второй запланированной книги, Объектная Механика II. ONF = Объектная Нормальная форма, Вы слышали его здесь сначала!;-)
так как потенциально патентоспособная технология скрывается в, я не имею право говорить больше, за исключением того, что нормализация данных является действительно легкой частью ;-)
ПРИЛОЖЕНИЕ: изменение планов - видит https://softwareengineering.stackexchange.com/questions/84598/object-oriented-normalization