[Заметка] Небольшой пример ООП

@korvin_ · Регистрация: 28.04.2012

Author24 — интернет-сервис помощи студентам

Go поддерживает объектный подход к программированию, однако немного иначе, нежели традиционные ООП-модели (Simula-подобная и SmallTalk-подобная). Вот небольшой пример на основе этого поста:

файл $GOPATH/src/oop/polymorphism/polymorphism.go играет роль UFormOOP.pas

Go    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
package main
 
import (
    "fmt"
    "oop/polymorphism/base"
    "oop/polymorphism/derived"
)
 
func main() {
    base.AddToList( derived.NewSum(1, 2, 3) )
    base.AddToList( derived.NewDiv(6, 2) )
    base.AddToList( derived.NewDiv(5, 0) )
    results := base.CalcAll()
    for _, result := range results {
        fmt.Println(result)
    }
}

здесь ничего интересного =) единственно, я так и не понял как удовлетворить требование не добавлять сюда никаких модулей, кроме стандартных.

файл $GOPATH/src/oop/polymorphism/base/calculator.go играет роль UOOPBaseClass.pas

Go    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
package base
 
import (
    "container/list"
    "strconv"
)
 
type Calculator interface {
    Calculate() (float64, error)
}
 
var calculators *list.List = list.New()
 
func AddToList(c Calculator) {
    calculators.PushBack(c)
}
 
func RemoveFromList(e *list.Element) {
    calculators.Remove(e)
}
 
func CalcAll() []string {
    i, results := 0, make([]string, calculators.Len())
    for e := calculators.Front(); e != nil; e = e.Next() {
        c := e.Value.(Calculator) // type cast
        result, err := c.Calculate()
        if err == nil {
            results[i] = strconv.FormatFloat(result, 'g', -1, 64)
        } else {
            results[i] = err.Error()
        }
        i++
    }
    return results
}

здесь уже появляется знакомое многим программистам на ОО-языках ключевое слово interface. В Go оно значит практически то же самое, что и в, скажем, Java или C#, за исключением того, что интерфейсы в Go могут содержать сигнатуры уже существующих методов, т.е. определенных ранее в других пакетах, например.

В отличие от многих современных языков, в Go нет поддержки параметрического полиморфизма (шаблоны или дженерики), поэтому методы типа list.List используют в качестве типа значений элементов interface{}, что равносильно, например, Object в Java или TObject в Delphi.

При приведении типа (type cast) отсутствует проверка корректности приведения, т.к. функция AddToList гарантирует, что в список будут добавлены только объекты, поддерживающие интерфейс Calculator. В противном случае код выглядел бы немного иначе:

Go    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
...
    for e := calculators.Front(); e != nil; e = e.Next() {
        c, ok := e.Value.(Calculator)
        if !ok {
            continue
        }
        result, err := c.Calculate()
...

файлы $GOPATH/src/oop/polymorphism/derived/sum.go и $GOPATH/src/oop/polymorphism/derived/div.go будут играть роль нового модуля из задания (пакеты в Go могут быть разбиты на несколько файлов, как в данном случае):

Go    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package derived
 
type Sum []float64
 
func NewSum(args ...float64) *Sum {
    s := Sum(args)
    return &s
}
 
func (s *Sum) Calculate() (result float64, err error) {
    for _, arg := range *s {
        result += arg
    }
    return result, nil
}

Go    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
package derived
 
import "errors"
 
type Div struct {
    x, y float64
}
 
func NewDiv(x, y float64) *Div {
    return &Div{x, y}
}
 
func (d *Div) Calculate() (result float64, err error) {
    if d.y == 0 {
        return 0, errors.New("Division by zero")
    }
    return d.x / d.y, nil
}

тип Sum реализуется просто как срез массива чисел с плавающей точкой, но он является не простым псевдонимом для []float64, а новым, самостоятельным типом (при этом не добавляет никакого дополнительного боксинга поверх []float64), а потому для него, как для любого пользовательского типа, можно определить методы, в частности метод Calculate().
Также мы определили две функции-конструктора для обоих типов, это распространенная практика в Go.

Как вы заметили здесь не указывается явно, что Sum и Div реализуют интерфейс Calculator, в этом нет необходимости, т.к. методы не принадлежат интерфейсам, интерфейсы лишь описывают сигнатуры методов, которые должны быть реализованы для типа, чтобы значение этого типа можно было использовать там, где требуется объект с таким интерфейсом (в частности в функциях AddToList, RemoveToList и CalcAll из пакета "base").

Пример выполнения:

Bash    
        
    Скопировано
1
2
3
4
~/prog/go/src/oop/polymorphism $ go run polymorphism.go 
6
3
Division by zero

@ilja123 · 10.01.2014, 21:46

Мне интересно почему самый новый язык сделали не ООП ? Получается, что ООП парадигма фигня никому не нужная

@korvin_ · 11.01.2014, 18:27 **[ТС]**

Сообщение от ilja123

Мне интересно почему самый новый язык сделали не ООП ?

Вообще-то Go вполне объектно-ориентированный.

Сообщение от ilja123

Получается, что ООП парадигма фигня

Да.

Сообщение от ilja123

никому не нужная

Многим нужна.

@castorsky · 28.01.2014, 03:27

Почему тогда фигня многим нужна, если она фигня?

@korvin_ · 28.01.2014, 07:57 **[ТС]**

Потому что ее, во-первых, разрекламировали, во-вторых, понасаждали всюду, где надо и не надо.

@ilja123 · 28.01.2014, 10:25

Прошу заметить, что я не начал холивар. Просто очень заинтересовало. Везде читал, что ООП -новая парадигма програм. А тут разработчики нового языка Go решили сделать новый язык, который лишен всех недостатков присущих другим языкам И вот те НА

Сообщение от korvin_

Вообще-то Go вполне объектно-ориентированный.

Нет Он не вполне ОО В нем есть подобие создания объектов, но это совсем не "ВПОЛНЕ ОО"

@korvin_ · 28.01.2014, 12:29 **[ТС]**

Сообщение от ilja123

Везде читал, что ООП -новая парадигма програм.

Очень новая, да...

Сообщение от ilja123

Нет Он не вполне ОО

Обоснуешь? В Go есть все, что нужно для ООП, в частности dynamic dispatch.

@castorsky · 28.01.2014, 16:00

во-вторых, понасаждали всюду, где надо и не надо

Всемирный заговор разработчиков? Не подумайте что я холиварю, мне хочется "расставить по полочкам" почему именно я испытываю нервоз когда пишу на том же c++ или скажем ada.

@korvin_ · 28.01.2014, 16:55 **[ТС]**

Сообщение от castorsky

Всемирный заговор разработчиков?

Просто следствие удачного маркетинга/пиара.

@ilja123 · 28.01.2014, 17:50

Сообщение от korvin_

Обоснуешь?

Что??? Go НЕ ООП язык!!! korvin_, Вы флудите Хотелось бы услышать адекватный ответ А не ваше "обоснуй"

Сообщение от castorsky

почему именно я испытываю нервоз когда пишу на том же c++

Я слышал, что требуют везде писать в стиле ООП, но не понимаю зачем. Создание классов может себя оправдывать в некоторых случаях Но чтобы использовать везде повсеместно... Это как PHP-прогеры пробуют писать в стиле ООП Хотел бы я увидеть, как это выглядет

@korvin_ · 28.01.2014, 18:24 **[ТС]**

Сообщение от ilja123

korvin_, Вы флудите Хотелось бы услышать адекватный ответ А не ваше "обоснуй"

Вообще-то я ответил, просто ты не захотел прочитать:

Сообщение от korvin_

В Go есть все, что нужно для ООП, в частности dynamic dispatch.

Добавлено через 55 секунд

Сообщение от ilja123

ООП ... Создание классов

ООП != Классы

@Nameless One · 29.01.2014, 17:38

Сообщение от ilja123

Что??? Go НЕ ООП язык!!! korvin_, Вы флудите Хотелось бы услышать адекватный ответ А не ваше "обоснуй"

В приличном обществе принято свои слова подкреплять аргументами. Многократное повторение одной и той же фразы не является аргументом.

@Eugine · 13.03.2014, 01:06

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

1) Помойму если писать на С++ без классов, то намного лучше писать на чистом С
2) Как мне кажется, код, написанный в стиле ООП легче понимать. Все разбито на блоки, зависимость которых можно проследить. Это намного проблематичнее сделать если писать одними функциями.

@castorsky · 13.03.2014, 03:45

Сообщение от Eugine

1) Помойму если писать на С++ без классов, то намного лучше писать на чистом С

Сообщение от korvin_

ООП != Классы

а так же наследование и объекты в ООП разрезе.

Сообщение от Eugine

Как мне кажется, код, написанный в стиле ООП легче понимать

ООП не стиль. Это один из концептов проектирования вычислительной модели. И совершенно не самый простой в "понимании".

Сообщение от Eugine

Все разбито на блоки, зависимость которых можно проследить. Это намного проблематичнее сделать если писать одними функциями.

Вам просто не достает опыта. Это пройдет со временем. Вы рассуждаете о концептах опираясь на конкретные реализации. Это неправильно вот почему: конкретная реализация очень редко (чаще всего никогда) не соответствует конкретно одной парадигме программирования просто потому что это глупо. Надо брать лучшее из разных парадигм если это возможно (и нужно). Так в haskell есть наследование, полиморфизм, ... хотя именно этот ЯП преподносится как "чистый" функциональный язык программирования. Да и вообще, как утверждает один "местный посетитель" -- "пуризм не есть хорошо". В этом я с ним солидарен.

Новые блоги и статьи Все статьи Все блоги /
Как использовать Behavior Graph в Unity при создании игрового AI GameUnited 14.04.2025 Искусственный интеллект в играх прошел долгий путь эволюции. От простейших алгоритмов, движущих призраками в Pac-Man, до сложных систем, управляющих поведением персонажей в современных AAA-проектах. . . .	Создание и стилизация списков в SwiftUI mobDevWorks 14.04.2025 Списки — фундаментальный элемент мобильных интерфейсов. От списка контактов до ленты новостей, от настроек до каталога товаров — трудно представить приложение, которое не использовало бы этот. . .	Паттерн SAGA и распределённые транзакции в микросервисной архитектуре stackOverflow 14.04.2025 Переход от монолитной архитектуры к микросервисам принес множество преимуществ: гибкость разработки, независимость развертывания и масштабирования отдельных компонентов. Однако этот переход создал и. . .	Кастомные аллокаторы в C++ и оптимизация управления памятью bytestream 14.04.2025 Работа с памятью в С++ всегда была и остаётся одной из самых увлекательных и сложных задач для программиста. Любой опытный C++ разработчик подтвердит: стандартные механизмы аллокации памяти – штука. . .	Организация сетей в Kubernetes и эффективное развертывание Mr. Docker 14.04.2025 Сетевая инфраструктура Kubernetes представляет собой сложную, но хорошо спроектированную систему, которая позволяет контейнерам взаимодействовать между собой и с внешним миром. За кажущейся простотой. . .
Многопоточность в Rust: Fearless concurrency и практические примеры golander 14.04.2025 Многопоточное программирование связано с рядом известных проблем. Наиболее распространенные из них — гонки данных (data races), взаимные блокировки (deadlocks) и условия гонки (race conditions). Эти. . .	Списки и кортежи в Python: различия, особенности, применение py-thonny 13.04.2025 Python славится своей гибкостью при работе с данными. В арсенале языка есть две основные последовательные структуры данных, которые программисты используют ежедневно — списки и кортежи. Эти структуры. . .	Middleware в ASP.NET Core UnmanagedCoder 13.04.2025 В ASP. NET Core термин "middleware" занимает особое место. Что же это такое? Middleware представляет собой программные компоненты, которые формируют конвейер обработки HTTP-запросов в приложении. . . .	Таблицы лута в Unity с MinMaxCurve и AnimationCurve GameUnited 12.04.2025 Создание сбалансированного лута в играх — задача не из простых. Разработчики постоянно ищут способы настройки систем выпадения предметов, которые будут одновременно справедливыми для игроков и. . .	std::expected в C++: Управление ошибками bytestream 12.04.2025 Обработка ошибок всегда была важной и одновременно сложной задачей в программировании на C++. На протяжении долгого времени разработчики использовали различные подходы: возвращаемые коды ошибок,. . .

@ilja123 48 / 48 / 6 Регистрация: 24.12.2009 Сообщений: 524
	10.01.2014, 21:46
	Мне интересно почему самый новый язык сделали не ООП ? Получается, что ООП парадигма фигня никому не нужная 0

@korvin_ 4552 / 2750 / 487 Регистрация: 28.04.2012 Сообщений: 8,676
	11.01.2014, 18:27 [ТС]
	Сообщение от ilja123 Мне интересно почему самый новый язык сделали не ООП ? Вообще-то Go вполне объектно-ориентированный. Сообщение от ilja123 Получается, что ООП парадигма фигня Да. Сообщение от ilja123 никому не нужная Многим нужна. 0

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	28.01.2014, 03:27
	Почему тогда фигня многим нужна, если она фигня? 0

@korvin_ 4552 / 2750 / 487 Регистрация: 28.04.2012 Сообщений: 8,676
	28.01.2014, 07:57 [ТС]
	Потому что ее, во-первых, разрекламировали, во-вторых, понасаждали всюду, где надо и не надо. 1

@ilja123 48 / 48 / 6 Регистрация: 24.12.2009 Сообщений: 524
	28.01.2014, 10:25
	Прошу заметить, что я не начал холивар. Просто очень заинтересовало. Везде читал, что ООП -новая парадигма програм. А тут разработчики нового языка Go решили сделать новый язык, который лишен всех недостатков присущих другим языкам И вот те НА Сообщение от korvin_ Вообще-то Go вполне объектно-ориентированный. Нет Он не вполне ОО В нем есть подобие создания объектов, но это совсем не "ВПОЛНЕ ОО" 0

@korvin_ 4552 / 2750 / 487 Регистрация: 28.04.2012 Сообщений: 8,676
	28.01.2014, 12:29 [ТС]
	Сообщение от ilja123 Везде читал, что ООП -новая парадигма програм. Очень новая, да... Сообщение от ilja123 Нет Он не вполне ОО Обоснуешь? В Go есть все, что нужно для ООП, в частности dynamic dispatch. 0

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	28.01.2014, 16:00
	во-вторых, понасаждали всюду, где надо и не надо Всемирный заговор разработчиков? Не подумайте что я холиварю, мне хочется "расставить по полочкам" почему именно я испытываю нервоз когда пишу на том же c++ или скажем ada. 0

@korvin_ 4552 / 2750 / 487 Регистрация: 28.04.2012 Сообщений: 8,676
	28.01.2014, 16:55 [ТС]
	Сообщение от castorsky Всемирный заговор разработчиков? Просто следствие удачного маркетинга/пиара. 0

@ilja123 48 / 48 / 6 Регистрация: 24.12.2009 Сообщений: 524
	28.01.2014, 17:50
	Сообщение от korvin_ Обоснуешь? Что??? Go НЕ ООП язык!!! korvin_, Вы флудите Хотелось бы услышать адекватный ответ А не ваше "обоснуй" Сообщение от castorsky почему именно я испытываю нервоз когда пишу на том же c++ Я слышал, что требуют везде писать в стиле ООП, но не понимаю зачем. Создание классов может себя оправдывать в некоторых случаях Но чтобы использовать везде повсеместно... Это как PHP-прогеры пробуют писать в стиле ООП Хотел бы я увидеть, как это выглядет 0

@korvin_ 4552 / 2750 / 487 Регистрация: 28.04.2012 Сообщений: 8,676
	28.01.2014, 18:24 [ТС]
	Сообщение от ilja123 korvin_, Вы флудите Хотелось бы услышать адекватный ответ А не ваше "обоснуй" Вообще-то я ответил, просто ты не захотел прочитать: Сообщение от korvin_ В Go есть все, что нужно для ООП, в частности dynamic dispatch. Добавлено через 55 секунд Сообщение от ilja123 ООП ... Создание классов ООП != Классы 0

@Nameless One 5828 / 3479 / 358 Регистрация: 08.02.2010 Сообщений: 7,448
	29.01.2014, 17:38
	Сообщение от ilja123 Что??? Go НЕ ООП язык!!! korvin_, Вы флудите Хотелось бы услышать адекватный ответ А не ваше "обоснуй" В приличном обществе принято свои слова подкреплять аргументами. Многократное повторение одной и той же фразы не является аргументом. 1

@Eugine 3 / 3 / 1 Регистрация: 10.11.2012 Сообщений: 63
	13.03.2014, 01:06
	Я слышал, что требуют везде писать в стиле ООП, но не понимаю зачем. Создание классов может себя оправдывать в некоторых случаях Но чтобы использовать везде повсеместно... 1) Помойму если писать на С++ без классов, то намного лучше писать на чистом С 2) Как мне кажется, код, написанный в стиле ООП легче понимать. Все разбито на блоки, зависимость которых можно проследить. Это намного проблематичнее сделать если писать одними функциями. 0

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	13.03.2014, 03:45
	Сообщение от Eugine 1) Помойму если писать на С++ без классов, то намного лучше писать на чистом С Сообщение от korvin_ ООП != Классы а так же наследование и объекты в ООП разрезе. Сообщение от Eugine Как мне кажется, код, написанный в стиле ООП легче понимать ООП не стиль. Это один из концептов проектирования вычислительной модели. И совершенно не самый простой в "понимании". Сообщение от Eugine Все разбито на блоки, зависимость которых можно проследить. Это намного проблематичнее сделать если писать одними функциями. Вам просто не достает опыта. Это пройдет со временем. Вы рассуждаете о концептах опираясь на конкретные реализации. Это неправильно вот почему: конкретная реализация очень редко (чаще всего никогда) не соответствует конкретно одной парадигме программирования просто потому что это глупо. Надо брать лучшее из разных парадигм если это возможно (и нужно). Так в haskell есть наследование, полиморфизм, ... хотя именно этот ЯП преподносится как "чистый" функциональный язык программирования. Да и вообще, как утверждает один "местный посетитель" -- "пуризм не есть хорошо". В этом я с ним солидарен. 1