Как Вы делаете код допускающим повторное использование?
Вы передаете данные в массив по ссылке, и в каждом цикле вы меняете значение ссылки:
self.aUser.username = object["username"] as! String
self.usersAvailableArray.append(self.aUser)
Попробуйте каждый раз создавать нового пользователя:
var newUser = usersAvailable()
newUser.username = object["username"] as! String
self.usersAvailableArray.append(newUser)
Это происходит потому, что объект, который вы добавляете, приходит из класса из документации к присяге :
Классы являются ссылочными типами
В отличие от типов значений ссылочные типы не копируются, когда они назначаются переменной или константе или когда они передаются функции. Вместо копии вместо этого используется ссылка на один и тот же существующий экземпляр. Вы можете увидеть больше о значениях и ссылках в Swift
blockquote>. Еще одно решение - изменить ваш класс на структуру, как показано ниже, structs different, если классы делают копию значения, когда оно передается вместо передать ссылку.
struct usersAvailable { var username = String() var userAvatar = UIImage() }
11 ответов
См. 10 подсказок относительно записи повторно используемого кода для некоторой справки.
- Сохраняют DRY кода. Сухой означает, "не Повторяют Себя".
- Заставляют класс/метод сделать всего одну вещь.
- модульные тесты Записи на Ваши классы И облегчают тестировать классы.
- Удаляют бизнес-логику или основной код далеко от любого кода платформы
- Попытка думать более абстрактно и использовать Интерфейсы и Абстрактные классы.
- Код для расширения. Запишите код, который может легко быть расширен в будущем.
- не пишут код, который не необходим.
- Попытка уменьшить связь.
- Быть больше Модульным
- код Записи как Ваш код является Внешним API
Больше, чем что-либо еще, пригодность для обслуживания делает код допускающим повторное использование.
Возможность многократного использования редко является стоящей целью сам по себе. Скорее это - побочный продукт записи кода, который хорошо структурирован, легко удобен в сопровождении и полезный.
, Если Вы намереваетесь делать повторно используемый код, Вы часто пробуете для принятия во внимание требований для поведения, которое могло бы требоваться в будущих проектах. Неважно, как хороший Вы становитесь в этом, Вы найдете, что понимаете эти соответствующие требованиям завтрашнего дня требования превратно.
, С другой стороны, если Вы запускаете с пустых требований текущего проекта, Вы найдете, что Ваш код может быть чистым и трудным и изящным. Когда Вы работаете над другим проектом, для которого нужна схожая функциональность, Вы естественно адаптируете свой исходный код.
я предлагаю смотреть на лучшие практики для Вашего выбранного языка программирования / парадигма (например, Шаблоны и ТЕЛО для Java / типы C#), Наклон / Гибкая литература программирования, и (конечно) книга "Завершенный Код". Понимание преимуществ и недостатков этих подходов улучшит Вашу практику кодирования никакой конец. Весь Ваш код тогда станет reausable - но 'случайно', а не дизайном.
кроме того, посмотрите здесь: Пишущий Удобный в сопровождении Код
Вы запишете различные модули (части) при записи относительно большого проекта. Повторно используемый код в средствах практики, которые Вы будете иметь, создает библиотеки, которыми могут пользоваться другие проекты, бывшие нужные в той же самой функциональности.
Так, необходимо определить модули, которые могут быть снова использованы, для того
-
Определяют базовую компетентность каждого модуля. Например, если Ваш проект должен сжать файлы, у Вас будет модуль, который обработает сжатие файла. Сделайте НЕ , заставляют его сделать [больше чем 1 112] ОДНУ ВЕЩЬ . Одна вещь только.
-
Запись библиотека (или класс), который обработает сжатие файла, не нуждаясь в чем-то большем чем файле, который будет сжат, вывод и формат сжатия. Это разъединит модуль от остальной части проекта, позволяя ему быть (ре), используемое в различной установке.
-
Вы не должны добираться, это совершенствует в первый раз при фактическом многократном использовании библиотеки, Вы, вероятно, узнаете дефекты в дизайне (например, Вы не сделали его достаточно модульным, чтобы быть в состоянии добавить новые форматы сжатия легко), и можно зафиксировать их во второй раз вокруг и улучшить возможность многократного использования модуля. Чем больше Вы снова используете его (и зафиксируйте дефекты), тем легче это станет к повторному использованию.
самая важная вещь рассмотреть разъединяется, если Вы пишете, что сильно связанная возможность многократного использования кода является первым несчастным случаем.
Отпуск все необходимое состояние или контекст за пределами библиотеки. Добавьте методы для определения состояния к библиотеке.
Для большинства определений "повторного использования" повторное использование кода является мифом, по крайней мере, по моему опыту. Можно ли сказать, что у меня есть некоторые шрамы от этого?:-)
повторным использованием, я не означаю брать существующие исходные файлы и бить их в представление до нового компонента, или сервис выпадает. Я означаю брать определенный компонент или сервис и снова использовать его без изменения.
я думаю, что первый шаг должен вовлечь себя в мышление, что он собирается взять по крайней мере 3 повторения для создания допускающего повторное использование компонента. Почему 3? Поскольку в первый раз Вы пытаетесь снова использовать компонент, Вы всегда обнаруживаете что-то, что он не может обработать. Таким образом необходимо изменить его. Это происходит пару раз, пока наконец у Вас нет компонента, который, по крайней мере, кажется, является допускающим повторное использование.
другой подход должен сделать дорогой перспективный дизайн. Но тогда стоимость все оплачиваема авансом, и преимущества (могут) появиться некоторое время в будущем. Если Ваш босс настоит, что текущий график проектных работ всегда доминирует, то этот подход не будет работать.
Объектная ориентация позволяет Вам осуществлять рефакторинг код в суперклассы. Это - возможно, самый легкий, самый дешевый и самый эффективный вид повторного использования. Обычное наследование классов не требует большого размышления о "других ситуациях"; Вы не должны создавать "всемогущий" код.
Вне простого наследования, повторное использование - что-то, что Вы находите больше, чем Вы изобретаете. Вы находите ситуации с повторным использованием, когда Вы хотите снова использовать один из своих собственных пакетов для решения немного отличающейся проблемы. Когда Вы хотите снова использовать пакет, который точно не соответствует новой ситуации, у Вас есть два варианта.
-
Копия это и фиксируют его. Вы теперь имеете почти к подобным пакетам - дорогостоящая ошибка.
-
Делают исходный пакет допускающим повторное использование в двух ситуациях.
Просто делают это для повторного использования. Ничто больше. Слишком много взглядов о "потенциальном" повторном использовании и неопределенных "других ситуациях" может стать пустой тратой времени.
Для добавления к вышеупомянутым объектам я сказал бы:
- Делают те функции универсальными, который необходимо снова использовать
- конфигурационные файлы Использования и заставить код использовать свойства, определенные в файлах/дб
- , Очевидно включают код в такие функции/классы, что те обеспечивают независимую функциональность и могут использоваться в различных сценариях и определить те сценарии с помощью файлов конфигурации
Другие упомянули эту тактику, но здесь они официально. Эти три получат Вас очень далеко:
- Придерживаются Единственный Принцип Ответственности - он гарантирует, что Ваш класс только "делает одну вещь", что означает, что более вероятно, что это будет допускающим повторное использование для другого приложения, которое включает ту же самую вещь.
- Придерживаются принцип замены Лисков - он гарантирует, что Ваш код "делает то, что предполагается без неожиданностей", что означает, что более вероятно, что это будет допускающим повторное использование для другого приложения, для которого нужно сделанное то же самое.
- Придерживаются эти , Открываются/Закрывают Principle - он гарантирует, что Ваш код может быть сделан вести себя по-другому, не изменяя его источник, что означает, что это, более вероятно, будет допускающим повторное использование без прямой модификации.
Я добавил бы понятие "Композиции классов по наследованию классов" (который получен на основании других ответов здесь). Тем путем "составленный" объект не заботится о внутренней структуре объекта, это зависит от - только его поведение, которое приводит к лучшей инкапсуляции и более легкой пригодности для обслуживания (тестирование, меньше деталей для заботы о). На языках, таких как C# и Java это часто крайне важно, так как нет никакого множественного наследования, таким образом, помогает, что ад графика наследования предотвращения u мог бы иметь.
Как упомянуто, модульный код является более допускающим повторное использование, чем немодульный код.
Один способ помочь к модульному коду состоит в том, чтобы использовать инкапсуляцию, видеть теорию инкапсуляции здесь: http://www.edmundkirwan.com/
Ed.
Если Вы проявляете подход Разработки через тестирование, то Ваш код только становится допускающим повторное использование как Ваш осуществлять рефакторинг на основе предстоящих сценариев.
Лично я нахожу, что постоянно рефакторинг производит более чистый код, чем попытка пересмотреть, для каких сценариев я должен кодировать конкретный класс.
Не изобретайте велосипед заново. Вот и все. И это само по себе дает много преимуществ, упомянутых выше. Если вам действительно нужно что-то изменить, вы просто создаете еще один фрагмент кода, другой класс, другую константу, библиотеку и т. Д.… Это поможет вам и остальным разработчикам, работающим в одном приложении.