Private секции дат гарантию того, что клиент класса будет пользоваться интерфейсом абстрактно от внутреннего представления этого класса. А это дает определенные преимущества, например гарантию проверки всех инвариантов + адаптация к изменениям. Зачем же их отменять?
Задача правильно выделить свойства абстракции кладется на девелопера. Конечно, было бы неплохо, чтобы компилятор проверял корректность отношения свойства к некотор сущности… Никаких противоречий в ООП нет. То, что компилятор не запрещает ситуации из серии «а создам-ка я статическое поле Общее по слонам в классе Слон» — не есть проблема ООП. Если противоречие и возникает, то это скорее всего неверно выделены свойства сущности при абстрагировании.
А вот отсюда на первый взгляд следует, что у класса «Слон» можно завести поле «Общее число слонов»?
На мой взгляд — нет.
Да, это я имел ввиду — нельзя завести такое поля. Точнее выражаясь, технически завести-то можно, а логически нет.
Для класса Слон статического поля общее по слонам не должно быть, так как просто-напросто такого свойства у слона быть не может.
Статическое поле — это поле, назначение которого заключается в обеспечении наличия единого значения для всех экземпляров класса. Но стоит заметить, что статическое поле — это тоже свойство экземпляра класса, что следует из определения класса (совокупность объектов, которым присущи некоторые описанные классом характеристики). Отсюда, статическое поле «среднее по слонам» в классе Слон не должно быть, так как не является свойством экземпляра класса (среднее по слонам логически не может быть свойством объекта слон).
В ООП все понятия четко определены:
Класс — множество объектов, которым присущи свойства, описанные этим классом.
Экземпляр — сущность, которая обладает свойствами, описанными классом.
Но к ValueTypes относятся структуры. А структуры как раз и описывают свойства, присущие определению типа данных, а именно — операции, внутреннее представление, занимаемая память. Ну, операции структура не описывает, точнее сказать операции описываются относительно структуры, ну т.е. у экземпляра этой структуры нет поведения как такового.
Взять даже тот же int, опишем его:
Тип данных: int;
Свойства: (Операции: сложение, умножение и т.д. | Внутреннее представление — набор битов (причем это скрыто от пользователя этого типа, а значит int можно считать абстрактным типом данных | Занимаемая память — зависит от разрядности целевой машины).
1) По-моему, автор статьи все усложняет. Есть уже устоявшиеся термины в ООП, смысл которых всем известен.
Класс — набор объектов, обладающих общими характеристиками. Класс описывает свойства (присущие типу данных конечно же, а это: интерфейс, внутреннее представление, занимаемая память), присущие каждой сущности, относящиеся к данному классу.
Экземпляр класса — некая сущность из множества всех сущностей, относящихся к некоторому классу.
Насчет интернациональности команды — если разработчик видит выражение:
Date date = new Date(1, 2, 3);
то он скорее всего непременно обратится к документации, так как знает, что если результат выполнения некоторого кода можно трактовать двояко, то лучше обратиться к документации. Там все аспекты работы этого кода должны быть описаны.
Что-то мне кажется, все предложенные варианты по добавлению функциональности «именованные параметры в C++» — это оверкиллы. Если параметров много и действительно можно запутаться в том, какое значение какому параметру предоставлять или есть еще куча каких-то optional-параметров, то можно воспользоваться Builder + Fluent interface. Ели параметров мало, но все еще можно запутаться, то быть может имеет смысл документировать метод относительно его параметров.
Погодите. Как альтернатива — можно использовать паттерн Builder с Fluent Interface. Но быть может это оверкил/обходной путь, т.к задача Builder совсем другая. Но все же. Что вы думаете?
А GitHub все-таки молодец… Поражает внимание к аудитории пользователей, являющихся студентами. Воспользовался возможностью получить Micro-аккаунт, теперь предоставили GitHub Student Developer Pack.
Просто волна инноваций: Windows 10, OSX Yosemite, iOS 8, Android L, iWatch, новый электромобиль от Tesla. Приятно живется в наше время :) Огорчил лишь Роскомнадзор, внеся Хабр в реестр.
Ростелеком МСК, GitHub загружается нормально. Будет очень нехорошо, если GitHub перестанет открываться и на Ростелекоме. Проекты же все там… Ну и зачем бы Роскомнадзору понадобилось вносить GitHub в единый реестр?
А вот отсюда на первый взгляд следует, что у класса «Слон» можно завести поле «Общее число слонов»?
На мой взгляд — нет.
Да, это я имел ввиду — нельзя завести такое поля. Точнее выражаясь, технически завести-то можно, а логически нет.
Для класса Слон статического поля общее по слонам не должно быть, так как просто-напросто такого свойства у слона быть не может.
В ООП все понятия четко определены:
Класс — множество объектов, которым присущи свойства, описанные этим классом.
Экземпляр — сущность, которая обладает свойствами, описанными классом.
P.S. прошу прощения, не в ту ветку ответил
Взять даже тот же int, опишем его:
Тип данных: int;
Свойства: (Операции: сложение, умножение и т.д. | Внутреннее представление — набор битов (причем это скрыто от пользователя этого типа, а значит int можно считать абстрактным типом данных | Занимаемая память — зависит от разрядности целевой машины).
Класс — набор объектов, обладающих общими характеристиками. Класс описывает свойства (присущие типу данных конечно же, а это: интерфейс, внутреннее представление, занимаемая память), присущие каждой сущности, относящиеся к данному классу.
Экземпляр класса — некая сущность из множества всех сущностей, относящихся к некоторому классу.
Date date = new Date(1, 2, 3);
то он скорее всего непременно обратится к документации, так как знает, что если результат выполнения некоторого кода можно трактовать двояко, то лучше обратиться к документации. Там все аспекты работы этого кода должны быть описаны.