-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Хороший тон
- Автор темы master_x
- Дата начала
Gorynych
Посетитель PHP-Клуба
master_x
несколько объявлений классов в одном файле - плохо с точки зрения разработки и сопровождения, но более эффективно с точки зрения непосредственной работы готового приложения (можете обратиться к докладу Расмуса Лердорфа - http://talks.php.net/show/phpclub ). Так что при сборке релиза стоит объединять разрозненные файлы.
с другой стороны... семейство взаимосвязанных классов (например абстрактный родитель и его прямые потомки, или фабрика и ее классы) разносить по разным файлам не так уж и удобно. Возможно, стоит опираться не столько на формальную схему один класс == один файл, сколько на логику и архитектуру приложения в целом ("слой" работы с данными, "слой" ответственный за пользовательский интерфейс и т.п.). Но это - мое частное мнение.
негласные правила именования полей в базе данных существуют. Но я редко сталкивался с такими правилами на уровне MySQL. Люди работающие с СУБД типа MS-SQL Server или Oracle как-то более формализированы в этом вопросе.
опять же, с другой стороны (вот привязалось
есть такое понятие, как метаданные и принятые для описания тех или иных сущностей стандарты. Например, inetOrgPerson - http://unix.org.ua/rfc/rfc2798.html Лично мне кажется более логичным использовать при описании подобных, стандартизированных сущностей, принятые обозначения (в общем-то довольно удобно ссылаться затем на нужный стандарт при интеграции с другим проектом. Всем становится понятнее ожидаемый набор полей). Надо заметить, что для таких, часто встречающихся в нашей работе понятий как "новость", "событие", "документ" и т.п. давно есть метаописания, признанные международным сообществом.
несколько объявлений классов в одном файле - плохо с точки зрения разработки и сопровождения, но более эффективно с точки зрения непосредственной работы готового приложения (можете обратиться к докладу Расмуса Лердорфа - http://talks.php.net/show/phpclub ). Так что при сборке релиза стоит объединять разрозненные файлы.
с другой стороны... семейство взаимосвязанных классов (например абстрактный родитель и его прямые потомки, или фабрика и ее классы) разносить по разным файлам не так уж и удобно. Возможно, стоит опираться не столько на формальную схему один класс == один файл, сколько на логику и архитектуру приложения в целом ("слой" работы с данными, "слой" ответственный за пользовательский интерфейс и т.п.). Но это - мое частное мнение.
негласные правила именования полей в базе данных существуют. Но я редко сталкивался с такими правилами на уровне MySQL. Люди работающие с СУБД типа MS-SQL Server или Oracle как-то более формализированы в этом вопросе.
опять же, с другой стороны (вот привязалось
есть такое понятие, как метаданные и принятые для описания тех или иных сущностей стандарты. Например, inetOrgPerson - http://unix.org.ua/rfc/rfc2798.html Лично мне кажется более логичным использовать при описании подобных, стандартизированных сущностей, принятые обозначения (в общем-то довольно удобно ссылаться затем на нужный стандарт при интеграции с другим проектом. Всем становится понятнее ожидаемый набор полей). Надо заметить, что для таких, часто встречающихся в нашей работе понятий как "новость", "событие", "документ" и т.п. давно есть метаописания, признанные международным сообществом.
master_x
Не думаю что это имено тот случай когда стоит, группировать классы.
Эти 3 класса представляют разные слои приложения, и даже если эти абстрактные( а я надеюсь что это абстрактные иначе ... )
Стоит групировать классы только тогда когда этот фаил будет независимым и завершенным решением чего-либо.
Gorynych
В MySQL нету негласных. При интеграции вполне достаточно соблюдать свои стандарты, и предоставить документацию.
Сейчас спешу, вечером более подробно объясню свою мысль.
Не думаю что это имено тот случай когда стоит, группировать классы.
Эти 3 класса представляют разные слои приложения, и даже если эти абстрактные( а я надеюсь что это абстрактные иначе ...
) Стоит групировать классы только тогда когда этот фаил будет независимым и завершенным решением чего-либо.
Gorynych
В MySQL нету негласных. При интеграции вполне достаточно соблюдать свои стандарты, и предоставить документацию.
Сейчас спешу, вечером более подробно объясню свою мысль.
ИМХО.
Парадигма одна. Но она не завершенная, она имет множество классов наследников, выходящих за эти рамки. В таком случае, можно вносить в 1 файл например ядро CMF. Лично я бы вносил в 1 файл несколько классов только:
а) Законченное приложение, библеотека.
б) Реализация схожих задач лежащих в 1 слое.
BRat какая тесная взаимосвязь между ними? Что Вы вкладываете в это понятие?
Парадигма одна. Но она не завершенная, она имет множество классов наследников, выходящих за эти рамки. В таком случае, можно вносить в 1 файл например ядро CMF. Лично я бы вносил в 1 файл несколько классов только:
а) Законченное приложение, библеотека.
б) Реализация схожих задач лежащих в 1 слое.
BRat какая тесная взаимосвязь между ними? Что Вы вкладываете в это понятие?
BRat ОМГ. Мы говорим про абстрактные классы. Или у тебя 1 класс контролера, модели, и вью?
master_x
Так что такое библиотека по моему или определение?
Библиотека например набор классов реализующие парсер XML, который я написал еще давно иногда только улучшаю изредка. Поэтому подключая 1 единственный файл в разные проекты, я подключаю слой работы с XML. Это как по мне удобно. Заметьте, если б я его делал конкретно под 1 проект, я бы разбил его на файлы.
master_x
Так что такое библиотека по моему или определение?
Библиотека например набор классов реализующие парсер XML, который я написал еще давно иногда только улучшаю изредка. Поэтому подключая 1 единственный файл в разные проекты, я подключаю слой работы с XML. Это как по мне удобно. Заметьте, если б я его делал конкретно под 1 проект, я бы разбил его на файлы.