Интерфесы+Инкапсуляция=Приложения
Вообще, я учился на IT-шной специальности, и в корочке у меня написано "математик-программист". Реально продуманные курсы связанные с программирование были в первых 4-х семестрах, потом начался всякий хлам, про ООП уже никто ничего не знает. И почти всё что было реально полезное, оно из этой книжки.
Но с 76 года прошлого века ситуация немного изменилась, и задач упорядочить упорядочить менее миллиона телефонных адресов, используя только 128 килобайт оперативной памяти перед разработчиками уже не ставят. И вообще, односвязные списки уже давно никто сам не реализует, и сортировки с хешированием, и бинарный поиск - всё это давно есть в std-либах любого языка. Понимать как это работает конечно надо, но только ли это нужно понимать?
В чём разница между программой и приложением. По мне так curl и grep это программы, а facebook и NetBeans - приложения. Я разделил их так, потому что считаю что используя принципы из книжки Вирта, - grep написать можно, а вот NetBeans - нельзя. Разница конечно в сложности, в первую очередь в количестве взаимодействий между компонентами системы. Я хочу сказать что если использовать за основу системы структуры данных (схему базы данных, если хотите), то в какой то момент систему станет невозможно развивать. Любая попытка сделать изменение приведёт к тому что всё развалится. Во первых потому что вся логика завязана на структуры данных, и их уже нельзя поменять. Во вторых потому что в коде нет логики, есть манипуляции c Hibernate-бинами, и когда возникает необходимость после сохранения комментария отправить письмо, оказывается что нужно найти все использования session.save(comment), и добавить Mail.send() следующей строчкой, местах где то в 26. Мой личный опыт говорит о том что это довольно типичная ситуация.
Единственный способ бороться со сложностью - вводить ограничения, которые будут предоставлять гарантии. И чем жёстче будут ограничения, чем меньше будет возможность сделать то же самое но по другому, тем больше шансов что либо изменить. (Довольно смутно?)
В примере выше, про комментарий, сразу понятно - нужно сделать метод createComment(), тогда хотя он всё равно будет вызываться в 26 местах, но если нужно будет изменить его логику, изменить нужно будет только в 1 месте. Пока ничего нового, общую логику нужно выделять в методы, у вирта про это есть. В чём прикол?
Как пишут код, как устроено приложение, всё тот же пример с комментарием. Конечно же используются Entiry-бины, и что бы было совсем хорошо, EntityManager сессия доступна вообще везде в логика приложения. Разработчик что то разрабатывает и тут бац, ему нужно что бы в логике добавлялся комментарий. Конечно же он ищет метод createComment(), если его не находит пишет свой, и использует его. Ага, сейчас там. new CommentEntity(), setPostId(), setTex(), session.save(comment); - У меня всё работает! (с) Почему разработчики так делают? - потому что могут! (хотя, если спросить, любой скажет что это плохо и так делать нельзя)
И вот тут самое интересное, как же заставить разработчиков не делать по плохому. Единственный способ который будет работать - запретить. Сделать так что бы в коде принципиально нельзя было использовать логику представляющую собой реализацию (session.save()). Для работы должны быть доступны только интерфейсы которые предоставляют методы для выполнения конкретных операций. То что стоит за прототипами этих методов - должно быть скрыто, полностью. Я имею в виду буквально. То есть даже если очень хочется - то всё равно нельзя.
Для меня самый большой вопрос, если это так очевидно, почему так никто не делает и почему этому нигде не учат?