Кодирование OO - для использования Диспетчеров объектов или нет?
Поместите l (печатал строчными литерами буква L), непосредственно перед спецификатором.
unsigned long n;
long m;
printf("%lu %ld", n, m);
6 ответов
Похоже, вы находитесь в той точке, в которой вы двигаетесь помимо определения объектов как «собака есть животное» и перехода к определениям объектов с точки зрения ролей, обязанностей и поведения .
Я бы порекомендовал эту книгу, чтобы помочь вам сделать этот переход и действительно "
У Мартина Фаулера есть полезные рассматривает этот .
Фундаментальный выбор - между Service Locator и Dependency Injection. Во-первых, обе реализации обеспечивают фундаментальную развязку, отсутствующую в наивном примере - в обоих случаях код приложения не зависит от конкретной реализации интерфейса службы. Важное различие между двумя шаблонами заключается в том, как эта реализация предоставляется классу приложения. При использовании локатора служб класс приложения запрашивает его явно, отправляя сообщение локатору. При инъекции нет явного запроса, служба появляется в классе приложения - отсюда и инверсия управления.
Инверсия управления - обычная особенность фреймворков, но за это приходится платить. Обычно это трудно понять, и это приводит к проблемам при отладке. Так что в целом я предпочитаю избегать этого, если он мне не нужен. Это не значит, что это плохо, просто я думаю, что это должно оправдывать себя более простой альтернативой.
Не очень "объектно-ориентированный" вид, когда все эти классы-менеджеры управляют легковесными объектами.
Я не знаю, очень ли это "объектно-ориентированный", но мне кажется, очень похоже на MVC и разделение проблем. Распространенным шаблоном является наличие очень легких бизнес-классов (до такой степени, что они являются просто контейнерами данных) и объектов репозитория, которые их перемещают.
Вы можете продолжить рефакторинг всей функциональности вашего класса User, но, как вы сказали, в конечном итоге в нем ничего не останется. На этом этапе вы можете оценить все другие классы, которые вы создали, а затем сделать индивидуальное суждение по каждому из этих классов, решая в каждом конкретном случае, содержат ли эти классы достаточную функциональность, чтобы гарантировать создание целого нового класса.
Если вы решите, что некоторые из этих классов слишком малы, вы можете вернуть их функции обратно в класс User. Я не вижу ничего плохого в том, чтобы иметь, например, функцию Validate для пользователя, вместо того, чтобы иметь класс UserValidation только с одним методом.
Ситуация, которую вы описываете, связана с тем, следуют ли объекты шаблону самообслуживания или адаптера для сохранения в репозиторий (то есть в базу данных).
Самообслуживание означает, что объекты сохраняются сами 'как в myObjectInstance.Save () , тогда как шаблон адаптера будет myObjectAdapter.Save (myObjectInstance) .
Форма адаптера часто используется, поскольку она удаляет все функции репозитория из объекты.
Я думаю, вы в выигрыше, когда говорите, что эти методы могут не принадлежать объекту пользователя. Методы Get / Search / Save можно обсуждать, но я считаю, что они не должны находиться в самом бизнес-объекте и должны выполняться либо с помощью репозитория (шаблон репозитория), либо с помощью Query Objects , если вы не хотите абстрагироваться от ORM в репозитории.
Что касается аутентификации, было бы лучше иметь набор классов, отвечающих за аутентификацию, и вообще не включать это в объект пользователя. Этот набор классов может знать об объекте пользователя или, что еще лучше, они должны знать о контракте, таком как учетные данные.