Буду благодарен за отзывы и конструктивные замечания.
Что так: суть статьи и ее посыл понятны + делитесь опытом — за это спасибо.
Что не так для меня:
1. ClientBuilder — лишний контракт.
2. MySqlClientBuilder размывает границы доступа к БД в приложении и усложняет процесс его понимания
Как бы сделал я:
1. Сделал объект Client настолько простым, насколько это возможно, в данном случае список полей и get/set методы к ним
2. Объект доступа к БД, ClientDao с операциями saveClient, loadClients, updateClient и т.д.
3. Объект проверки сущности Client в ClientValidator — проверка заполнености всех данных, а также их прикладная согласованность.
4. В слое бизнес логики перед сохранением проверка Client с помощью ClientValidator
Итого имеем: строго формализованные слои приложения:
Слой 'Бизнес Объект' — Client
Слой 'Объект доступа к данным' — ClientDao
Слой 'Проверки объектов' — ClientValidator
Слой 'Бизнес логики' — где происходит манипуляция остальными вышеперечисленными слоями.
С Вами соглашусь.
Я не работал с php, не знаю как принято в проектах на нем, но зачастую даже сама логика валидации может жить в отдельном классе по объекту и вызываться непосредственно перед требуемой задачей. С этой точки зрения объект — он как контейнер данных, хранит ровно то, что в него положили, а достаточно это или нет решает, как правильно подмечено, сам 'контекст'.
А какого поведения вы ожидаете, например, от QueryBuilder'а, если не укажите таблицу?
Вот смотрите: я не указываю таблицу и...? Это валидный sql запрос для определнных СУБД: SELECT 1 на PostgreSql отрабатывает отлично.
Я соглашусь с Delphinum — валидность / невалидность объекта определяет (возможно должна определять) бизнес логика, хотя в рамках конкретных задач бывает и так, что и сам объект успешно справляется с этой задачей, например, на уровне деклараций.
За статью спасибо, читается залпом.
Отдельное спасибо за качество следопыта в Вас, когда разбираешься, пока истина не покажет свое лицо. Люблю таких людей
Логика в хранимых процедура это весьма удобно и часто используется.
А здесь все зависит от типа приложения и характера сопровождения: у нас, например, 4 типа СУБД поддерживаются, а решение сопровождается самим клиентом. Поэтому все в хранимках делать — это та еще задачка.
Но если рассматривать конкретных случае — решение вполне себе приемлимое.
Создание через рефлексию фиксится конструкцией throw в конструкторе.
Я так понимаю, у парней, которые сражаются за свой стиль abstract VS final есть 2 ключевых позиции: краткость и защищенность от.... Во вторую позицию Ваше предложение отлично вписывается, но вот в первую.
История хоть и вымышленная, но родилась не на пустом месте. Лет nth назад я повстречал человека, который утверждал, что final+private constructor не тоже самое, что abstract+private constructor. И его основной аргумент был в том, что через рефлекш, так просто создать объект класса с модификатором abstract не получится, в отличии от final, хотя при этом признавал не эстетичность конструкции. Но вот сколько лет я уже мучаюсь вопросом: 'А зачем?'. Может есть у кого хоть какие-то гипотезы?
Я буду честен — встречал всего один раз такой подход, и думаю недостаточно 1го раза для вывода с моей стороны лучший или хучший
По факту любой синглтон такая фабрика.
Вот с этим я пожалуй не соглашусь.
// Ярко выраженный фабричный метод
MySingleton instance1 = MySingleton.valueOf("MY_SINGLETON");
// Доступ к синглетрну можно и так осуществить
MySingleton instance2 = MySingleton.values()[0];
// и так
MySingleton instance3 = MySingleton.MY_SINGLETON;
Спрошу: Вы используете у себя в коде такой подход?
Спасибо за статью. Я не писал ни на Objective-C и ни на Swift, но примеры для Swift смотрятся так, как будто это твой язык разработки.
Было бы интересно узнать как.
Что так: суть статьи и ее посыл понятны + делитесь опытом — за это спасибо.
Что не так для меня:
1. ClientBuilder — лишний контракт.
2. MySqlClientBuilder размывает границы доступа к БД в приложении и усложняет процесс его понимания
Как бы сделал я:
1. Сделал объект Client настолько простым, насколько это возможно, в данном случае список полей и get/set методы к ним
2. Объект доступа к БД, ClientDao с операциями saveClient, loadClients, updateClient и т.д.
3. Объект проверки сущности Client в ClientValidator — проверка заполнености всех данных, а также их прикладная согласованность.
4. В слое бизнес логики перед сохранением проверка Client с помощью ClientValidator
Итого имеем: строго формализованные слои приложения:
Я не работал с php, не знаю как принято в проектах на нем, но зачастую даже сама логика валидации может жить в отдельном классе по объекту и вызываться непосредственно перед требуемой задачей. С этой точки зрения объект — он как контейнер данных, хранит ровно то, что в него положили, а достаточно это или нет решает, как правильно подмечено, сам 'контекст'.
Вот смотрите: я не указываю таблицу и...? Это валидный sql запрос для определнных СУБД: SELECT 1 на PostgreSql отрабатывает отлично.
Я соглашусь с Delphinum — валидность / невалидность объекта определяет (возможно должна определять) бизнес логика, хотя в рамках конкретных задач бывает и так, что и сам объект успешно справляется с этой задачей, например, на уровне деклараций.
Отдельное спасибо за качество следопыта в Вас, когда разбираешься, пока истина не покажет свое лицо. Люблю таких людей
А здесь все зависит от типа приложения и характера сопровождения: у нас, например, 4 типа СУБД поддерживаются, а решение сопровождается самим клиентом. Поэтому все в хранимках делать — это та еще задачка.
Но если рассматривать конкретных случае — решение вполне себе приемлимое.
Исходник: 85 мегабайт
Время компиляции: Total time: 05:04 min
Я так понимаю, у парней, которые сражаются за свой стиль abstract VS final есть 2 ключевых позиции: краткость и защищенность от.... Во вторую позицию Ваше предложение отлично вписывается, но вот в первую.
История хоть и вымышленная, но родилась не на пустом месте. Лет nth назад я повстречал человека, который утверждал, что final+private constructor не тоже самое, что abstract+private constructor. И его основной аргумент был в том, что через рефлекш, так просто создать объект класса с модификатором abstract не получится, в отличии от final, хотя при этом признавал не эстетичность конструкции. Но вот сколько лет я уже мучаюсь вопросом: 'А зачем?'. Может есть у кого хоть какие-то гипотезы?
Интервьюер оказался человеком с юром, все прошло гладко. Человек X уже более 7 лет работает там и очень доволен.
Я рассуждал так, что перечисленные языки очень похожи, и хотелось увидеть схожие решение на с#
Все равно зачет!!!
Я буду честен — встречал всего один раз такой подход, и думаю недостаточно 1го раза для вывода с моей стороны лучший или хучший
Вот с этим я пожалуй не соглашусь.
Спрошу: Вы используете у себя в коде такой подход?