Начало: 1, 2.
Конечно же классы пишутся для человека. Задача машины проста - выполнить код. И всё. Код - это функции.Существенная информация для машины - поля, данные хранящиеся внутри объекта, его состояние, и методы-функции, это состояние меняющие. Всё остальное - для человека. Поскольку задача человека сложнее - код поддерживать и развивать. И именно для этого эти функции и данные написаны не сами по себе, а в виде классов.
Основная идея очень проста - представить объекты, как черные ящики, позволить программисту оперировать объектами не зная их внутреннюю структуру. Как, например, в ресторане, я не знаю как и из чего готовится стейк. Мы пользуемся внешним интерфейсом - заказал, съел, заплатил. Да, правильно, это и есть инкапсуляция.
Хорошая идея? Очень. Поскольку знать и помнить всё невозможно. Нужно ограничить информацию, количество оперируемых понятий и состояний. Всегда можно структурировать задачу, разбить её на части, на уровни, с учётом зависимостей. Теперь кодируем эти понятия и уровни в виде объектов и их методов. И готова программа правильная, объектная, понятная и развиваемая! Вперёд!
Говорите, не получается? Тут же всё просто. Значит делаем объект клиент, объект ресторан, объект стейк, объект официант. Дальше добавляем метод "сделать заказ". Кому добавляем метод? Эээ... Официанту? Нет, клиенту? Может ресторану? О, идея! Сделаем класс "менеджер заказов". И добавим его в ресторан. И с ним пусть все общаются. И диспетчер официантов. И очередь клиентов. Так, дальше, состояние заказа. Ага, в стейке хранить не будем. Какое состояние, когда он съеден? Нужен менеджер стейков. Или диспетчер. Клиент? Подожди, тут не до клиентов. Нужен менеджер очередей и диспетчер менеджеров.
А может ну их на хрен объекты? Сейчас быстренько организуем структурку состояния заказа, функцию добавить заказ с несколькими параметрами "ресторан", "клиент", "официант", и т.д. Как просто получается! А массив структур переделаем в табличку базы, всё просто получается. Но не объектно. Ладно, один объект оставим. Ресторан.
Значит, это, о чем я? Ага, вот, мысль первая, очевидная: во всём надо знать меру, и в разбиении на объекты тоже. Расковыряйте любимый компьютер и увидите, что не все комбинации деталей имеют отдельный корпус. Есть готовые детали, которые действительно, как черные ящички со своими выводами, есть их комбинации - сменные платы, и есть самый внешний корпус. Почему-то то, что очевидно в "железе" часто оказывается источником споров в "софте".
Мысль вторая - некоторые действия затрагивают несколько объектов сразу. Модель черного ящика с методами изменяющими "его" состояние, не работает, когда надо согласованно изменить состояние нескольких объектов. Старая добрая функция выглядит здесь наиболее уместно.
Третье - модель черных ящиков работает плохо, когда их много. Может потребоваться построить индексы для быстрого доступа, нужно распределять ресурсы, и т.д. Вплоть до того, что состояние "объекта" может быть не локализовано в одной структуре, а размазано по различным контейнерам в зависимости от типов запросов. Совет - сделайте большой объект с открытыми данными внутри. Это будет проще, чем постоянно передвигать внутренние меж-объектные перегородки.
Четвертое. Эээ... Забыл. Завтра вспомню.
No comments:
Post a Comment