Станислав Макаров

Все советуют вам Книгу Дракона. Книга, безусловно, отличная и классическая, но я что-то по вашему вопросу сомневаюсь, что вам нужно именно это - реализация и механика/синтаксис языков. Попробуйте Programming Language Pragmatics - мне кажется там ответы на ваши вопросы.

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

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

В C++ и C# есть классовое ООП, соединённое с номинативной стратегией типизации. В JS и Lua есть прототипное ООП, которое в TypeScript приправляется структурной типизацией. В Rust по сути нет наследования, но есть полиморфизм. В Ruby есть концепция метаклассов, которая не особо известна в других языках. Все делают по-своему, говорить, что в каком-то языке "истинное" ООП - глупо, потому что об этом нет договорённости.

Исторически есть две крупные "школы" ООП - школа языка SIMULA и школа языка Smalltalk, вот можете почитать об этом. К этим школам добавляется ещё прототипный подход, который впервые появился в языке Self, джаваскрипт тут Америку миру не открыл. История языков программирования вообще очень длинная и интересная штука, большинство идей в современных промышленных языках были изобретены значительно ранее в других языках, экспериментальных или академических.

JS как язык отвратителен не потому, что в нём "ненастоящее" ООП, а совсем по другим причинам.

с вашей идееологией интересно(с которой я согласен), как вы относитесь к тсу?

Вы спросили не у меня, но позволю себе ответить - TypeScript это лучшее, что было с JS, потому что он делает программирование на JS возможным. Обратите внимание - с точки зрения ООП тайпскрипт ничего нового не вносит, так что на мой взгляд дело вообще не в ООП. А например в том, что в JS никак бл..ь не доедут записи. Как можно в 2023 году программировать на языке без таких элементарных вещей? За что нам такое наказание?

Какова роль интерфейсов в ООП?
В чем суть интерфейсов в программировании?

ReturnType

Появилось требование - изменить формат некоторых отчетов на CSV.

А кто сказал, что может появиться такое требование? Вернее, что вы сможете его удовлетворить без изменения контракта?

Ведь у вас какой контракт? Что метод MakeReport возвращает html-отчёт? Так как же вы вообще сможете реализовать возврат CSV, не поменяв контракт?

А вот если вы таки поменяете контракт, например скажете что "MakeReport возвращает поток (текстовый или двоичный) конечного размера", то тогда генерация и возврат CSV вполне себе лягут в такой контракт. Конечно, такой контракт уже будет куда более общим - даже тестировать в нём будет особого нечего (кроме того что отчёт вообще сгенерировался и имеет ненулевую длину).

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

Всё просто, не так ли?

Принцип подстановки говорит - я поставлю рамки, ограничения (т.е. контракт), и все экземпляры подклассов должны ему удовлетворять. Полиморфизм говорит - отлично, значит у нас возможность определить СПЕЦИФИЧНОЕ поведение, которое может отличаться от других специфичных поведений, но при этом все они будут делать что-то вполне ожидаемое и ЗАРАНЕЕ ОГОВОРЕННОЕ.

Сам факт того, что вы составляете СОГЛАШЕНИЯ, выполнения которых ожидают клиенты класса, даёт вам право ВО ВСЕХ ОСТАЛЬНЫХ аспектах вести себя КАК ВАМ ВЗДУМАЕТСЯ (ну я немного преувеличил, но суть такова) в каждом из подклассов.

Ваш getNode будет работать некорректно, т.к. каждый раз будет перезаписываться в прототипе при создании нового объекта. Т.е. при вызове getNode для любого объекта Timer всегда будет извлекаться значение одной и той же переменной - захваченной при последнем создании объекта.

Более правильная реализация:
https://developer.mozilla.org/en-US/docs/Web/JavaS... , Emulating private methods with closures

проблема у такого подхода - всё это делается ценой рантайма - на каждый объект будут свои инстансы методов. Хотите нормальную инкапсуляцию? Берите TypeScript.

А почему вы по умолчанию public не ставите, если выбираете между public и private? Наверное потому что вам инкапсуляция нужна?

Ситуация с дочерними классами ничем не отличается. Не стоит делать метод protected по умолчанию по той же причине, по которой его не стоит делать public по умолчанию.

По-моему зависимости внутри системы от интерфейсов более гибкие.

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

LoggerInterface

В каждом ОО-языке свои конвенции именования интерфейсов, но скорее всего лучше назвать просто Logger. Вы же не пишете Class в конце имени каждого класса.

Подскажите, пожалуйста, как правильно определить когда использовать интерфейс и когда абстрактный класс?

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

Не совсем понятно, чего вы хотите. Вернее, чего хотите - понятно, непонятно - почему.

Если вы хотите абсолютно все методы делегировать к инстансу IR - то почему бы вам просто не возвращать инстанс IR через интерфейс I из объекта A - зачем самому A реализовывать I?

Если же посредничество A все-таки необходимо, то значит, что вы хотите дать этому какую-то смысловую нагрузку. Т.е. раз вам хочется, чтобы A сам реализовал I, то значит вам хочется, чтобы он скрывал факт того, что вызовы на самом деле делегируются к инстансу IR.

Раз вы хотите, чтобы факт делегирования скрывался от клиента класса A, то вероятно, со временем, вы захотите поменять логику делегирования, и делегировать, например, не к IR, а к другой реализации интерфейса I (иначе зачем вам такое сокрытие факта делегирования к IR). А раз так, то вполне логично, что вы должны явно реализовать методы, делегирующие себя к методам IR.

К чему я это всё? Конечно, можно себе представить, что код делегирования генерируется автоматически на основе конструкции вроде вашей (implements I by delegate), однако: а) это довольно частный случай, чтобы добавлять в язык синтаксический сахар для этого, плюс наверняка возникнет ряд вопросов реализации, на которые не будет однозначного ответа; б) я думаю такое реализуемо в языках с мощными макросами, но мне приходят в голову только те, которые вы врядли будете использовать, например Nemerle или Lisp. А, ну и на препроцессоре C++ такое можно сделать.

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

Подкласс нужно создавать тогда, когда у вас есть дополнительная логика что называется для конкретных случаев. По вашему примеру, если Magick - это класс всяких магов, то подкласс водяных магов может определять свой magick, который он умеет кастовать. Ну или образовывать более конкретную, "водяную" магию.

Второй вариант подразумевает, что магия может полностью задаваться извне, и Magick только кастит её, но в её "формировании" не участвует.

Сейчас вы не решили для себя, что такое Magick. Вам нужно это сделать, и вопрос отпадёт сам собой.

А вы по какому признаку хотите классифицировать? Я вот могу назвать такую архитектуру клиент-серверной, а еще многослойной.
Какие альтернативы? Ну, во-первых сам WCF может быть очень разный, и SOAP, и REST. Во-вторых, некоторые клиенты (например, административного характера) могут цепляться напрямую к базе (к примеру, они имеют доступ к серверу по VPN), и тогда веб-сервиса между БД и клиентом нет.
Также, приложение может работать не сразу со веб-сервисом/БД, а к примеру складировать данные в локальную базу (какой-нибудь SQLite), а потом её синхронизировать с основной БД - также через сервис или напрямую (зависит от доверия к клиентскому приложению) - это сложнее с точки зрения наладки всего процесса, но иногда просто необходимо, если связь с центральным сервером БД не гарантирована (иногда приложения на мобильных устройствах должны работать и вне большого города и толстого 4G канала).

WCF-служба может пользоваться ORM или программист может заранее составить все SQL-запросы.
WCF-служба может хоститься и на IIS, если это удобно. Хотя, если она выполняет в БД фоновые операции, то вполне правильно и логично хостить её в Виндовом сервисе.

Каждый из перечисленных вами слоёв можно поменять/убрать/упростить/усложнить. А еще, например, можно вспомнить про многопользовательскую работу и возможные проблемы при работе разных людей с одними и теми же данными, что тоже повлияет почти на все слои в вашей схеме.

Вас что конкретно интересует? Нужно хотя бы говорить о клиенте или сервисе отдельно, т.к. это сами по себе крупные компоненты со своей архитектурой.

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D...

ru.stackoverflow.com/questions/41844/%D0%97%D0%B0%...

Во-первых вам нужно ОЧЕНЬ ЧЕТКО понять принципиальную разницу между терминами "WCF service" и "windows service", т.к. общего между ними немного. Первое это про веб-сервисы, второе - это тоже что и демоны в *nix-системах. Первое это про архитектуру распределенной системы, второе это про жизненный цикл программы (как, когда и кем запускается/останавливается).

Поэтому:
1) если разработка под Винду, и

"служба должна выполнять в фоне некоторые действия с бд"

то почитайте про Windows Service - на шарпе такие пишутся относительно просто. Это не единственный способ запустить процесс, который будет крутиться и сам что-то делать в базе, но он предпочтителен.
2) если взаимодействие с клиентом подразумевается не по самодельному протоколу, а например по HTTP, то вам срочно нужно ознакомиться с тем, что такое веб-сервисы/веб-API и какие они бывают. Если вы уже понимаете что это такое, то вам нужно выбрать способ реализации под Дотнетом.

Подскажите, это можно сделать в рамках одной службы или нет?

Если под службой понимается Windows-служба, то можно. Стоит ли - другой вопрос, зависит от тех действий, которые вы хотите выполнять в фоне, архитектуры БД и политики работы с ней.