Ещё вопросик хочу напоследок задать, есть ли в нашем случае у varchar(60) какое-то преимущество перед char(60), или наоборот?
А на счёт "перегрузки" - кажется термин употребляется взамен "переопределению". И есть подозрения, что само переопределение (то бишь оверрайдинг) является одним из видов этой самой перегрузки. Разве нет?
В адовых заблуждениях "из-за безграмотности" скорее подошёл бы пример с MVP/ADR, который все называют MVC, хотя паттерн ни разу не похож на него (в вебе вообще невозможно MVC запилить без сокетов).
А ты аргументируешь невозможность изменения переменной в вызывающем методе тем, что передаётся примитив, а значит - по значению.
class A { // Чем не непримитивный тип?
public int x;
}
class B {
public static void main() {
A a = new A();
a.x = 3;
change(a);
System.out.println(a.x); // Выведет 3, по-вашему?
}
public static void change(A a) {
a.x = 5;
}
}
Да, верно. В случае active record (eloquent) у нас по проекту "гуляет" такой себе god-object, который умеет во все (и к базе запрос сделать, и преобразовать данные, и сохранить их). В случае же data mapper'а (doctrine) сущность используется лишь для представления данных.
Верно. Так как всю логику работы с БД мы выносим в репозитории, то при смены ORM нам понадобится лишь написать новую реализацию интерфейсов репозиториев приложения. И все заработает.
Все эти преимущества от использования доктрины очень сильно упрощают поддержку, чтение, тестирование кода.