LINUX.ORG.RU
ФорумTalks

ООП, обязанности класса. Упрощение.

 


1

2

ООП предназначено для снижения сложности разработки, но тем не менее существует куча принципов, в том числе и SOLID, следуя которым, появляется куча интерфейсов, классы разбиваются на обязанности, в итоге код становится сложней. Зачем усложнять код преждевременно, без причины. Вот пример простого кода:

public class ApiAttachment {
    public String url;
    public String small_url;
    public int type;

    public void setSmallImageToView(ImageView imageView) {
        String host = imageView.getContext().getString(R.string.host_address);
        new ImageLoaderTask(host, imageView, small_url).execute();
    }
}
Я вынес загрузку изображения в класс Attachment т.к. много, где использовалась эта конструкция. И очень удобно сделать просто myAttachment.setSmallImageToView(imageView); Нормально ли это, как вы считаете?

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

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

Нормально ли это, как вы считаете?

Почему нет? Раз ты задаешь такой вопрос, значит что-то тебя смущает в этом коде. Что?

Stahl ★★☆
()
Ответ на: комментарий от Stahl

Просто я привык дробить на очень мелкие части, кодил так года 3, юзал антипаттерн функциональная декомпозиция, так сказать. Решил переучиться.
Меня наоборот смущало, что у меня повсюду конструкция

 new ImageLoaderTask(host, imageView, small_url).execute(); 
я вынес ее в Attachment. Посоветоваться нескем.

pozitiffcat ★★★
() автор топика

классы разбиваются на обязанности, в итоге код становится сложней.

Что-то ты делаешь не так. Unix-way же во все поля. Разбил на обязанности - код стал проще. А вообще, почитай «Совершенный код» - там вопросы сложности прекрасно освещены.

feofan ★★★★★
()

Код в примере на пехапе?

th3m3 ★★★★★
()
Ответ на: комментарий от feofan

Разбил на обязанности - код стал проще.

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

Stahl ★★☆
()
Ответ на: комментарий от feofan

Да читал я его. И «совершенный» читал, и «чистый» читал. ООП ради ООП надоел. Ведь код должен быть простым. Простой код легко изменять, простой код легко понимать.

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от pozitiffcat

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

Попробуй писать на go. Если, конечно, есть возможность. Мне понравилось, зависимость есть, брат жив.

feofan ★★★★★
()
Ответ на: комментарий от feofan

Знаешь что будет если штангенциркулем попасть в ухо? А я даже знать не хочу — любой инструмент требует использования лишь в каком-то диапазоне применений. Нерационально циркулем копать или ловить блох. У ООП тоже есть своя ниша. Свои способы применения. И не любить ООП это так же нелепо, как не любить микроскопы. Причём не любить микроскопы за то, что они бывают зелёные.

Stahl ★★☆
()
Ответ на: комментарий от feofan

Да нет возможности. На работи плюсы, за работой Java. Если для себя нужно побыстрому наваять что-то пишу на плюсах тоже.

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от Stahl

любой инструмент требует использования лишь в каком-то диапазоне применений

Согласен. ООП хорош, например, в построении GUI. Но его же принято пихать везде.

Меня смущает не сама парадигма, а то, как её применяют - сложившиеся практики. Чрезмерно раздутое дерево наследования. Всё это усложняет код.

На код на яве, например, смотреть страшно с её фабриками фабрик фабрик.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 2)
Ответ на: комментарий от Stahl

Ага. Особенно если классов > 100500, и потом левым людям надо будет в этом разбираться. А вообще, перечитай Совершенный код еще раз. Желательно оригинал.

spider_russia
()
Ответ на: комментарий от pozitiffcat

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

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

Napilnik ★★★★★
()
Ответ на: комментарий от CYB3R

Да будет тебе известно, что комменты очевидных вещей и соответственно их количество - это неуважение к читающему этот код.

spider_russia
()

обязанности класса

Надо ещё написать про права класса, а то получается какое-то классовое неравенство.

Pythagoras ★★
()

К тебе пара вопросов от зеленого человека в ООП. У меня есть проект под ведерко, есть класс, который работает с сетью (NetworkWorker).
Правильно ли, что этот класс занимается:
1)Сборкой URL для разных сценариев
2)Парсингом прилетевшего JSON'a
3)Сборкой другого объекта с данными из JSON'a
4)Вызовом коллбэка, ибо все это в другом потоке
Есть смысл бить это все на классы? Например UrlBuilder, DataDownloader, JSONParser и тд?

Jefail ★★★★
()
Ответ на: комментарий от Jefail

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

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от pozitiffcat

Читаемость кода ухудшается, я просто в свое время натыкался на Single responsibility principle, в моем случае этого нет.

Jefail ★★★★
()
Ответ на: комментарий от Jefail

Если читаемость ухудшается, тогда раздели. Тут по ситуации.

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от Jefail

Есть смысл бить это все на классы? Например UrlBuilder, DataDownloader, JSONParser и тд?

UrlBuilder и DataDownloader должны быть разнесены парктически всегда, поскольку рано или поздно у тебя возникнет задача скачивать данные от URL'ов из другого источника. Аналогично надо отрывать JSONParser, поскольку рано или поздно ты начнешь скачивать не JSON, а например pixmap или архив. Или парсить JSON из локального файла (а.к.а из кэша)

no-dashi ★★★★★
()
Последнее исправление: no-dashi (всего исправлений: 1)
Ответ на: комментарий от no-dashi

Спасибо за внятное разъяснение, пойду рефакторить)

Jefail ★★★★
()
Ответ на: комментарий от no-dashi

Мне кажется, нужно разносить, пока это действительно не понадобится, потому что как правило 50 на 50, что это не понадобится. Или если для понимания херово, то тоже разнести. Сам раньше так делал, но все зря. Другое дело если тестировать собираешься, тут однозначно выносить надо.
Всегда проще исправить простой код, чем сложный.

pozitiffcat ★★★
() автор топика
Последнее исправление: pozitiffcat (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.