Слабая связь и методы OO для новичков
Несколько способов сделать то, что вы хотите. Мое предложение: поместите 3 класса в массив, выбирайте случайное число от 0 до 2 каждый раз и присвойте этому имени класса:
<Avatar className={classes[Math.floor(Math.random() * 3)]}.../>
4 ответа
Я полагаю, что Вы отсутствовали на некоторых фундаментальных понятиях.
Идея позади ООП запускается с дискретных, допускающих повторное использование единиц логики. С акцентом на создание самодостаточных модулей.
В случае компонента Заметки RTF это встречает указанные выше критерии путем обработки данного набора данных (заметка) таким способом, которым не заботятся программа и другие объекты в рамках программы, как это делает это - задание. Это - цель, должен показать интерфейс, принять данные, управлять теми определенными данными и передать те данные на другую часть Вашей программы.
Идея позади того, чтобы быть слабо связанным состоит просто в том, что можно заменить то управление заметкой другим управлением, которое встречает те же интерфейсные спецификации. А именно, то, что можно инстанцировать его, позвольте пользователю взаимодействовать с ним и вытащите данные при необходимости.
Быть слабо связанным идет рука об руку с идеей Разделения проблем (SoC); который является процессом повреждения программы в отличные функции, чтобы уменьшить перекрывающуюся функциональность и сделать легче справиться. Но они не то же самое. Incidentaly, это было также одним из основных драйверов отодвигания от процедурного стиля программирования в ООП. Поскольку ООП вынуждает программирование думать с точки зрения связанной и дискретной функциональности.
Это кажется, что Вы действительно спрашиваете о SoC.
Существует много способов достигнуть SoC. Иногда это включает хранение UI, обрабатывая логику и разделенные слои постоянства (рассмотрите шаблон разработки MVC, например). Иногда это просто держит связанные функции вместе для сокращения сложности; который управление RTF уже делает, содержа все функции, необходимые для управления данными так, чтобы у Вас не было дальнейших зависимостей.
Я предложил бы два понятия, интерфейсы и внедрение зависимости, как способ отделить Ваши классы. Интерфейсы дают Вам способ определить контракт или набор ожидаемых поведений, который независим от любой реализации. Когда у Вас есть класс, зависят от интерфейса, а не от класса, Вы получаете свободу заменить другими классами, которые реализуют интерфейс, не имея необходимость переписывать класс, который является в зависимости от него.
Когда Вы используете интерфейсы с внедрением зависимости, т.е. даете классу фактическую реализацию, что это должно продолжить работать, а не иметь его, создают конкретную реализацию самостоятельно, Вы достигаете еще более отделения в Вашем приложении. Теперь класс только знает об интерфейсе и даже не знает, как создать его, просто используйте его. Внедрение зависимости часто используется с creational шаблонами, такими как Разработчик или Фабрика, где Вы локализуете конструкцию объектов в едином классе так, чтобы только, что класс должен измениться при расширении приложения с помощью дополнительных классов.
Кроме того, помните, что связь (и его близнец, сцепление) является относительной мерой. Вы не можете устранить всю связь, или Ваши объекты не смогли бы взаимодействовать. Наличие некоторого уровня зависимости необходимо. Необходимо сбалансировать его с простоты использования и реализации также.
Что касается Вашего конкретного примера, трудно сказать без фактического кода. Я подозреваю, что Вы - сверхразработка решение, и нарушение принципа DRY (не повторяйте себя). Вы, возможно, должны посмотреть на способы использовать интерфейсы и возможно легкую обертку для отделения классов от компонента платформы, а не полного переопределения.
Ну, я не абсолютно ясен по вопросу, но почти кажется, что стратегическая модель работала бы здесь.
Создайте основанное на объектах на своем родительском объекте RTF, но установите методы обработки для хранения, и т.д. как определенные объекты с их собственными методами.
Это включает питание состава, строго не наследовав все родительские методы, и Вы не должны создавать огромный пользовательский объект, просто заменять методы, Вы должны.
Пример, который Вы выбрали, довольно сложен.
Вы правы, когда Вы говорите, что rtf компонент заметки очень слабо связывается. Так свободно, что это является практически не растяжимым, и может только быть использовано как есть, поскольку это интегрирует презентацию/представление, контроллер и модель.
Если Вы хотите видеть пример хорошо разработанной, расширяемой системы обогащенного текста, смотреть на документацию текстовой системы OS X (или Gnustep, если Вы хотите прочитать код). Это сложно, потому что существует много проектных решений, которые должны быть сделаны и потребность, которая будет скрыта от одного модуля до другого. Там можно непосредственно работать в хорошей структуре.
rtf компонент заметки имеет ограниченный объем использования, которое Вам, возможно, придется работать вокруг использования хорошо разработанных классов:
- Загрузка и сохранение данных компонентов только имеют смысл, если Вы не должны сохранять другие данные в своей программе в том же файле/дб.
- Это также не обрабатывает большие объемы данных хорошо.
- И это только понимает небольшое подмножество rtf.