[Java] простой вопрос о структуре программы

Мне, как начинающему, не понятно как правильнее и лучше реализовать перечисленные алгоритмы.

Блок-схемой. Иначе заболеешь ЖГМ.

не, ну серьезно

Мне, как начинающему, не понятно как правильнее и лучше реализовать перечисленные алгоритмы. В интерфейсах? или для каждого алгоритма создавать класс? или как лучше?

я использую следующие правила:
1) определяю перечень фич, подлежащих реализации
2) определяю перечень инструментов, которые имплементят фичи
3) далее просто, 1 инструмент = 1 класс

если класс получается слишком большой, значит фичи неправильно раскиданы, думаем, перераскидываем, и снова в бой

иногда имеет смысл упрощать: 1 фича = 1 класс

фичи, например: чтение из файла, кластеризация, построение диаграммы, отображение диаграммы, etc.

интерфейсы имеет смысл использовать в тот момент, когда почувствуешь потребность в них

Я серьезно, вместо того, чтобы набить рабочий код для совершенно плёвой задачки ты хочешь заинженерить её в минимум ста сущностях.

Рефакторинг в жабе безумно дешев, поэтому просто пиши, вылизать и причесать всегда успеешь.

Я серьезно, вместо того, чтобы набить рабочий код для совершенно плёвой задачки ты хочешь заинженерить её в минимум ста сущностях.

Рефакторинг в жабе безумно дешев, поэтому просто пиши, вылизать и причесать всегда успеешь.

если я буду «просто писать» или «как хочу», мне практикант не зачтёт практику :)

интерфейсы имеет смысл использовать в тот момент, когда почувствуешь потребность в них

пишу же, - начинающий.
не затруднит привести несколько примеров, когда есть в них потребность?

я использую следующие правила: 1) определяю перечень фич, подлежащих реализации 2) определяю перечень инструментов, которые имплементят фичи 3) далее просто, 1 инструмент = 1 класс

если класс получается слишком большой, значит фичи неправильно раскиданы, думаем, перераскидываем, и снова в бой

иногда имеет смысл упрощать: 1 фича = 1 класс

фичи, например: чтение из файла, кластеризация, построение диаграммы, отображение диаграммы, etc.

btw, спасибо за это :) я в принципе так и делаю.

мне практикант не зачтёт практику :)

Так бы сразу и сказал, что надо придумать максимально запутанный дизайн.

Тогда всё просто: каждый метод должен реализовывать собственный интерфейс. Обязательно должен быть свой синглтон под каждый параметр конфигурации. Воткни еще куда-нибудь сигналы/события (нам же надо развязать модули системы?) и последует незамедлительный профит.

не затруднит привести несколько примеров, когда есть в них потребность?

с точки зрения языка лучше почитать вот этот материал, там довольно таки обстоятельно расписано

с точки зрения архитектуры, можно почитать, например, вот этот материал (есть примеры на Java)

с точки зрения архитектуры, можно почитать, например, вот этот материал (есть примеры на Java)

вот это надо было

>если я буду «просто писать» или «как хочу», мне практикант не зачтёт практику :)

Важно, чтобы работало, а не то, КАК написано. ИМХО.

Важно, чтобы работало, а не то, КАК написано. ИМХО.

ну у нас «работает» это ещё даже не тройка ;)
2 с плюсом где-то.

Значит ваш препод идиот.

Значит ваш препод идиот.

смотри, когда пишешь вот такие маленькие программы как в ОП, то можно, конечно, и обойтись без этих доп. классов/интерфейсов. Но они не могут дать нам сразу большую программу, а учиться нам как-то нужно..

ого, мнение программиста, программирующего программы на языках программирования?

можете посмотреть как кластеринг организован в Apache Mahout - там разделено на алгоритмы для определения similarity/distance, и алгоритмы самой кластеризации

А то.

Apache Mahout

спасибо большое, прям то что нужно.

не затруднит привести несколько примеров, когда есть в них потребность?

интерфейс - это механизм (одиночной) динамической диспетчеризации. если у тебя в рамках задачи возникают два класса, обладающие одинаковым интерфейсом, но существенно различающиеся по реализации (и есть необходимость делать выбор между их использованием в рантайм) - заводи интерфейс

интерфейс - это механизм (одиночной) динамической диспетчеризации. если у тебя в рамках задачи возникают два класса, обладающие одинаковым интерфейсом, но существенно различающиеся по реализации (и есть необходимость делать выбор между их использованием в рантайм) - заводи интерфейс

читай - «три алгоритма, одна матрица == делай интерфейсы»
я правильно понял?

я правильно понял?

насколько я могу судить по постановке задачи - да. это противоестественно, но именно так делается execution in the kingdom of nouns

Шаг первый: GOD-object.

Сделай один класс, который реализует все. Каждая подзадача - свой метод.

Шаг второй: рефакторинг:

1. Устрани дублирование
2. Разбей длинные методы на логически связанные куски.
3. Сгруппируй методы, решающие схожие задачи. Из каждой группы методов создай свой класс.
4. Дальше сам. Сиди и вчитывайся в свой код, ищи способы его упростить и сделать более логичным. Обязательно делай перерывы. Не делай что-то, что не имеет какого-то предназначения (интерфейсы для красоты или на будущее, только если есть классы с похожими сигнатурами). Помни: код прекрасен когда из него нечего выкинуть, а не нечего добавить.

Когда получишь опыт, сможешь представлять большие куски кода в голове и делать его рефакторинг до написания. Это назвается проектировать. Пока у тебя нету опыта, научить тебя проектировать невозможно.

ты точно читал ОП?

Не занимайся разработкой ПО. Умоляю.

Не занимайся разработкой ПО. Умоляю.

Вы что-то имеете против практичного подхода?

> Важно, чтобы работало, а не то, КАК написано

Жизненный цикл большинства продуктов не заканчивается на выпуске первой версии. Дальше продукт надо сопровождать, модифицировать, расширять и т.д. И вот тут вам все аукнется...

> не затруднит привести несколько примеров, когда есть в них потребность?

Есть такая книжка: Приёмы объектно-ориентированного программирования. Гамма, Хелм, Джонсон, Влиссидес.

Там это расписано довольно таки неплохо.

> Вы что-то имеете против практичного подхода?

Да. ООП - это взаимодействие объектов, а не «кусков кода». И писать вещи вроде: «представлять большие куски кода в голове и делать его рефакторинг до написания», - это провокация к закладыванию изначально неверного понимания сути ООП. Молчу уже про перл «проектирование = рефакторинг-в-уме».

ООП - это взаимодействие объектов

Вы это не от большого опыта говорите. В java, ООП, как взаимодействия объектов нет.

Молчу уже про перл «проектирование = рефакторинг-в-уме».

Тут я с dizza полностью согласен, проектирую точно так же: личинка кода рефакторится в уме с периодическим выбросом в редактор, когда в мозгах уже не умещается, тестами доводится до ума и потом опять в голову на следующую итерацию.

> В java, ООП, как взаимодействия объектов нет.

А что же тогда такое «ООП в java» по Вашему?

Личинка кода рефакторится в уме с периодическим выбросом в редактор, когда в мозгах уже не умещается, тестами доводится до ума и потом опять в голову на следующую итерацию.

Я думаю, Вы путаете понятия «рефакторинг» и «проектирование».

А что же тогда такое «ООП в java» по Вашему?

Не более чем обычные три мантры студентов-плюсовиков. Сдобренные, впрочем, женериками, но от этого истинная цель жабского о-о-пэ всё-равно не меняется. Она призвана не отстрелить себе ногу, а «взаимодействие объектов» сюда никак не входит.

Я думаю, Вы путаете понятия «рефакторинг» и «проектирование».

А ты придаешь этому слишком большое значение. Цель всегда одна — сделать поддерживаемое, гибкое, масштабируемое решение, да подешевле. Как ты этот процесс не назови, суть одна: надо думать, надо писать и кромсать код.

1. Сделать что-то, чтобы работало («работало» = «проверяемо набором юнит-тестов»)
2. Зарефакторить до красивой структуры классов интерфейсов. Непрерывно тестируя тестами из №1.

Ни в коем случае не показывать преподу результат №1.

> а «взаимодействие объектов» сюда никак не входит.
Мне страшно подумать о том, как выглядит по-Вашему «взаимодействие объектов».

Мне страшно подумать о том, как выглядит по-Вашему «взаимодействие объектов».

Это хороший страх, обоснованный, ведь я люблю крякающих драконов.

А что же тогда такое «ООП в java» по Вашему?

Почитай про EJB, доки по Spring и поймешь, что стандартный жавский подход подразумевает написание процедур (сервисов), которые оперируют бинами, по сути структурами, но с геттерами/сеттерами и ассоциациями между собой. Пожалуй на этих ассоциациях и геттерах с сеттерами (которые нужны, кстати, не для инкапсуляции, а для упрощения рефакторинга на будущее) все ООП заканчивается.

Дисклаймер: я такой подход не разделяю, так как у меня DDD головного мозга.

> Почитай про EJB, доки по Spring и поймешь

что ну её нахер, эту яву!

Для лабы по кластерному анализу просто ппц как требуются ежыбэ бины и ынтырпразй-конейнер с иксиэмыль кофнигом!


По теме, ТСу:

Создай четыре метода: читающий данные, нормализующий матрицу, строящий дерево, выводящий результат.

Каждый из методов дорабатывать по-вкусу. Скажем, дерево можно строить из inner class'ов. Для твоей студентческой лабы этого более чем достаточно.

Херотень про интерфейсы и прочий маразматический ынтырпрайз можешь смело забыть.

Херотень про интерфейсы и прочий маразматический ынтырпрайз можешь смело забыть.

Читай выше, ему надо не задачу на кластерный анализ сделать, а как раз навертеть интерфейсов.

я такой подход не разделяю, так как у меня DDD головного мозга.

Разве DDD имеет какое-то отношение к конкретной реализации?

Для лабы по кластерному анализу просто ппц как требуются ежыбэ бины и ынтырпразй-конейнер

А я это и не советовал. Просто пытался разъяснить человеку что есть жавское ООП. И как бы смысл не в интерпрайз иксемель конфиге. Смысл в разделении логики (основной) и данных. И опять же я не говорю что это 100% хорошо, просто так принято в мире.

Разве DDD имеет какое-то отношение к конкретной реализации?

Я EJB со спрингами привел не в качестве примеров реализаций. Ведь это не только набор конкретный технологий, но и набор рекомендаций по проектированию. Да, никто не запрещает плюнуть на эти рекомендации и с их помощью делать DDD.

> ему надо не задачу на кластерный анализ сделать, а как раз навертеть интерфейсов.

Я в это, откровенно говоря, слабо верю. Просто препрод не принимает хоть и работающее, но откровенное говно.

Херотень про интерфейсы и прочий маразматический ынтырпрайз можешь смело забыть.

ну изначальная идея про интерфейсы исходила как раз от практиканта, я хотел сделать просто классы.

1. Сделать что-то, чтобы работало («работало» = «проверяемо набором юнит-тестов») 2. Зарефакторить до красивой структуры классов интерфейсов. Непрерывно тестируя тестами из №1.

Ни в коем случае не показывать преподу результат №1.

это тут спорят про это, мой вопрос был вообще не об этом.
половина программы уже сделана, мне было не совсем понятно как организовать алгоритмы (в интерфейсах или без них). Соб-но, всё в ОП.