LINUX.ORG.RU

Как вы проектируете поведение.

 ,


0

2

Так:

class Book {
    private String name;
    private String text;

    public void store(Place place) {
        place.store(name, text);
    }
}

interface Place {
    void store(String name, String text);
}

class Library implements Place {
    @Override
    public void store(String name, String text) {
        // запись в БД
    }
}

// кто-то вызывает
book.store(place);

Или так:

class Book {
    private String name;
    private String text;

    public String getName() {
        return name;
    }

    public String getText() {
        return text;
    }
}

class Library {
    public void store(String name, String text) {
        // запись в БД
    }
}

// кто-то вызывает
library.store(book.getName(), book.getText());

Первый способ гибче, но оверхед есть небольшой, к тому же интерфейс book может распухнуть, если мы начнем много чего пихать в него, например проверку прав доступа при чтении. Второй способ тупой, но не тестируемый и мы раскрываем сущность book.

И вообще, как вы подходите к проектированию системы, когда получаете ТЗ?

book.store(place);

Человек впрыгивает в брюки, да.

library.store(book.getName(), book.getText());

А, нет, в полёте брюки разраваются на штанины и каждая нога насаживается на них самостоятельно.

Я бы сделал library.add(Book book) или book.attachTo(Library library)

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 2)

library.store(Book book);

anonymous ()

Ты понимаешь в каком отнощении у тебя Library и Book или те пофигу?

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

Лучше почитать что-нибудь по ОО проектированию, того же Грейди Буча и попрактиковаться в UML перед кодопейсательством.

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

Я уже все что только можно перечитал. И Буча и Роберта Мартина и GoF, и Кента Бека, и Фаулера. В голове каша после всего этого

pozitiffcat ★★ ()

Ведь ты же сохраняешь тут не книгу, а текст из книги и имя из книги, то есть, ты копируешь книгу в библиотеку. Это неправильная абстракция, ИМХО. Может у вас в жабе так принято, я хз, но это похоже на уродливое уродство.

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

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

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

Это ООП принципы тут как раз не при чем. Ты абстракции неправильно строишь. Библиотека должна выдавать книгу а не копии ее компонентов.

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

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

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

ООП принципы везде одни

кстати, ООП-принципы не везде одни. Java — это вообще не ООП, а лишь его имитация. Настоящее ООП — это когда ВСЕ есть объект, и объекты общаются посредством передачи сообщений. Объект САМ решает, как ему обрабатывать сообщение. Семантика другая, соответственно и возможности, и подходы к проектированию другие.

quest2017 ()

interface Place

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

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

Лишняя зависимость — всегда плохо.

Именно поэтому и нужны интерфейсы.

book.store(place);

Кто на ком стоял? Хранить - это функция книги или места?

ovk48 ★★★ ()

А чо похапе все обсирают? Там ООП точно так же выглядит.

macsucks ()

library.store(book) самый правильный вариант.

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

А чо похапе все обсирают? Там ООП точно так же выглядит.

Вот поэтому, видимо, и обсирают.

quest2017 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.