Класс против структуры данных

Класс - это просто набор данных и методов, которые могут воздействовать на эти данные. Вы можете использовать класс для реализации структуры данных, но это разные вещи.

Возьмите связанный список, например. Вы можете реализовать структуру данных Linked List, используя класс, и в некоторых языках это самый чистый и очевидный способ сделать это. Это не единственный способ реализовать связанный список, но он может быть лучшим в зависимости от языка.

Связанный список, однако, не имеет ничего общего с тем, чтобы быть классом. Связанный список - это способ представления данных в виде отдельных узлов, где каждый узел каким-то образом связан со следующим.

Структура данных - это концептуальный способ моделирования данных, каждая из которых имеет разные свойства и разные варианты использования. Класс - это синтаксический способ, который некоторые языки предлагают группировать данные и методы.

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

Проще говоря, класс можно рассматривать как синтаксический инструмент, предоставляемый данным языком программирования, скажем Java, который объединяет данные и методы вместе для использования при реализации концепций или объектов в программе или применение.

С помощью класса вы можете реализовать программный компонент, представляющий идею или объект в реальном мире. Вы делаете это, захватывая свойства объекта как переменные-члены и его поведение или операции как методы класса.

Структуры данных , с другой стороны, в основном являются моделями обработки данных (массив, связанный список, дерево двоичного поиска). Класс часто используется для реализации структур данных из-за их уникального способа фиксировать как состояние, так и поведение этих структур.

Таким образом, они различны в этом смысле.

Я рекомендую прочитать Чистый код главу 6: объекты и структуры данных. Вся глава об этом ... Вы можете прочитать реферат, если вы не хотите покупать книгу, ее можно найти здесь .

В соответствии с этим, вы можете эффективно использовать классы двумя различными способами. Это явление называется антисимметрией данных / объектов. В зависимости от ваших целей, вы должны решить, будут ли ваши классы следовать принципу открытого / закрытого или нет.
Если они следуют за OCP, они будут полиморфными, а их экземпляры будут использоваться как объекты. Таким образом, они будут скрывать данные и реализацию общего интерфейса, и будет легко добавить новый тип, который также реализует этот интерфейс. Большинство шаблонов проектирования соответствуют OCP, например, MVC, IoC, каждая оболочка, адаптер и т. Д.
Если они не следуют OCP, они не будут полиморфными, их экземпляры будут использоваться в качестве структур данных. Таким образом, они будут предоставлять данные, и этими данными будут манипулировать другие классы. Это типичный подход и для процедурного программирования. Есть несколько примеров, которые не используют OCP, например, DTO, исключения, объекты конфигурации, шаблон посетителей и т. Д.

Типичный шаблон, когда вы должны подумать о выполнении OCP и переместить код на более низкий уровень абстракции: исправление

class Manipulator {
    doSomething(Object dataStructure){
        if (dataStructure instanceof MyType1){
            // doSomething implementation 1
        }
        else if (dataStructure instanceof MyType2)
        {
            // doSomething implementation 2
        }
        // ...
    },
    domSomethingElse(Object dataStructure){
        if (dataStructure instanceof MyType1){
            // domSomethingElse implementation 1
        }
        else if (dataStructure instanceof MyType2)
        {
            // domSomethingElse implementation 2
        }
        // ...
    }
}

class MyType1 {}
class MyType2 {}
//if you want to add a new type, every method of the Manipulator will change

: перемещение реализации на более низкий уровень абстракции и выполнение OCP

interface MyType {
    doSomething();
    domSomethingElse();
}

class MyType1 implements MyType {
    doSomething(){
        // doSomething implementation 1
    },
    domSomethingElse(){
        // domSomethingElse implementation 1
    }
}

class MyType2 implements MyType {
    doSomething(){
        // doSomething implementation 2
    },
    domSomethingElse(){
        // domSomethingElse implementation 2
    }
}

// the recently added new type
class MyType3 implements MyType {
    doSomething(){
        // doSomething implementation 3
    },
    domSomethingElse(){
        // domSomethingElse implementation 3
    }
}

Типичный шаблон, когда вы должны подумать о нарушении OCP и переместить код на более высокий уровень абстракции: исправление

interface MyType {
    doSomething();
    domSomethingElse();

    //if you want to add a new method here, every class which implements this interface, will be modified
}

class MyType1 implements MyType {
    doSomething(){
        // doSomething implementation 1
    },
    domSomethingElse(){
        // domSomethingElse implementation 1
    }
}

class MyType2 implements MyType {
    doSomething(){
        // doSomething implementation 2
    },
    domSomethingElse(){
        // domSomethingElse implementation 2
    }
}

или

interface MyType {
    doSomething();
    domSomethingElse();
}

class MyType1 implements MyType {
    doSomething(){
        // doSomething implementation 1
    },
    domSomethingElse(){
        // domSomethingElse implementation 1
    }
}

class MyType2 implements MyType {
    doSomething(){
        // doSomething implementation 2
    },
    domSomethingElse(){
        // domSomethingElse implementation 2
    }
}

//adding a new type by which one or more of the methods are meaningless
class MyType3 implements MyType {
    doSomething(){
        throw new Exception("Not implemented, because it does not make any sense.");
    },
    domSomethingElse(){
        // domSomethingElse implementation 3
    }
}

: перемещение реализации на более высокий уровень абстракции и нарушать OCP

class Manipulator {
    doSomething(Object dataStructure){
        if (dataStructure instanceof MyType1){
            // doSomething implementation 1
        }
        else if (dataStructure instanceof MyType2)
        {
            // doSomething implementation 2
        }
        // ...
    },
    domSomethingElse(Object dataStructure){
        if (dataStructure instanceof MyType1){
            // domSomethingElse implementation 1
        }
        else if (dataStructure instanceof MyType2)
        {
            // domSomethingElse implementation 2
        }
        // ...
    },
    // the recently added new method
    doAnotherThing(Object dataStructure){
        if (dataStructure instanceof MyType1){
            // doAnotherThing implementation 1
        }
        else if (dataStructure instanceof MyType2)
        {
            // doAnotherThing implementation 2
        }
        // ...
    }
}

class MyType1 {}
class MyType2 {}

или разбивать классы на подклассы.

Люди обычно следуют OCP по количеству методов один или два, потому что повторять одни и те же операторы if-else недостаточно СУХО.

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