Кажется, только сейчас я понял, почему программисты так злоупотребляют статическими полями — видимо, они действительно думают, что статические поля это общие данные класса (т.е. всего множества объектов — экземпляров данного класса).
Но ведь в любой (любой!) хорошей книжке по ООП написано, что класс это всего лишь тип данных, а не множество объектов!
Соответственно, если мы заводим статическое поле класса — характеристику именно типа данных, то если мы пытаемся использовать это поле как общие данные множества объектов, то мы используем инструмент не по назначению (пытаемся завивать гвозди кусачками) => куча проблем.
Не хотелось бы показаться резким и некорректным, но из таких советов:
При создании класса слонов сохраняем кол-во всех слонов, сумму длительности жизни, роста, веса всех слонов в статические поля и после получаем все средние величины.
можно в любой книжке по ООП составлять главу «Примеры, как не надо делать».
Если у нас есть тип данных (класс в понятиях ООП) «Слон», то для полноценной реализации сущности предметной области нам нужно реализовать типы данных «Список слонов» и «Слоны», которые и будут разруливать общее кол-во слонов, их средний вес и т.д.
В случае, если мы заводим в одном типе данных «Слон» статические поля «общее кол-во», какие-то средние величины, то даже говорить не хочется что будет с вашими этими полями при работе с многопотоком, с сопровождением кода двумя-тремя и более «поколениями» программистов, и т.д.
Есть впечатление, что при том, что ООП сейчас явно находится в кризисе, если не в конце жизненного цикла (тут и от функциональных языков какие-то ожидания, и чуть ли не скриптовый Golang, по моему мнению, являющийся одним из кандидатов на новый мейнстрим),
так вот при этом, к сожалению, ООП за этот период так и не «взлетел», т.е. не использовался так, чтобы получить отдачу, от того, что вообще заложено в ОО-концепцию.
А жаль — инструмент очень красивый и мощный.
Именно это имелось в виду, просто торопился — хотел написать «экземпляры этих классов», потом понял, чтобы не было путаницы между терминами ООП и теорией множеств, нужно написать «экземпляры этих типов данных».
Мне кажется, вы смешали понятие статических классов и статических элементов нестатических (экземплярных) классов.
Кроме того, вы упомянули эти вещи как средства реализации теории множеств в ОО-программировании.
Но именно злоупотребление этими вещами не по назначению, приводит к куче проблем в отладке, к трудностям сопровождения кода, к торможению и завалу проектов и т.д.
Попробуем по пунктам:
1. Статические классы это не более чем «хелперы», содержащие несколько процедур (вычисляющих 2 + 2, например, т.е. не имеющие отношения ни к конкретному типу объектов, ни к предметной области в целом), которыми мы можем пользоваться там, где нам нужно что-то вычислить, и при этом мы не хотим заниматься копи-пастом.
Статические классы — это в чистом виде процедурное программирование (то, что несколько процедур оборачиваются в отдельный статический класс, экземпляр которого нельзя создать — чистая условность, т.к. многие большинство ОО-языков не позволяют объявить процедуру вне класса — и это правильно).
Относить процедурное программирование к теории множеств перебор, иначе бы те, кого не устраивает противоречивость ООП, просто пользовались бы процедурным программированием.
2. Что же касается статических элементов нестатического класса (поля, методы), то это очень опасный инструмент — но это необходимое зло.
К теории множеств это не имеет не малейшего отношение. Назначение таких элементов чисто техническое.
Полагаю, если бы не необходимость реализации экземплярного конструктора — технически в виде статического метода — то не было бы в чистом ООП статических методов и полей в нестатических классах.
Не говорю уж таких вещах, как «статические методы» и «методы класса», которые оба являются неэкземплярными (в Delphi language есть такое) — не думаю, что стоит пытаться реализовывать теорию множеств, полагаясь на такие сугубо технические вещи.
Идея ООП в том, что есть тип данных, и экземпляры этих данных.
«Расшаривание» между экземплярами неких данных (полей) на уровне именно класса, а не специальных структур — отдельных объектов (экземпляров других классов), приводит к гарантированному завалу кода и проекта (тут и проблемы при многопоточности, и внезапное изменение данных другим экземпляром и т.д.).
Использование статических методов в нестатических классах — тоже опасная вещь, и лучше выносить их в хеплер (статический класс),
т.к. наличие в нестатическом классе статического метода имеет подводный камень:
что если, в будущем этот метод все же начнет пользоваться экземплярными данными класса (состоянием объекта)? придется объявлять метод экземплярным, а ведь есть уже куча кода, которая его вызывает и считает статическим; если вы четко видите, что метод не вынести в хелпер, значит, понимаете, что метод неразрывно связан с классом и потенциально может стать экземплярным.
3. Таким образом, для обхода ограничений и противоречивости ООП, при работе над проектом приходится для каждой сущности городить огород — конструировать одну «метасущность» из нескольких ООП-сущностей, да еще придумывать какие-то структуры для расшаривания данных между объектами — экземплярами одного типа данных.
Об этом, и то том, чего бы хотелось взамен, я уже писал в другом отзыве.
Если вас не удовлетворяет мой ответ, то это связано с тем, что я являюсь специалистом по ООП и реляционным БД (а также моделированию предметной области в той части, где это можно сделать путем средствами ООП и реляционной модели), но не являюсь специалистом по теории множеств.
Поэтому ответы на вопросы, которые вы задаете, мне тоже были бы интересны.
Повторюсь, идея публикации в том, что работа с ООП и реляционными БД выявила их недостатки, связанные с моделированием предметной области или реализацией в коде/схеме БД уже имеющихся моделей, полученных от бизнес-аналитиков.
И поэтому вопрос
чем плохи или хороши механизмы ООП
имеет место быть.
Ответ на ваш вопрос дадут, видимо, специалисты по теории множеств, а мне как разработчику по-прежнему хотелось иметь такие средства и платформы разработки, которые нативным образом позволяли бы реализовывать «метод, основанный напрямую на аксиоматике Цермело-Френкеля» или любой другой, который вас устроит в части реализации поведения в теории множеств.
Мне кажется, в такой постановке вопроса и с спорить не о чем.
Мы же не пишем 100% кода на ассемблере или на процедурном C,
а используем объектные C++, Java, C# и т.д.
Почему бы не продвинуться вперед, и концепции и средства разработки не поднять на уровень еще выше — чтобы они соответствовали концепциям и средствам описания модели предметной области.
Здесь же я предложил обсудить вопросы моделирования, связанные с описанием сущностей и их признаков.
Но давайте попробует поговорить и о поведении:
Вы знаете, что поведение, которое в ООП наследуется, а также может перекрываться (полиморфизм), часто подвергается критике?
И есть такой подход, когда поведение не наследуется, наследования вообще как бы нет,
но каждый объект может реализовывать множество разных интерфейсов.
Такой подход реализован в т.ч. и в таком потенциальном кандидате на будущий мейнстрим, как Golang?
В этом случае у нас при моделировании предметной области снимаются сложные вопросы, связанные с реализацией поведение в части наследования и полиморфизма.
В общем, какое нужно, такое и добавляем поведение через интерфейсы.
Как вариант, да. Однако, пост о том, что хотелось бы реализаций этих продвинутых онтологий в мейнстриме уровня C#/Java/SQL Server — речь не о конкретных языках/СУБД, а об уровне мейнстрима.
Да, таблица «Машина» реализует именно перечень параметров (т.е. реализует аристолевский тип), но с помощью этой таблицы чаще всего моделируются и «Список машин», и «Машины».
Возможное взаимное непонимание как раз из-за путаницы терминов и может происходить.
Хотелось бы прокомментировать статью, действительно замечательную.
Вот только комментарий получился развернутым, поэтому я дал его в виде отдельной статьи: habrahabr.ru/post/249193/
Но ведь в любой (любой!) хорошей книжке по ООП написано, что класс это всего лишь тип данных, а не множество объектов!
Соответственно, если мы заводим статическое поле класса — характеристику именно типа данных, то если мы пытаемся использовать это поле как общие данные множества объектов, то мы используем инструмент не по назначению (пытаемся завивать гвозди кусачками) => куча проблем.
можно в любой книжке по ООП составлять главу «Примеры, как не надо делать».
Если у нас есть тип данных (класс в понятиях ООП) «Слон», то для полноценной реализации сущности предметной области нам нужно реализовать типы данных «Список слонов» и «Слоны», которые и будут разруливать общее кол-во слонов, их средний вес и т.д.
В случае, если мы заводим в одном типе данных «Слон» статические поля «общее кол-во», какие-то средние величины, то даже говорить не хочется что будет с вашими этими полями при работе с многопотоком, с сопровождением кода двумя-тремя и более «поколениями» программистов, и т.д.
Есть впечатление, что при том, что ООП сейчас явно находится в кризисе, если не в конце жизненного цикла (тут и от функциональных языков какие-то ожидания, и чуть ли не скриптовый Golang, по моему мнению, являющийся одним из кандидатов на новый мейнстрим),
так вот при этом, к сожалению, ООП за этот период так и не «взлетел», т.е. не использовался так, чтобы получить отдачу, от того, что вообще заложено в ОО-концепцию.
А жаль — инструмент очень красивый и мощный.
Именно это имелось в виду, просто торопился — хотел написать «экземпляры этих классов», потом понял, чтобы не было путаницы между терминами ООП и теорией множеств, нужно написать «экземпляры этих типов данных».
Кроме того, вы упомянули эти вещи как средства реализации теории множеств в ОО-программировании.
Но именно злоупотребление этими вещами не по назначению, приводит к куче проблем в отладке, к трудностям сопровождения кода, к торможению и завалу проектов и т.д.
Попробуем по пунктам:
1. Статические классы это не более чем «хелперы», содержащие несколько процедур (вычисляющих 2 + 2, например, т.е. не имеющие отношения ни к конкретному типу объектов, ни к предметной области в целом), которыми мы можем пользоваться там, где нам нужно что-то вычислить, и при этом мы не хотим заниматься копи-пастом.
Статические классы — это в чистом виде процедурное программирование (то, что несколько процедур оборачиваются в отдельный статический класс, экземпляр которого нельзя создать — чистая условность, т.к. многие большинство ОО-языков не позволяют объявить процедуру вне класса — и это правильно).
Относить процедурное программирование к теории множеств перебор, иначе бы те, кого не устраивает противоречивость ООП, просто пользовались бы процедурным программированием.
2. Что же касается статических элементов нестатического класса (поля, методы), то это очень опасный инструмент — но это необходимое зло.
К теории множеств это не имеет не малейшего отношение. Назначение таких элементов чисто техническое.
Полагаю, если бы не необходимость реализации экземплярного конструктора — технически в виде статического метода — то не было бы в чистом ООП статических методов и полей в нестатических классах.
Не говорю уж таких вещах, как «статические методы» и «методы класса», которые оба являются неэкземплярными (в Delphi language есть такое) — не думаю, что стоит пытаться реализовывать теорию множеств, полагаясь на такие сугубо технические вещи.
Идея ООП в том, что есть тип данных, и экземпляры этих данных.
«Расшаривание» между экземплярами неких данных (полей) на уровне именно класса, а не специальных структур — отдельных объектов (экземпляров других классов), приводит к гарантированному завалу кода и проекта (тут и проблемы при многопоточности, и внезапное изменение данных другим экземпляром и т.д.).
Использование статических методов в нестатических классах — тоже опасная вещь, и лучше выносить их в хеплер (статический класс),
т.к. наличие в нестатическом классе статического метода имеет подводный камень:
что если, в будущем этот метод все же начнет пользоваться экземплярными данными класса (состоянием объекта)? придется объявлять метод экземплярным, а ведь есть уже куча кода, которая его вызывает и считает статическим; если вы четко видите, что метод не вынести в хелпер, значит, понимаете, что метод неразрывно связан с классом и потенциально может стать экземплярным.
3. Таким образом, для обхода ограничений и противоречивости ООП, при работе над проектом приходится для каждой сущности городить огород — конструировать одну «метасущность» из нескольких ООП-сущностей, да еще придумывать какие-то структуры для расшаривания данных между объектами — экземплярами одного типа данных.
Об этом, и то том, чего бы хотелось взамен, я уже писал в другом отзыве.
Поэтому ответы на вопросы, которые вы задаете, мне тоже были бы интересны.
Повторюсь, идея публикации в том, что работа с ООП и реляционными БД выявила их недостатки, связанные с моделированием предметной области или реализацией в коде/схеме БД уже имеющихся моделей, полученных от бизнес-аналитиков.
И поэтому вопрос имеет место быть.
Ответ на ваш вопрос дадут, видимо, специалисты по теории множеств, а мне как разработчику по-прежнему хотелось иметь такие средства и платформы разработки, которые нативным образом позволяли бы реализовывать «метод, основанный напрямую на аксиоматике Цермело-Френкеля» или любой другой, который вас устроит в части реализации поведения в теории множеств.
Вот и я об этом же habrahabr.ru/post/249193/
Мне кажется, в такой постановке вопроса и с спорить не о чем.
Мы же не пишем 100% кода на ассемблере или на процедурном C,
а используем объектные C++, Java, C# и т.д.
Почему бы не продвинуться вперед, и концепции и средства разработки не поднять на уровень еще выше — чтобы они соответствовали концепциям и средствам описания модели предметной области.
Здесь же я предложил обсудить вопросы моделирования, связанные с описанием сущностей и их признаков.
Но давайте попробует поговорить и о поведении:
Вы знаете, что поведение, которое в ООП наследуется, а также может перекрываться (полиморфизм), часто подвергается критике?
И есть такой подход, когда поведение не наследуется, наследования вообще как бы нет,
но каждый объект может реализовывать множество разных интерфейсов.
Такой подход реализован в т.ч. и в таком потенциальном кандидате на будущий мейнстрим, как Golang?
В этом случае у нас при моделировании предметной области снимаются сложные вопросы, связанные с реализацией поведение в части наследования и полиморфизма.
В общем, какое нужно, такое и добавляем поведение через интерфейсы.
Возможное взаимное непонимание как раз из-за путаницы терминов и может происходить.
Вот только комментарий получился развернутым, поэтому я дал его в виде отдельной статьи:
habrahabr.ru/post/249193/