Вопрос о шаблоне структуры класса. Что я должен выбрать?
Это не потому, что структура является вложенной, а потому, что вам нужен получатель-указатель для изменения значения, на которое указывает получатель, в данном случае ваша переменная a.
Без указателя ваш метод UpdateB будет обновлять только копию исходного значения структуры.
См. Следующее:
package main
import "fmt"
type B struct {
c int
}
type A struct {
b B
}
func (a *A) UpdateB(n int) {
a.b.c = n
}
func main() {
a := A{b: B{c: 5}}
fmt.Println(a)
a.UpdateB(50)
fmt.Println(a)
}
8 ответов
В опции (A) Вы создаете то, что известно как Функциональный объект или Функтор, это - шаблон разработки, который хорошо документируется.
Два основных преимущества:
- Рабочие могут быть установлены в одном месте и затем объекте, используемом в другом месте
- Объект может сохранить состояние между вызовами
Также при использовании платформы внедрения зависимости (Spring, Guice и т.д....), функтор может быть автоматически инициализирован и введен везде, где требуется.
Функциональные объекты экстенсивно используются в библиотеках, например, Стандартной библиотеке шаблонов C++
SampleClass1
- Я, возможно, должен поддержать состояние рабочих между doWork
- Мне, возможно, понадобилась бы возможность установить Рабочих индивидуально. (doWork с 1 и 2, затем с 2 и 3)
- Я хочу поддержать рабочих, потому что это, как могли бы ожидать, выполнит doWork многократно на тех же рабочих.
- Я не служебный класс. Экземпляр меня важен.
SampleClass2
- Дайте мне двух рабочих, и я сделаю работу с ними.
- Я не забочусь, кто они, и я не хочу поддерживать их.
- Это - чужое задание для поддержания любого соединения между рабочими.
- Я могу быть большим количеством служебного класса. Возможно, я могу просто быть статичным.
Другая опция, вариант случая A, следующая:
class SampleClass3
{
SampleClass3( IWorker workerA, IWorker workerB );
WorkResult doWork();
}
Преимущества:
Более трудно сделать объект дефектным, так как Вы обязаны предоставлять всех рабочих, которые необходимы во время создания (в отличие от случая A).
Можно все еще нести состояние в SampleClass3 и/или одном из рабочих. (Это невозможно в случае, если B.)
Недостатки:
- У Вас должны быть все свои рабочие, готовые перед построением SampleClass3 вместо способности обеспечить их позже. Конечно, Вы могли также обеспечить методы set, так, чтобы они могли быть изменены позже.
Другая опция:
Класс IWorker:
статический WorkResult doWork (Iworker a, Iworker b);
A) плохой дизайн, потому что он позволяет объекту быть дефектным (один, или оба из классов рабочего, возможно, не были установлены).
B) может быть хорошим. Сделайте это статичным хотя, если Вы не зависите от внутреннего состояния SampleClass2
IMO 2-й подход выглядит лучше, он требует, чтобы вызывающая сторона использовала меньше кода для выполнения задачи. 2-й подход менее подвержен ошибкам, вызывающая сторона не должны волноваться, что объект не мог бы быть инициализирован полностью.
Если больше чем один метод зависит от IWorker a и IWorker b, я говорю, действительно выбирают A.
Если только doWork () использует и IWorker a и IWorker b, то выберите B.
Кроме того, какова реальная цель Вашего SampleClass? doWork немного походит на служебный метод mroe, чем что-либо еще.
Как насчет того, чтобы вместо этого определить a WorkDelegate (или альтернативно интерфейс, имеющий сингл doWork метод без аргумента), который просто возвращает a WorkResult и позволяющие отдельные классы решают, как они реализуют его? Таким образом, Вы не ограничиваетесь преждевременными решениями.