Комментарии 26
Это какой-то прикол? )
Если статья понравиться, то я буду писать продолжение в будущем.
Не стóит.
Как-бы, если мы хотим в нормальном ООП языке выполнить http запрос, то это будет выглядеть как-то так:
println(«www.google.com».toURL().text)
и все. Это груви, если что. Вот тут все как раз инкапсулировано — строка «www.google.com» умеет toURL(), а уже объект URL имеет метод getText() (который в груви можно записать просто как .text), и этот метод уже получает результат запроса.
А тут написано строк 50 какой-то хрени, которая заканчивается conn.setDoOutput(true), а собственно выполнения http запроса в этом коде нет.
Ну то есть, я написал в своей жизни десятки наверное http клиентов, и кучу подобного кода — но этот код просто какая-то непонятная ненужная фигня, которая делает вообще не то, что нужно. Как выполнить http запрос в java? Вот например, нормальная инструкция, и она совсем не об этом.
https — это ведь тоже не о том, чтобы поменять несколько буковок в URL. Это о том, что бывают разные методы шифрования, сертификаты, и т.п., с которым нужно работать. А тут мы что видим, каст к HttpsUrlConnection, и все?
P.S. Ну и русский язык тот еще… про тся/ться уже намекнули, но и остальное не лучше.
Возможно потому, что приведенный пример — это не совсем ООП. Например, одна из задач ООП — инкапсуляция деталей от клиентского кода, клиенский код должен зависеть от абстракций и ничего не знать о подклассах. А здесь — знает, поэтому код выглядит сложным, и преимущества ООП непонятны. Инстанцирование подклассов нужно прятать от клиента в фабрике (паттерн Фабричный Метод). Про ООП нельзя рассказывать без описания паттернов, принципов типа SOLID и т.д.
Ну и ряд других ошибок есть, которые скорее дискредитируют ООП.
Сишную часть оценить не могу, не разбираюсь в процедурном программировании, может кто сделает. Тогда будет понятно, поедставляет ли она интерес.
в c файлах переменные являются глобальными (тоже что и static внутри объекта). Поэтому работать с большим числом структур conn чем 1 вряд-ли получится.
Чтобы этого избежать, нужно вносить все переменные внутрь структур. Придется изобретать полиморфизм в СИ. Но зачем?
В с++ происходит в точности тоже самое, но более красиво
// headers
struct conn {
void ( *connect ) ( const char *url );
char *( *read ) ( void );
};
struct conn_http {
// анонимная структура позволяет обращаться к ее полям, какбудто они есть в родительской структуре.
struct conn;
int sockfd;
};
struct conn_https {
struct conn;
int sockfd;
SSL *ssl;
};
// http.c
struct conn_http* init_http () {
struct conn_http* self = zalloc(sizeof(struct conn_http));
if (self)
{
conn->connect = connect_http;
conn->read = read_http;
}
return self;
}
// https.c
struct conn_https* init_https () {
struct conn_https* self = zalloc(sizeof(struct conn_https));
if (self)
{
conn->connect = connect_https;
conn->read = read_https;
}
return self;
}
// main.c
struct conn* conn;
int main ( int argc, char **argv ) {
// кастовать к "базовой структуре" не противозаконно, ее смещение внутри наследника равно 0
switch ( get_protocol ( ) ) {
case HTTP_PROTOCOL: conn = (struct conn*)init_http (); break;
case HTTPS_PROTOCOL: conn = (struct conn*)init_https (); break;
case ERROR_PROTOCOL: return -1;
}
conn->connect ( "www.google.com" );
char *data = conn->read ( );
free(conn);
}
Про ООП нельзя рассказывать без описания паттернов, принципов типа SOLID и т.д.
Как по мне, про ООП нужно рассказывать без описания паттернов, принципов типа SOLID и т.д., потому как ООП — это совсем не про паттерны и не про SOLID, и объединение их в одной теме, это грубое нарушение Single Responsibility Principle :)
Но лично мне сам подход «Пока я ещё наверное плохо знаю ООП, поэтому держите от меня статью по ООП» крайне не нравится. Не надо писать про то, что плохо знаешь.
Как по мне, про ООП нужно рассказывать без описания паттернов, принципов типа SOLID и т.д., потому как ООП — это совсем не про паттерны и не про SOLID
А что бы вы тогда включили в краткий курс по ООП?
ООП — это же именно методология, а не синтаксис. Эти принципы входят в ООП изначально, а паттерны — это примеры их правильного применения.
А SOLID — это даже не методология. Это набор best practices, выработанный за пару десятилетий использования ООП. Преподавать их надо, но уже тогда, когда человек ООП владеет, и значит, способен понять, зачем ему эти практики, и какие сложности в организации разработки могут быть без них.
Если до конца следовать логике исторического развития ООП, тогда наследование и полиморфизм тоже не следует изучать, потому что Алан Кэй не закладывал их в первоначальную концепцию ООП.
Ещё кстати стоит добавить к базовым принцип абстракции.
А что вы понимаете, скажем, под принципом полиморфизма? Как вы его сформулируете студентам без отсылок к SOLID, GRASP и паттернам?
Если до конца следовать логике исторического развития ООП, тогда наследование и полиморфизм тоже не следует изучать,
Да я же не следую логике исторического развития ООП. Я просто отделяю базовые принципы от рекомендаций, суть которых понятна только при наличии практики, а в противном случае их надо было бы зубрить, не включая мозги :) И ладно ещё если речь идет о Single Responsibility, а попробуйте в рамках курса ООП объяснить студентам, которые несколько занятий назад понятие класса не знали, какую проблему решает IoC. Не зазубрить, дескать, делайте вот так, а именно понять, почему делать вот так, и какие проблемы будут в противном случае. Особенно в свете того, что на всех учебных примерах, которые они могли там писать в рамках учебного курса, как раз IoC был совершенно не к месту, и проблемы только бы создавал, а не решал.
А что вы понимаете, скажем, под принципом полиморфизма? Как вы его сформулируете студентам без отсылок к SOLID, GRASP и паттернам?
Полиморфизм для новичков лучше всего показывается практическим примером, обычно на создании UI. Когда есть какой-то базовый класс, описывающий общее поведение виджета на форме, а в дочерних классах определяется его поведение и внешний вид.
Паттерны — это прежде всего единые наименования для популярных решений. Многие из паттернов — способ обхода недостатков тех или иных языков. Например, с проникновение элементов ФП в ООП языки всё реже нужно имплементировать паттерны стратегия, можно просто колбэк передвть
А если стратегия stateful и поэтому у неё много методов, коллбэк справится? Или метод один, но кода на тысячу строк — так, что без разбивки на приватные методы код лямбды будет выглядеть как огромная простыня непонятного текста?
Насчёт stateful я сморозил, у стратегии не должно быть бизнесового состояния, иначе это уже другой тип сущности. Но сути вопроса это не меняет: как функциональный подход инкапсулипует полиморфные сущности с состоянием и множеством методов?
А я где-то подобное утверждал? )
Мой тезис в том, что многие паттерны в популярных ООП ЯП нужны лишь потому, что эти ЯП стандартных и удобных средств решения этих задач не дают. Грубо говоря, могло бы быть ключевое слово singleton и не нужно было бы этого паттерна с приватным конструктором, методом getInstance и т. п.
Состояние инкапсулируется через замыкания.
ООП — это если есть сущность с именем, и её можно неким образом беспокоить через предоставленные сущностью(этой или другой) инструменты. Структурное программирование — не потому что структуры используются, а потому что структура программы прослеживается. Программа состоит из меньших блоков, взаимодействующих между собой. Обычно, блоками являются процедуры и функции. При логическом развитии идеи блоков до структур данных, операций над ними, и некоторой(к слову необязательной) компоновки их между собой появляется ООП. Развитие ООП до состояния, где данных как отдельных сущностей внутри программы не существуют, а остались только функции, оперирующие друг другом и внешним вводом — получили функциональное программирование.
Язык не причем. ООП на С -> GLib и Gstreamer. структурное программирование -> С++ без использования RAII, функциональщина в Java -> Rx и декораторы.
Развитие ООП до состояния, где данных как отдельных сущностей внутри программы не существуют, а остались только функции, оперирующие друг другом и внешним вводом — получили функциональное программирование.
Не согласен. Взять Haskell или Erlang, там есть данные как отдельные сущности.
ФП — это когда функции являются First-Class Citizens, функции — чистые, и иммутабельность преобладает.
Но этот способ конечно же придумал не я, я его сам вычитал из книги когда-то. И так https и http. Чтобы это сделать, нужно создать интерфейс. И к этому интерфейсу присваивать нужный класс, в зависимости от типа протокола. Я точно не помню, но вроде я где-то читал, что ООП вправляет мозги. Что это позволяет писать грамотный красивый код. Возможно так.
Вся статья выглядит как один большой несвязный кусок текста. Нет никакой структуры, никакого «газетного» стиля. После прочтения я понял только то, какой беспорядок происходил у автора в голове на момент написания этого «сочинения».
Вступление. Основная тема. Выводы.
Где это все?
Выбор языков для профориентиации начинающих программистов — ява и си?!
Ну нафиг, пардон май френч.
Си с его препроцессором, куцей системой типов, правом на ношение огнестрельного оружия и стрельбу в ногу.
Ява с её КоролевствомСуществительных.
Два, наверное, лучших языка для демотивации.
Да, промышленные стандарты, но.
Структурное против ООП программирование