допустим ситуация такая, вам надо хранить массив координат в базе данных
пары (x, y) потом, вдруг решили, что большинству запросов проще работать с (угол, расстояние) какую дисциплину в коде вы будете поддерживать, чтобы такой переход был безболезненный.
>>В текущем классе уже ничего подменить нельзя. Вот он код класса — написан. Можно в наследнике сделать по-другому. Ну, значит в наследнике будет все хорошо, а в родителе как было плохо, так и остается.
я имею ввиду класс CurrentUser — getter же его? Мы можем изменить реализацию getName в классе CurrentUser не трогая функцию SendMail
> Это и есть инкапсуляция — реализация изолирована от интерфейса
>>> Инкапсуляция — это скрытие реализации от пользователя. В данном случае реализация фактически открыта. Сам по себе факт отделения реализации от интерфейса не означает инкапсуляцию. Например, в C файл интерфейса функций можно отделить от имплементации. Тем не менее, все данные лежат снаружи.
В файле интерфейса C будет декларирована структура user. И код SendMail не будет гарантирован от залезания туда.
>>>Я также не знаю, как правильно декомпозировать функционал. В Python или C++, если мне нужна была маленькая функция для преобразования строки в число, я просто писал её в конце файла. В Java или C# я вынужден выносить её в отдельный класс StringUtils.
ОО способ — добавить ToNumber в string. См смолток и extension methods в C#
>>>В недо-ОО-языках я мог объявить ad hoc обёртку для возврата двух значений из функции (снятую сумму и остаток на счету). В ООП языках мне придётся создать полноценный класс РезультатТранзакции.
Непонятно почему добавление простого класса это плохо. Анонимные типы не противоречат ООП.
>>>И для нового человека на проекте (или даже меня самого через неделю) этот класс будет выглядеть точно таким же важным и фундаментальным в архитектуре системы. 150 файлов, и все одинаково важные и фундаментальные — о да, прозрачная архитектура, прекрасные уровни абстракции.
>>> Я не умею писать эффективные программы. Эффективные программы используют мало памяти — иначе сборщик мусора будет постоянно тормозить выполнение. Но чтобы совершить простейшую операцию в объектно-ориентированных языках приходится создавать дюжину объектов.
>>>Чтобы сделать один HTTP запрос мне нужно создать объект типа URL, затем объект типа HttpConnection, затем объект типа Request… ну, вы поняли.
Пробовали ли вы подсчитать, сколько байтов занимает каждый такой объект?
>>>В процедурном программировании я бы просто вызвал несколько процедур, передав им созданную на стеке структуру. Скорее всего, в памяти был бы создан всего один объект — для хранения результата. В ООП мне приходится засорять память постоянно.
>>>То что foo.getName() лучше foo.name — с этим никто не спорит
я специально выделил слово ничем в предыдущем сообщении, чтобы показать, что спорит.
>>> Потому что в контексте принципа инкапсуляции наличие геттеров и сеттеров для поля равносильно открытию поля
Соответственно неравносильно. Геттер вводит абстракцию свойства мы можем подменить его реализацию, как хотим. Это и есть инкапсуляция — реализация изолирована от интерфейса. То, что пока капсулоа одноместная ничего не меняет.
А я пользуюсь постоянно — переключил язык поиска на английский и теперь там американское спецприложение, а не яндекс.Если надо быстро что-то найти в инете или поискать по штрихкоду (попробуйте, наример, просканировать штрихкод пачки макарон). Правда у меня в основном такой юзкейз: объясняю ребенку про гидросамолеты и иллюстрирую картинками из поиска Бинга.
Он синхронизирует контакты не с дескктопом, а с онлайн сервисами — так что через гмыл и хотмыл можете синхронизироваться с о всем софтом, который синхронизируется с ними. Вот медиа придется через зюн или маковскую приблуду.
пары (x, y) потом, вдруг решили, что большинству запросов проще работать с (угол, расстояние) какую дисциплину в коде вы будете поддерживать, чтобы такой переход был безболезненный.
Этим круто ООП
>>>Что показать? саму фигуру? допустим. Где? На экране, на какой-то канве? Еще где-то?
В данном примере, не важно.
я имею ввиду класс CurrentUser — getter же его? Мы можем изменить реализацию getName в классе CurrentUser не трогая функцию SendMail
> Это и есть инкапсуляция — реализация изолирована от интерфейса
>>> Инкапсуляция — это скрытие реализации от пользователя. В данном случае реализация фактически открыта. Сам по себе факт отделения реализации от интерфейса не означает инкапсуляцию. Например, в C файл интерфейса функций можно отделить от имплементации. Тем не менее, все данные лежат снаружи.
В файле интерфейса C будет декларирована структура user. И код SendMail не будет гарантирован от залезания туда.
Либо будет ООП реализованное библиотекой C
ОО способ — добавить ToNumber в string. См смолток и extension methods в C#
>>>В недо-ОО-языках я мог объявить ad hoc обёртку для возврата двух значений из функции (снятую сумму и остаток на счету). В ООП языках мне придётся создать полноценный класс РезультатТранзакции.
Непонятно почему добавление простого класса это плохо. Анонимные типы не противоречат ООП.
>>>И для нового человека на проекте (или даже меня самого через неделю) этот класс будет выглядеть точно таким же важным и фундаментальным в архитектуре системы. 150 файлов, и все одинаково важные и фундаментальные — о да, прозрачная архитектура, прекрасные уровни абстракции.
>>> Я не умею писать эффективные программы. Эффективные программы используют мало памяти — иначе сборщик мусора будет постоянно тормозить выполнение. Но чтобы совершить простейшую операцию в объектно-ориентированных языках приходится создавать дюжину объектов.
>>>Чтобы сделать один HTTP запрос мне нужно создать объект типа URL, затем объект типа HttpConnection, затем объект типа Request… ну, вы поняли.
Пробовали ли вы подсчитать, сколько байтов занимает каждый такой объект?
>>>В процедурном программировании я бы просто вызвал несколько процедур, передав им созданную на стеке структуру. Скорее всего, в памяти был бы создан всего один объект — для хранения результата. В ООП мне приходится засорять память постоянно.
Стек — это тоже память.
я специально выделил слово ничем в предыдущем сообщении, чтобы показать, что спорит.
>>> Потому что в контексте принципа инкапсуляции наличие геттеров и сеттеров для поля равносильно открытию поля
Соответственно неравносильно. Геттер вводит абстракцию свойства мы можем подменить его реализацию, как хотим. Это и есть инкапсуляция — реализация изолирована от интерфейса. То, что пока капсулоа одноместная ничего не меняет.
В одной из редакций UML notation guide я видел разделение наследования и обобщения, каковое показалось мне полезным.
По памяти — наследование — это передача неких свойств от одного к другому, а обобщение, отношение между частным и общим.
Соответственно, обобщение сопровождается наследованием. Как и создание объекта по прототипу.
См разъяснение в доке про язык self www.selflanguage.org/_static/published/parents-shared-parts.pdf
оно лучше тем, что резализацию getName можно подменить не меняя вызывающий код. Корявая абстракция лучше чем никакой.
Предположим решили, не хранить name в Person, а хранить историю изменения имени и получать текущее значение на лету?
Насколько я понял, не говорили что этой возможностью исчерпываются все фичи 7.8 просто это то, что пока обещают.
Не понял. Если имеется ввиду комменты, то просто достаточно знать синаксис и команду help.
Например, наберите щас в павершелле help ls или help %.
Про баш, не знаю прокомментировать не могу