Я сейчас делаю плагин к IDEA для автоматического определения мест, где необходимо делать выделение метода, основываясь только на структуре кода.
Результаты очень интересные :-)
Где-то через месяц ожидаю завершение прототипа, мой прогноз — 80% случаев вердикт по выносу в отдельный метод будет верным.
Не скажите.
Структура времени выполнения остается той же — да, верно.
Структура же кода при таком подходе обретает семантику.
Например, при выделении методов им придется давать осмысленные имена.
И не только методам, а еще и параметрам.
А если параметров слишком много — это еще один стимул задуматься, а правильно ли так делать.
Так что от такого шага очень много плюсов.
При этом код времени выполнения будет, скорее всего, таким же.
Мыслить шаблонами и шаблонное мышление — не совсем одно и то же.
Если ты мыслишь шаблонами — ты понимаешь, что есть что-то и помимо шаблонов.
Если у тебя шаблонное мышление — увы, у тебя нет этого понимания.
Я лично стал придумывать, как их можно использовать в моем проекте.
И удивлялся, как они гармонично сочетаются друг с другом :-)
Но тогда я еще не знал о принципе KISS.
Я бы сказал — не только.
Есть еще cohesion и coupling.
Есть принцип единой ответственности.
Есть процедурный, объектно-ориентированный и функциональный подходы.
И есть еще много чего, и все это, примененное в гармонии, вызывает в нас чувство прекрасного.
Паттерны — это не только голые скелеты указанных трех компонент. Они описывают форму, но не содержание.
Кстати, именно поэтому есть даже пара паттернов, имеющих совершенно одинаковую структуру. Предлагаю Вам найти их самостоятельно, чтобы понять, что Вы упуская, размышляя предложенным Вами способом.
Не все так просто,
Как нам кажется порою,
Не все так сложно,
Как логический узор,
Все гармонично,
Только кинь иначе взор — И глубина тотчас
Открыта пред тобою,
Мыслить функциями высших порядков — это особое чувство познания еще одной бесконечной грани мышления :-)
Когда впервые испытываешь это чувство неизвестных доселе возможностей… :-)
P.S. Не совсем задача про раскраску, т.к. в реальной жизни есть еще фактор перераспределения ресурсов — сегодня три человека. завтра пять, в конце вообще один.
Добавление людей при приближении к концу разработки — да.
А вот чем больше людей взять в начале пути… тут уже вопрос некого оптимального числа.
По-моему оптимальное число будет тем что, что и минимальное количество цветов на закраску графа, чтобы никакие две соседние вершины не были закрашены одним и тем же цветом. Вершины — это части функционала, связи между ними — зависимости. Чем лучше продумана архитектура, тем точнее можно определить, какое число людей будет оптимальным.
На готовом проекте это вполне реально, согласен.
Чем старше проект, тем точнее можно прогнозировать временные затраты.
Однако на старте этого, как правило, нельзя сделать, т.к. нет базиса, на основании которого можно давать оценки. Более-менее точные оценки могут появиться после детальной проработки use case'ов (особенно UI) и архитектуры приложения в целом. А могут и не появиться — вопрос, реально ли это нужно, т.к. оценка задачи масштаба проекта занимает существенное время.
Да, так получается, если следовать примерам к использованию framework'ов.
А осмелиться сделать шаг назад и взглянуть на всю картину целиком, отбросив привычные способы работы и взяв на вооружение чистые концепции ООП — это может далеко не каждый. А кто осмеливается, пишет вот такие статьи. Хорошо, что после получения опыта разработки в разных направлениях (desktop, web, gameplay, IDE plugin, etc.) начинаешь чувствовать правильное направление. Но для этого нужна хорошая почва на основе базовых концепций. Если ее нет — это первое, чем необходимо заниматься в плане саморазвития. Отсутствие своего мнения с твердой аргументацией мешает видеть проблемы и пути их решения.
Например, можно делать так.
Есть у нас информация об автомобиле. Это — абстрактный тип данных. Что можно делать с информацией? Читать и писать. Но сама она себя читать и писать не может — это должен делать кто-то еще. Получается, что нам нужен Обработчик информации об автомобиле, умеющий ее читать и писать. Возможно, он является частным случаем обработчика (произвольной) информации. И как ему читать и писать? Для этого нужны инструменты (глаза = wrapper для ResultSet, шариковая ручка = wrapper для PreparedStatement, для примера), которые он использует. Он умеет обрабатывать информацию из модели и подготавливать ее для записи, а также записывать в модель после чтения. И, заметьте, ему пофиг, из базы читать или из файла — это же тоже абстрактный тип данных, специфику оставим классам реализации. А для абстрактного типа данных самое важное — интерфейс. Интерфейс — это сама суть абстракции. Нужно мыслить интерфейсами — тогда ООП получается сам собой. Забудьте про реализацию, когда строите модель. Реализацию нужно вспомнить лишь после построения модели — и, возможно, поправить абстракцию для соответствия реальным возможностям. Но наоборот нельзя — концепция, как правило, рушится при обратном подходе: от реализации к интерфейсу.
Набор процедурных сервисов, как правило, можно заменить набором связанных моделей.
Причем модель инкапсулирует и управляет своим состоянием.
Просто в наше время почему-то народ увлекся процедурным подходом. Видимо потому, что ООП сложнее, требует продумывания use-case'ов, разделения на модели и обдумывание связей между ними, а также поддержание целостности концепции. Процедурный же подход намного проще: взял параметры, обработал, передал результат следующему обработчику, и так пока не дойдет до кода представляния. И то, что все это делается с использованием классов и объектов, не делает этот подход объектно-ориентированным. Это процедурное программирование с использованием объектов, не более того.
Результаты очень интересные :-)
Где-то через месяц ожидаю завершение прототипа, мой прогноз — 80% случаев вердикт по выносу в отдельный метод будет верным.
Структура времени выполнения остается той же — да, верно.
Структура же кода при таком подходе обретает семантику.
Например, при выделении методов им придется давать осмысленные имена.
И не только методам, а еще и параметрам.
А если параметров слишком много — это еще один стимул задуматься, а правильно ли так делать.
Так что от такого шага очень много плюсов.
При этом код времени выполнения будет, скорее всего, таким же.
Если ты мыслишь шаблонами — ты понимаешь, что есть что-то и помимо шаблонов.
Если у тебя шаблонное мышление — увы, у тебя нет этого понимания.
Достаточно лишь правильно посмотреть.
Относитесь к этому проще: это всегда было, и оно от Вас не зависит.
И удивлялся, как они гармонично сочетаются друг с другом :-)
Но тогда я еще не знал о принципе KISS.
Посмотрите легенду об ученике, который научился ходить по воде :-)
Есть еще cohesion и coupling.
Есть принцип единой ответственности.
Есть процедурный, объектно-ориентированный и функциональный подходы.
И есть еще много чего, и все это, примененное в гармонии, вызывает в нас чувство прекрасного.
Паттерны — это не только голые скелеты указанных трех компонент. Они описывают форму, но не содержание.
Кстати, именно поэтому есть даже пара паттернов, имеющих совершенно одинаковую структуру. Предлагаю Вам найти их самостоятельно, чтобы понять, что Вы упуская, размышляя предложенным Вами способом.
Не все так просто,
Как нам кажется порою,
Не все так сложно,
Как логический узор,
Все гармонично,
Только кинь иначе взор — И глубина тотчас
Открыта пред тобою,
Лишь улови… (с)
Когда впервые испытываешь это чувство неизвестных доселе возможностей… :-)
А вот чем больше людей взять в начале пути… тут уже вопрос некого оптимального числа.
По-моему оптимальное число будет тем что, что и минимальное количество цветов на закраску графа, чтобы никакие две соседние вершины не были закрашены одним и тем же цветом. Вершины — это части функционала, связи между ними — зависимости. Чем лучше продумана архитектура, тем точнее можно определить, какое число людей будет оптимальным.
Например, проект должен быть выпущен к какому-то событию.
Чем старше проект, тем точнее можно прогнозировать временные затраты.
Однако на старте этого, как правило, нельзя сделать, т.к. нет базиса, на основании которого можно давать оценки. Более-менее точные оценки могут появиться после детальной проработки use case'ов (особенно UI) и архитектуры приложения в целом. А могут и не появиться — вопрос, реально ли это нужно, т.к. оценка задачи масштаба проекта занимает существенное время.
А осмелиться сделать шаг назад и взглянуть на всю картину целиком, отбросив привычные способы работы и взяв на вооружение чистые концепции ООП — это может далеко не каждый. А кто осмеливается, пишет вот такие статьи. Хорошо, что после получения опыта разработки в разных направлениях (desktop, web, gameplay, IDE plugin, etc.) начинаешь чувствовать правильное направление. Но для этого нужна хорошая почва на основе базовых концепций. Если ее нет — это первое, чем необходимо заниматься в плане саморазвития. Отсутствие своего мнения с твердой аргументацией мешает видеть проблемы и пути их решения.
Есть у нас информация об автомобиле. Это — абстрактный тип данных. Что можно делать с информацией? Читать и писать. Но сама она себя читать и писать не может — это должен делать кто-то еще. Получается, что нам нужен Обработчик информации об автомобиле, умеющий ее читать и писать. Возможно, он является частным случаем обработчика (произвольной) информации. И как ему читать и писать? Для этого нужны инструменты (глаза = wrapper для ResultSet, шариковая ручка = wrapper для PreparedStatement, для примера), которые он использует. Он умеет обрабатывать информацию из модели и подготавливать ее для записи, а также записывать в модель после чтения. И, заметьте, ему пофиг, из базы читать или из файла — это же тоже абстрактный тип данных, специфику оставим классам реализации. А для абстрактного типа данных самое важное — интерфейс. Интерфейс — это сама суть абстракции. Нужно мыслить интерфейсами — тогда ООП получается сам собой. Забудьте про реализацию, когда строите модель. Реализацию нужно вспомнить лишь после построения модели — и, возможно, поправить абстракцию для соответствия реальным возможностям. Но наоборот нельзя — концепция, как правило, рушится при обратном подходе: от реализации к интерфейсу.
инкапсулированареализована концепция абстрактного типа данных.Причем модель инкапсулирует и управляет своим состоянием.
Просто в наше время почему-то народ увлекся процедурным подходом. Видимо потому, что ООП сложнее, требует продумывания use-case'ов, разделения на модели и обдумывание связей между ними, а также поддержание целостности концепции. Процедурный же подход намного проще: взял параметры, обработал, передал результат следующему обработчику, и так пока не дойдет до кода представляния. И то, что все это делается с использованием классов и объектов, не делает этот подход объектно-ориентированным. Это процедурное программирование с использованием объектов, не более того.
В частных случаях — может быть, в общем — все становится монструозным.