Большая Утилита или разделенная на разные части? - PullRequest
1 голос
/ 14 июля 2011

Я пишу приложение, в котором будут участвовать несколько программистов. У нас возникают некоторые проблемы при управлении исходным кодом.У нас обычно есть Utility.php, который делится между разными пользователями.Итак, мы создаем большой файл utility.php, и все так его называют ...

Но мы находим проблему ... Когда мы хотим отделить проект, например, у нас есть конец шрифта CMS,и задний конец.Когда мы хотим разделить существующий проект, нам нужно разделить большой файл utility.php на места или скопировать один раз или выполнить синхронизацию между другими.Итак, мы рассматриваем, использовать разные небольшие утилиты, которые используют только в связанном классе.Любые предложения ??

Текущий: FontEnd.php вызывает -> Utility.php BackEnd.php вызывает ---> Utility.php

Учитывая: FontEnd.php вызывает -> StyleUtility.php, ClientUtility.php, bababa вызывает BackEnd.php ---> DBUtility.php, MaintainUtility.php, ababba

1 Ответ

2 голосов
/ 14 июля 2011

Вы не должны никогда ставить себя в ситуацию, когда у вас есть классы или модули БОГА (те, которые выполняют каждую работу под солнцем).

Они должны хорошо делать одно и одно - это принцип единой ответственности. Если у вас есть один модуль, который выполняет вызовы базы данных и макеты пользовательского интерфейса, вы сделали это неправильно.

Правило, которому вы должны следовать, - максимизировать сцепление и свести к минимуму сцепление.

Максимальная согласованность означает, что все в одном модуле должно быть тесно связано друг с другом (например, все интерфейсы базы данных в одном модуле, все файловые операции ввода-вывода в другом и все статистические функции в еще одном).

Минимальная связь означает, что между классами не должно быть ненужных зависимостей. Должен быть очень четко определенный API для модуля базы данных, и должен быть нет способ делать вещи базы данных, которые обойдут этот API.

Другими словами (например), объединение функций сжатия и управления окнами в одном модуле - плохая идея. Во что бы то ни стало имейте служебный модуль сжатия и модуль управления окнами, но не соединяйте их вместе.

...