powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Объектно-ориентированный vs хакерский подход к программированию
75 сообщений из 75, показаны все 3 страниц
Объектно-ориентированный vs хакерский подход к программированию
    #34176108
Нашел статью, в которой описывается разница между объектно-ориентированным, процедурным и "хакерским" подходами на примере одной задачи. Объектно-ориентированный подход явно уступает остальным по объему кода, в т.ч. "пустого" boilerplate кода. Т.е. он заведомо хуже. Так какие доводы можно привести в его пользу?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176121
Статья http://csis.pace.edu/%7Ebergin/patterns/ppoop.html собственно. Ссылку забыл вставить :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176132
smbdy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
бред
никаких доводов не нужно
кому нужно тот сам поймёт / прочитает / разбереца / etc
тебе в раздел флейма
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176138
Фотография Ruslan.Isbarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Времена, когда люди боролись за лишний байт памяти прошли (относится только к прикладному программингу). ИМХО страдать такой фигней сейчас не нужно, лучше сосредоточиться на других вещах, например архитектура. Не стоит обходить такие вещи как удобочитаемость, рано ли поздно придется заниматься сопровождением, добавлять функционал.
Более того, в наше время весь софт пишется в сжатые сроки. ООП позволяет делать это быстрее.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176149
Ruslan.IsbarovБолее того, в наше время весь софт пишется в сжатые сроки. ООП позволяет делать это быстрее.Это в какие? Всегда интересовало. Вот например TheBat! ты за сколько времени напишешь?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176159
Фотография Ruslan.Isbarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжить Ruslan.IsbarovБолее того, в наше время весь софт пишется в сжатые сроки. ООП позволяет делать это быстрее.Это в какие? Всегда интересовало. Вот например TheBat! ты за сколько времени напишешь?

Неважно за сколько я его напишу. Важно сколько начальство поставит. Я уверен, разработчики TheBat! не маялись фигней дабы сделать вид что работают... Вот тебе встречный вопрос: как думаешь, сколько проектов в наше время укладываются в сроки поставленные менеджерами проектов (или лицами занимающимися оценкой рисков и сроков)? По статистике, в процентах.

P.S. Неважно какой проект, краткосрочный, среднесрочный или долгосрочный, времени всегда мало. Лишний день факапа - убытки для компании, подбитая репутация в лице заказчиков и прочие неприятности.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176162
mysterio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Подписываюсь под каждым словом.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176186
Фотография Ruslan.Isbarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, приведу пример из области системного программирования. Вот замечательная OpenSource операционная система реального времени http://ecos.sourceware.org/ (либо http://sources.redhat.com/ecos/ ) (Embedded Configurable Operating System), разрабатываемая компанией Cygwin (входит в RedHat).
В этой системе только HAL (Hardware Abstraction Level) написан на языках низкого уровня (Assembler'ы) (HAL пишется для конкретного процессора и периферии, содержащейся в нем). Все остальное - планировщик, графическая оболочка, драйверы файловых систем и прочее-прочее пишется на C++, с использованием ОО подхода.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176194
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ruslan.Isbarovкак думаешь, сколько проектов в наше время укладываются в сроки поставленные менеджерами проектов (или лицами занимающимися оценкой рисков и сроков)?
- я думаю, нисколько :) Что во многом связано с низкой культурой заказчиков, которые после утверждения ТЗ норовят внести поправки, но при этом что бы все было сделано в те же сроки и без доплаты. Кроме того если сразу сказать заказчику сколько времени потребуется на проект он скорее всего откажется в пользу других исполнителей которые пообещают золотые горы, а в итоге сорвут сроки и сделают криво работающую поделку. Так что менеджерам часто приходится заведомо врать заказчику, или в более мягкой форме, скрывать от него часть правды, иначе первоначальная сделка просто не состоится.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176201
KachalovЛадно, это уже оффтоп для форума "Работа".

Все таки мне кажется что ОО подход более уместен при разработке "повторно используемых библиотек", чем при написании чего-то что "нужно сегодня, а завтра нужно будет новое"
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176204
mysterio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжить какой у вас опыт работы программистом?
Если бы вы написали хотя бы одну действительно большую и сложную систему, вы бы так не говорили.
Возьмите того же Буча и почитайте.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176207
Фотография Ruslan.Isbarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kachalov Ruslan.Isbarovкак думаешь, сколько проектов в наше время укладываются в сроки поставленные менеджерами проектов (или лицами занимающимися оценкой рисков и сроков)?
- я думаю, нисколько :)

Точно. 0%... :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176222
Фотография Ruslan.Isbarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжить KachalovЛадно, это уже оффтоп для форума "Работа".

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

И ты здесь пропагандируешь "процедурно-ориентированный" подход к разработке? А ты не задумывался что то, что ты пишешь "сегодня", с таким подходом напишешь только к "завтра", а как ты сам сказал "...а завтра нужно будет новое".
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176224
Фотография ррмяф
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжить
У вас вот уже спросили.
А что вы написали в разработке чего участвовали, расскажите, пожалуйста.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176236
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжитьОбъектно-ориентированный подход явно уступает остальным по объему кода, в т.ч. "пустого" boilerplate кода. Т.е. он заведомо хуже.
- "пустой" код образуется при недостаточном моделировании задачи. Хорошая модель позволяет избежать "лишних" методов в новом коде, кроме того стоит критически относится к сторонним библиотекам, которые могут содержать избыточный для Вашей задачи код.

какбытькакжить
мне кажется что ОО подход более уместен при разработке "повторно используемых библиотек", чем при написании чего-то что "нужно сегодня, а завтра нужно будет новое"

- ООП это способ мышления, заметно превосходящий по гибкости и удобству "процедурное" и "пошаговое" мышление (программирование). Если Вы мыслите исходя из данных сомнений в необходимости ООП просто не может быть, если Вы мыслите действиями, то наверное ООП Вам кажется излишне сложным. Это два разных взгляда на жизнь.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176514
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
креатив по сцылце не релевантен поскольку заведомо OS-dependent, что с оопом нараскоряку
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176517
Kachalov
- "пустой" код образуется при недостаточном моделировании задачи.


моделирование - зло
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176534
грузин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"
какбытькакжить

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

Ну что - то есть в этом, когда объекты моделируешь прикладной ориентации. А так как рыночная стихия заставляет бизнес выживать и адаптироваться и при этом воспроизводиться то... программисты без работы на останутся...
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176645
Угу, так же как президенты. Вопрос сколько и на каких основаниях.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34176834
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Читал статью. Забавно. Никаких выводов.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34177841
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kachalov
- ООП это способ мышления, заметно превосходящий по гибкости и удобству "процедурное" и "пошаговое" мышление (программирование). Если Вы мыслите исходя из данных сомнений в необходимости ООП просто не может быть, если Вы мыслите действиями, то наверное ООП Вам кажется излишне сложным. Это два разных взгляда на жизнь.

Как я ни люблю ООП, но комбинация ООП + статическая типизация (при всех плюсах) приводит к появлению "лишних" строчек кода, которые иногда существенно увеличивают время на внесение изменений.

Тут нужно сразу внести пояснения, иначе меня скушают.

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

2. Но "Дьявол в деталях" (с). На одних объектах из предметной области далеко не уедешь.
Появляются "синтетические" классы: классы-утилиты, промежуточные интерфейсы для обеспечения дополнительной гибкости, фактори, паттерны визитор, темлейт метод и т.п.
Казалось бы где грабли, ведь синтетические классы тоже решают задачи к которым можно применить ООА? А они есть. Преимущество использования декомпозиции данных (оно же ООА) существует только пока "данные" достаточно стабильны (существенно стабильнее, чем связанное с ними поведение). Так вот, данные предметной области стабильны и поэтому классы предметной области тоже стабильны, а синтетические классы не стабильны, т.к. исользуются для описания _поведения_, которое _нестабильно_.

К чему это приводит?

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


Н-р, код из второго сообщения.

Что вижу - то пою:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
 public   class  PrintOS 
{
	 public   static   void  main( final  String[] args) 
	{
		String osName = System.getProperty("os.name") ;
		 if  (osName.equals("SunOS") || osName.equals("Linux")) 
		{
			System.out.println("This is a UNIX box and therefore good.") ;
		} 
		 else   if  (osName.equals("Windows NT") || osName.equals("Windows 95")) 
		{
			System.out.println("This is a Windows box and therefore bad.") ;
		} 
		 else  
		{
			System.out.println("This is not a box.") ;
		}
	}
}

Процедурная декомпозиция:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) {
        String osName = System.getProperty("os.name");
         if  (isUnix(osName)) {
            processUnix();
        }  else   if  (isWindows(osName)) {
            processWindows();
        }  else  {
            processUnknown();
        }
    }

     private   static   void  processUnknown() {
        System.out.println("This is not a box.");
    }

     private   static   boolean  isWindows(String osName) {
         return  osName.equals("Windows NT") || osName.equals("Windows 95");
    }

     private   static   void  processWindows() {
        System.out.println("This is a Windows box and therefore bad.");
    }

     private   static   boolean  isUnix(String osName) {
         return  osName.equals("SunOS") || osName.equals("Linux");
    }

     private   static   void  processUnix() {
        System.out.println("This is a UNIX box and therefore good.");
    }
}

Ясно стало видно дублирование кода для выявления типа OS, которое трудно устранить не имея возможности получить ссылку на метод.

Используем для этого полиморфизм:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) {
        findOSByName(System.getProperty("os.name")).process();
    }

     private   static  OS findOSByName(String osName) {
         for  (OS os :  new  OS[]{ new  Unix(),  new  Windows(),  new  Unknown()}) {
             if  (os.isMatch(osName)) {
                 return  os;
            }
        }
         throw   new  InternalError();
    }

     interface  OS {
         boolean  isMatch(String osName);

         void  process();
    }

     static   class  Unknown  implements  OS {
         public   boolean  isMatch(String osName) {
             return  true;
        }

         public   void  process() {
            System.out.println("This is not a box.");
        }
    }

     static   class  Windows  implements  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("Windows NT") || osName.equals("Windows 95");
        }

         public   void  process() {
            System.out.println("This is a Windows box and therefore bad.");
        }
    }

     static   class  Unix  implements  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("SunOS") || osName.equals("Linux");
        }

         public   void  process() {
            System.out.println("This is a UNIX box and therefore good.");
        }
    }
}

Смотрим и видим, что класс PrintOS содержит утилитные методы, которым нужно найти другое место, чтобы они могли быть повторно использованы где-то ещё.

Синтезируем объект "известные операционные системы":

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) { 
        //Сказка?
        OSes.findByName(System.getProperty("os.name")).process();
    }
}

 interface  OS {
     boolean  isMatch(String osName);

     void  process();
}

 class  OSes {
     static  OS[] registred =  new  OS[]{ new  Unix(),  new  Windows(),  new  Unknown()};

     public   static  OS findByName(String osName) {
         for  (OS os : registred) {
             if  (os.isMatch(osName)) {
                 return  os;
            }
        }
         throw   new  InternalError();
    }

     static   class  Unknown  implements  OS {
         public   boolean  isMatch(String osName) {
             return  true;
        }

         public   void  process() {
            System.out.println("This is not a box.");
        }
    }

     static   class  Windows  implements  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("Windows NT") || osName.equals("Windows 95");
        }

         public   void  process() {
            System.out.println("This is a Windows box and therefore bad.");
        }
    }

     static   class  Unix  implements  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("SunOS") || osName.equals("Linux");
        }

         public   void  process() {
            System.out.println("This is a UNIX box and therefore good.");
        }
    }
}

Смотрим и снова видим, что что-то не так. А именно метод process. Он делает то, что нужно классу PrintOS, а как же быть другим пользователям OSes? Можно дописывать методы в интерфейс OS и реализовывать их, но это нарушает OSP.
Поэтому появляется визитор:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) {
        OSes.findByName(System.getProperty("os.name")).process( new  PrintMessageVisitor());
    }

     private   static   class  PrintMessageVisitor  implements  OSes.Visitor {
         public   void  visit(OSes.Unix unix) {
            System.out.println("This is a UNIX box and therefore good.");
        }

         public   void  visit(OSes.Windows windows) {
            System.out.println("This is a Windows box and therefore bad.");
        }

         public   void  visit(OSes.Unknown unknown) {
            System.out.println("This is not a box.");
        }
    }
}

 interface  OS {
     boolean  isMatch(String osName);

     void  process(OSes.Visitor visitor);
}

 class  OSes {
     static  OS[] registred =  new  OS[]{ new  Unix(),  new  Windows(),  new  Unknown()};

     public   static  OS findByName(String osName) {
         for  (OS os : registred) {
             if  (os.isMatch(osName)) {
                 return  os;
            }
        }
         throw   new  InternalError();
    }

     interface  Visitor {

         void  visit(Unknown unknown);

         void  visit(Windows windows);

         void  visit(Unix unix);
    }

     static   class  Unknown  implements  OS {
         public   boolean  isMatch(String osName) {
             return  true;
        }

         public   void  process(Visitor visitor) {
            visitor.visit( this );
        }
    }

     static   class  Windows  implements  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("Windows NT") || osName.equals("Windows 95");
        }

         public   void  process(Visitor visitor) {
            visitor.visit( this );
        }
    }

     static   class  Unix  implements  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("SunOS") || osName.equals("Linux");
        }

         public   void  process(Visitor visitor) {
            visitor.visit( this );
        }
    }
}

Лечге стало? Стало. Но остаётся дублирование и трудно добавлять новые типы оs.

Фиксим:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) {
        OSes.findByName(System.getProperty("os.name")).process( new  PrintMessageVisitor());
    }

     private   static   class  PrintMessageVisitor {
        @OS.Type(OSes.Unix. class )
         public   void  unixGood() {
            System.out.println("This is a UNIX box and therefore good.");
        }

        @OS.Type(OSes.Windows. class )
         public   void  windowsBad() {
            System.out.println("This is a Windows box and therefore bad.");
        }

        @OS.Type(OSes.Unknown. class )
         public   void  foo() {
            System.out.println("This is not a box.");
        }
    }
}


 abstract   class  OS {
     private   static  Object[] emptyArray =  new  Object[]{};

     public   abstract   boolean  isMatch(String osName);

     public   final   void  process(Object visitor) {
         for  (Method method : visitor.getClass().getMethods()) {
            OS.Type annotation = method.getAnnotation(OS.Type. class );
             if  (annotation !=  null  && annotation.value().equals( this .getClass())) {
                 try  {
                    method.invoke(visitor, emptyArray);
                }  catch  (Exception e) {
                     throw   new  InternalError(); //TODO;
                }
            }
        }
    }

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    @ interface  Type {
         Class  value();
    }
}


 class  OSes {
     static  List<OS> registred =  new  ArrayList<OS>();

     private  OSes() {
    }

     static  {
         for  ( Class  clazz : OSes. class .getClasses()) {
             if  (OS. class .isAssignableFrom(clazz)) {
                 try  {
                    register((OS) clazz.newInstance());
                }  catch  (Exception e) {
                     throw   new  InternalError(); //TODO;
                }
            }
        }
    }

     public   static   void  register(OS os) {
        registred.add(os);
    }

     public   static  OS findByName(String osName) {
         for  (OS os : registred) {
             if  (os.isMatch(osName)) {
                 return  os;
            }
        }
         return  Unknown.INSTANCE;
    }

     public   static   class  Unknown  extends  OS {
         public   final   static  OS INSTANCE =  new  Unknown();

         public   boolean  isMatch(String osName) {
             return  false;
        }
    }

     public   static   class  Windows  extends  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("Windows NT") || osName.equals("Windows 2003");
        }
    }

     public   static   class  Unix  extends  OS {
         public   boolean  isMatch(String osName) {
             return  osName.equals("SunOS") || osName.equals("Linux");
        }
    }
}

Избавляемся от мусора ввиде статиков:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) {
         new  OSContainer().resolve(System.getProperty("os.name")).process( new  MessagePrinter());
    }

     private   static   class  OSContainer  extends  AbstractOSContainer {

         public   static   class  Windows  extends  OS {
             public   boolean  isMatch(String osName) {
                 return  osName.equals("Windows NT") || osName.equals("Windows 2003");
            }
        }

         public   static   class  Unix  extends  OS {
             public   boolean  isMatch(String osName) {
                 return  osName.equals("SunOS") || osName.equals("Linux");
            }
        }
    }

     private   static   class  MessagePrinter {
        @OS.Type(OSContainer.Unix. class )
         public   void  unixGood() {
            System.out.println("This is a UNIX box and therefore good.");
        }

        @OS.Type(OSContainer.Windows. class )
         public   void  windowsBad() {
            System.out.println("This is a Windows box and therefore bad.");
        }

        @OS.Type(OS.Unknown. class )
         public   void  foo() {
            System.out.println("This is not a box.");
        }
    }
}

// Support ---------------------------------------------------------------------

 abstract   class  OS {
     public   final   static  OS UNKNOWN =  new  Unknown();

     private   static  Object[] emptyArray =  new  Object[]{};

     public   abstract   boolean  isMatch(String osName);

     public   final   void  process(Object visitor) {
         for  (Method method : visitor.getClass().getMethods()) {
            OS.Type annotation = method.getAnnotation(OS.Type. class );
             if  (annotation !=  null  && annotation.value().equals( this .getClass())) {
                 try  {
                    method.invoke(visitor, emptyArray);
                }  catch  (Exception e) {
                     throw   new  InternalError(); //TODO;
                }
            }
        }
    }

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    @ interface  Type {
         Class  value();
    }

     public   static   class  Unknown  extends  OS {
         public   boolean  isMatch(String osName) {
             return  false;
        }
    }
}

 class  OSes {
     private  List<OS> registred =  new  ArrayList<OS>();

     public   void  register(OS os) {
        registred.add(os);
    }

     public  OS findByName(String osName) {
         for  (OS os : registred) {
             if  (os.isMatch(osName)) {
                 return  os;
            }
        }
         return  OS.UNKNOWN;
    }
}

 class  AbstractOSContainer {
     private  OSes oses =  new  OSes();

     public  AbstractOSContainer() {
        initOSesFromInnerClasses();
    }

     private   void  initOSesFromInnerClasses() {
         for  ( Class  clazz :  this .getClass().getClasses()) {
             if  (OS. class .isAssignableFrom(clazz)) {
                 try  {
                    oses.register((OS) clazz.newInstance());
                }  catch  (Exception e) {
                     throw   new  InternalError(); //TODO;
                }
            }
        }
    }

     public  OS resolve(String osName) {
         return  oses.findByName(osName);
    }
}

Итого из простого метода получены синтетические сущности:
OS - операционная система
@Os.Type - аннотация упрощающая создание visitor'ов
OSes - произвольный набор операционных систем и методы работы с ними
AbstractOSContainer - базовый класс для конкретного набора OS (с автоматической подгрузкой типов операционных систем)
OSConainer - конкретный набор OS (их может быть несколько для разных задач)

Однако изменение в тз на исходный метод может сразу сделать все эти классы бесполезными (если им не успели найти применения ещё где-нибудь) или существенно большей переработки, чем потребовалось для простого варианта.

Какой вывод?

ООП не является достаточно гибким способом мышления.
Нет времени сейчас, кто хочет может дописать как тоже самое будет выглядеть на лиспе, чтобы убедиться, что есть способ "лучше" :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178415
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs
Однако изменение в тз на исходный метод может сразу сделать все эти классы бесполезными (если им не успели найти применения ещё где-нибудь) или существенно большей переработки, чем потребовалось для простого варианта.

Какой вывод?

ООП не является достаточно гибким способом мышления.

- вот я и говорю ООП - другой способ мышления :) Вы исходном примере с которого Вы начали всю мутату нет данных вообще. ООП исходит из данных. Программист с ООП мышлением в Вашем искуственном примере первым делом бы завел поле:
Код: plaintext
1.
 private  String osName;
и вокруг него бы выстраивал методы. То что получилось у Вас это не ООП, а пародия на него.

Если заказчик системы занимается продажей товаров, то сущность "товар" никуда не денется из ТЗ как бы ни изголялся заказчик и какие бы действия над ними не делал. Данные не куда не пропадут из программы, тогда как действия над ними можно менять, в этом и заключается мощь и гибкость ООП.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178513
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторто сущность "товар" никуда не денется из ТЗ как бы ни изголялся заказчик и какие бы действия над ними не делал

запросто. Заказчик продавал диски с пиратскими играми и фильмами а сейчас (в свете последних событий) это стало пустая болванка+услуга по записи скачанного из инета файла неизвестного содержания.

И не надо про другое мышление. Мышление одинаковое всегда должно быть, здравое.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178799
AlexeyShponarsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Реально большой проэкт (по-моему) без ООП не напишешь, а если напишешь то он будет как минимум в раза два больше (кода). ООП - сила.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178806
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1024запросто. Заказчик продавал диски с пиратскими играми и фильмами а сейчас (в свете последних событий) это стало пустая болванка+услуга по записи скачанного из инета файла неизвестного содержания.

GameDisc -> Disc -> Object
VideoDisc -> Disc -> Object
- если при написании кода программист исходил из общего случая (класс Disc), то его код не потерял актуальности и большую часть кода удастся использовать повторно или модифицировать программу без существенных трудозатрат. А программист который смотрит в будущее создал бы такую структуру классов:
GameDisc -> Disc -> Ware -> Object
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178857
ррмяфА что вы написали в разработке чего участвовали, расскажите, пожалуйста.... не волшебник, я только учусь© Потому и спрашиваю

GameDisc -> Disc -> Ware -> Object
GameDisc -> Disc -> Ware -> Object
Будильник -> Часы -> Ware -> Object
Секундомер -> Часы -> Ware -> Object
Женские трусы -> Трусы -> Ware -> Object
Мужские трусы -> Трусы -> Ware -> Object
?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178910
Фотография Ruslan.Isbarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexeyShponarskyРеально большой проэкт (по-моему) без ООП не напишешь, а если напишешь то он будет как минимум в раза два больше (кода). ООП - сила.

Увы, сейчас все технологии реализованы с применением ОО подхода.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34178932
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всё просто, как пареная репа !

Хотите "РУБить капу$ту" на пике самых передовых технологий - используйте ООП .

А кто там - приверженец процедурального или еще бог-знает какого программирования - нервно курит в сторонке. Ибо нефиг.

Хакеры говорите?

Ха! Ха!

А вот давайте поймаем одного живого хакера и спросим его - Чел! Ты юзаешь ООП или как?

Тогда всё вопросы исчезнут ИМХО.

C уважением
Lord Mayton
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34179019
smbdy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
срочно переименуйте топик в
mayton
А вот давайте поймаем одного живого хакера
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34179652
PFOcChKen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Написать можно всё и при помощи процедурного и при помощи ООП подхода, вопрос во времени, сложности и количестве кода... При процедурном подходе все три параметра будут на порядок больше. Это проверено на практике миллионов программистов, которые работали до нас. ООП разрабатывался не с бадуна, а когда это стало необходимостью, иначе мы до сих пор бы обсуждали процедуры, функции и т.д. и ни каких ООП языков не было бы впринципе. Простой пример - релизуйте хоть более-менее сложный алгоритм при помощи процедурного и ООП подхода и всё станет на свои места. Например - реализация решения ЗЛП в общем случае - задача может иметь сколько угодно переменных и сколько угодно ограничений. Можно попробовать писать на С и С++, например. Мне кажется, что только на более-менее сложных задачах можно увидеть как ООП обгоняет процедурный подход по всем мыслимым критериям.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34180162
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KachalovПрограммист с ООП мышлением в Вашем искуственном примере первым делом бы завел поле:
Код: plaintext
1.
 private  String osName;
и вокруг него бы выстраивал методы. То что получилось у Вас это не ООП, а пародия на него.

О, давайте вы, как программист с ООП мышлением, покажите где будет заведено это поле, какие методы с ним будут работать и т.д.

Плз.


Kachalov
Если заказчик системы занимается продажей товаров, то сущность "товар" никуда не денется из ТЗ как бы ни изголялся заказчик и какие бы действия над ними не делал.

Данные не куда не пропадут из программы, тогда как действия над ними можно менять, в этом и заключается мощь и гибкость ООП.

Попробуйте читать то, что я пишу.

Сущности ака "товар" вытекают из анализа предметной области и никуда не могут исчезнуть, пока не изменится сама предметная область, что бывает достаточно редко.

Однако операции с "товаром" могут то исчезать, то появляться.
Код реализующий эти операции будет либо насквозь процедруным, либо будут вводиться вспомогательные объекты (т.н. синтетические объекты, которых полным полно во всех общеизвестных паттернах) позволяющие избавиться от дублирования кода, изменить направление зависимостей, увеличить сцепление и т.д. и т.п.
В первом случае имеем дело не с ООП, а с миксом ООП + процедурщина - без функциональных типов (т.е. в java) этого не достаточно, чтобы писать "хороший" код.
Во втором случае, объекты могут появляться и исчезать так же часто как будет измененяться поведение "стабильных" объектов.
Т.е. вместо гибкости, можно получить необходимость писать лишний код.

Самый лучший вариант ООП + функциональное программирование так, как это сделано в nemerle.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34180632
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs
О, давайте вы, как программист с ООП мышлением, покажите где будет заведено это поле, какие методы с ним будут работать и т.д.

- фигней заниматься не хочется.

NotGonnaGetUs
Однако операции с "товаром" могут то исчезать, то появляться.
Код реализующий эти операции будет либо насквозь процедруным, либо будут вводиться вспомогательные объекты (т.н. синтетические объекты, которых полным полно во всех общеизвестных паттернах) позволяющие избавиться от дублирования кода, изменить направление зависимостей, увеличить сцепление и т.д. и т.п.
- не забывайте про полиморфизм, который поможет адаптировать методы под изменение задачи (при условии что предметная область не изменилась и классы, описывающие сущности, были составлены разумно, скорее всего переопределению подвергнется малое число методов, а в сущностных классах в идеале вообще ничего трогать не придется)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34180791
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kachalov- фигней заниматься не хочется.
А вы займитесь, и увидите, что фигней окажутся слова про "мышление".
Тем более, что тут любое решение простая пара строчек кода.

Kachalov
- не забывайте про полиморфизм, который поможет адаптировать методы под изменение задачи

Какже я его забуду, он мне по ночам только не снится :)

Полиморфизм не бесплатная штука. Любое использование полиморфизма приводит к появлению нового класса наследника, а цепочки наследований приводят к коду изменять, который в некоторых случаях существенно труднее, чем "лапшу" из if-else.


Если вам всё кажется таким солнечным, сделайте то, что я прошу. Не одному мне, думаю, будет интересно увидеть "ООП в действии".
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34181683
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Kachalov

автор- фигней заниматься не хочется.

для фигни на скл.ру есть ПТ. А тут извольте обосновывать. Дофига вас таких, сопливых.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34181787
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs
А вы займитесь, и увидите, что фигней окажутся слова про "мышление".
Тем более, что тут любое решение простая пара строчек кода.

- по просьбам "телезрителей" попытался описать проблему из примера NotGonnaGetUs с "моей" точки зрения, т. е. опираясь на данные (то самое ООП мышление). Боюсь решение никого кроме меня не удовлетворит, т. к. получилось "слишком" просто :)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
 public   class  OS {
    
     private  String name; //OS name
     private   final   static  OS[] OSList= new  OS[]{ new  OS("Linux"),  new  OS("Windows")};
    
     public  OS(String name) {
         this .name=name;
    }
    
     public  String getName(){
         return ( this .name);
    }
        
     public  String toString(){
         return ("This is a "+ this .getName());
    }
    
     public   static  OS getOSByName(String name){
        OS os= null ;
         for ( int  i= 0 ; i<OSList.length; i++){
             if (OSList[i].getName().equalsIgnoreCase(name)) os=OSList[i];
        }
         return ((os!= null )?os: new  OS("Unknown"));
    }
    
}

 public   class  TestOS {
    
     public   static   void  main(String[] arg) {
        System.out.println(OS.getOSByName(System.getProperty("os.name")));
    }
    
}

- возможно не уловил суть проблемы в изложении NotGonnaGetUs, ели что поясните какие проблемы могут возникнуть при использовании предложенного кода
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34181792
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
10242Kachalov
автор- фигней заниматься не хочется.
для фигни на скл.ру есть ПТ. А тут извольте обосновывать. Дофига вас таких, сопливых.

- персонально для 1024 - Сергей Сергеевич ведите себя сдержаней, вы вроде взрослый человек, а ведете себя как подросток в период полового созревания. Не хватало еще нам с Вами прилюдно соплями меряться :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34183087
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kachalov- возможно не уловил суть проблемы в изложении NotGonnaGetUs, ели что поясните какие проблемы могут возникнуть при использовании предложенного кода

1.

a. Сообщения, которые выводятся на экран должны совпадать с теми, что присутствуют в исходном коде. В общем случае эти сообщения произвольные, т.к. мнения о том, что good или bad у разных людей разные.
Т.е. универсального toString() сделать нельзя.

b. Алгоритм определения типа OS в вашем варианте не работает, т.к. ни одна из версий windows не идентифицируется как osName == "windows".

Если учесть это, что ваш варинт будет таким:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
 public   class  PrintOS {
     public   static   void  main( final  String[] args) {
        System.out.println(OS.findByName(System.getProperty("os.name")).getMessage());
    }
}

 class  OS {
     public   static   final  String WINDOWS = "Windows";
     public   static   final  String UNIX = "Unix";
     public   static   final  String UNKNOWN = "Unknown";

     private  String name;

     public  OS(String name) {
         this .name = name;
    }

     public  String getName() {
         return  name;
    }

     public  String getMessage() {
         if  (getName().equals(UNIX)) {
             return  "This is a UNIX box and therefore good.";
        }  else   if  (getName().equals(WINDOWS)) {
             return  "This is a Windows box and therefore bad.";
        }  else  {
             return  "This is not a box.";
        }
    }

     public   static  OS findByName(String osName) {
         if  (isUnix(osName)) {
             return   new  OS(WINDOWS);
        }
         if  (isWindows(osName)) {
             return   new  OS(UNIX);
        }
         return   new  OS(UNKNOWN);
    }

     public   static   boolean  isWindows(String osName) {
         return  osName.equals("Windows NT") || osName.equals("Windows 2003");
    }

     public   static   boolean  isUnix(String osName) {
         return  osName.equals("SunOS") || osName.equals("Linux");
    }
}

2. Проблемы:

а. Нет возможности расширить класс OS поведением специфичным для конкретной операционной системы. Н-р, для windows имеет смысл метод "получить реестр", а для unix или unknown - нет.
Т.е. в нём недостаточно гибкости.

b. Добавление нового типа OS потребует изменения в коде класса OS.
Нарушение OCP.

Общий вывод: требуется рефакторинг "замена переменной типа наследованием или стратегией" (либо наследуем Unix -> OS, либо добавляем в OS поле Type и реализуем Type <- Unix).

с. Класс OS содержит методы c низкой степенью сцепления. Попытки добавления новых методов для работы с OS только усугубят ситуацию. Н-р, есть две группы методов (findByName, isWindows и isLinix) и (getName, getMessage) явно решающих не связные друг с другом задачи. Поэтому нужно выделить первую группу методов в класс OSFactory.

d. Класс OS обладает информацией о всех своих "подтипах". Это проблема, т.к. постоянно появляются новые версии OS, что приведёт к необходимости изменений в классе OS.
Если бы набор OS был фиксирован раз и на всегда, то можно было бы обойтись использованием простого enum'a.

e. Метод getMessage находится не на своём "месте". Пожелания всех желающих засунуть в (полу)библиотечный класс не выйдет. Нужен механизм позволяющий каждому клиенту расширять поведение класса не прибегая к его модификации (опять OCP).

...

Продолжая копаться можно найти ещё кучу различных "поводов" для изменений, каждое из которых будет разрешать _потенциальные_ проблемы, но, вместе с тем, всё больше и больше усложнять общее решение.
И все эти усложнения могут легко пойти лесом, из-за внезапно появившихся у заказчика новых требований совсем "чуть-чуть" меняющих поведение объектов, но почему-то таким способом, который "не ложится" на имеющийся код.
Т.е. стабильность классов оказывается достаточно условной, о чём я и пытаюсь сказать.

Поэтому меня очень радует подход Фаулера и других идеологов хp: останавливаться на самом простом решении из возможных, но при этом оставлять возможности для будущих рефакторингов, чтобы как только решение не сможет удовлетворить изменившимся требованиям, его можно было легко привести к более совершенному виду (заменить параметр типа на стратегию или наследование и т.д.).
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34183104
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
     public   static  OS findByName(String osName) {
         if  (isUnix(osName)) {
             return   new  OS(WINDOWS);
        }
         if  (isWindows(osName)) {
             return   new  OS(UNIX);
        }
         return   new  OS(UNKNOWN);
    }

Опечатка :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34183134
vfabr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
NotGonnaGetUsОднако операции с "товаром" могут то исчезать, то появляться.
Какие такие операции? Мне просто интересно может я чего нить не понимаю ...

есть товар, у него есть набор свойств ключ=значение, есть артикул, вес, количество, цена, описание и тд(данные). Товар может рассказать о себе (методы). Если например имеется ввиду что у товара должна быть например галка "в прайс" то это может быть уже объект прайс.

вообще я согласен с NotGonnaGetUs. Есть некая граница до которой функциональное программирование удобно и после которой неудобно. Надо делать так чтобы это было максимально эффективно (стоимость работы на полученный результат). Иногда можно сделать "круто" только когда это круто будет работать все клиенты уйдут к конкурентам. Как говорится без фанатизма надо.

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

Вообще бизнес процесс зачастую не меняется так быстро чтобы невозможно было напрограммировать то что нужно. Да действительно нужно программировать, но за это кажется программистам деньги и платят :-)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34183146
vfabr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
про фаулера +1
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34183351
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vfabr
NotGonnaGetUs
Сущности ака "товар" вытекают из анализа предметной области и никуда не могут исчезнуть, пока не изменится сама предметная область, что бывает достаточно редко.

NotGonnaGetUsОднако операции с "товаром" могут то исчезать, то появляться.
Какие такие операции? Мне просто интересно может я чего нить не понимаю ...


"товар" используется в качестве примера, а затем синонима для обозначения классов выведенных непосредственно при анализе предметной области.

Операции == действия над объектами/данными.
Н-р, вчера нужно было напечатать в консоль, что "This is a UNIX box and therefore good.", а сегодня версию OS и тип файловой системы. Объект один и тот же - "OS", а представить его ввиде классов/данных можно очень по разному (и сильно потом жалеть).

Тут же уместно вспомнить известный пример про написания класса "стол".
И в очередной раз убедиться, что ООП очень хорошо подходит для решения _конкретной_ задачи, и не очень подходит для создания решений для _семейств_ задач, особенно если в постановке задачи начинают фигурировать "естественные" понятия, которые бывает очень проблематично представить ввиде фиксированного набора свойств, а значит и отобразить в класс.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34185711
Вот еще один пример сопоставления OOP vs NOOP.

Я тоже заметил давно, что OOP очень сильно смахивает на способ записи процедур и функций в классы, т.е. эдакое модуляризированное процедурное программирование.

Мне вот интересно, а если у класса из примера в статье не 2 состояния male|female, а 15 или 30, что, 30 классов-наследников писать? А если иерархий наследования не одна а 3-4?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34185840
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжитьЯ тоже заметил давно, что OOP очень сильно смахивает на способ записи процедур и функций в классы, т.е. эдакое модуляризированное процедурное программирование.

А я давно заметил, что написание программ очень смахивает на работу с MS Word, т.е. эдакое набирание буковок на клавиатуре.

Правда, мы с тобой "зрим в корень", а все остальные ничего в этой жизни не понимают?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34185929
ldima
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжить Вот еще один пример сопоставления OOP vs NOOP.

Я тоже заметил давно, что OOP очень сильно смахивает на способ записи процедур и функций в классы, т.е. эдакое модуляризированное процедурное программирование.

Мне вот интересно, а если у класса из примера в статье не 2 состояния male|female, а 15 или 30, что, 30 классов-наследников писать? А если иерархий наследования не одна а 3-4?

В качестве варианта советую почитать какую-нибудь книгу по шаблоном проектирования или вообще по ооп. а потом уж этот подход критковать, если не нравится. Проблемы с порождением большого числа классов обычно вполне решаемы
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34185986
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ув. Наснипаиметь, ваших огромных постов мой убитый оопом моск ниасиливает - но чую голимая крамола. Озвучте пожалуйста тезис в полторы строки, чтоб его можно было предметно оспорить

заранее сапсибо

вот одна из попыток воспринятия мегапрог (см.выш):
ущербные оопные куски писал явный провокатор задавщийся мелочной целью построить себе имя на попрании досточтимы Основ. но и на него найтётся хитрый болт: берём его креативы, компилим C++ компилятором, дизасемблируем - получаем процедурный код беспрецендентный по своей невообразимой вычурности. дальше делаем выводы что дейкстра и вирт должны отправиться в ад прямиком минуя чистилище.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34186093
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppув. Наснипаиметь, ваших огромных постов мой убитый оопом моск ниасиливает - но чую голимая крамола. Озвучте пожалуйста тезис в полторы строки, чтоб его можно было предметно оспорить

заранее сапсибо


А вы почитайте это сообщение .
Там есть п.1 и п.2.
Если согласны с п.1., то переходим к п.2 про проблемы (не знаю как можно не согласиться с п.1.)

Если в пунктах a/b/c/d/e что-то не понятно, то зацитируйте и задайте вопрос об этом.

Или можете повторить опыт Kachalov'a и показать нам, что ваш моск советует сделать с исходным кодом (тем, где всего один метод main), чтобы он стал "чиста" объекто ориентированным, а не процедурным.


Что вам за тезис нужен - не понял.
Если хочется с чем-нибудь по спорить, то вот вам несколько:

1. Если злоупотреблять ООП, т.е. порождать классы при декомпозиции поведния объектов выведенных из предметной области, изменения в коде будет делать так же сложно, как если бы весь код был насквозь процедурным.
2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией.
3. Хороший ООЯ должен сочетать не ООП + процедурное программирование, а ООП + функциональное программирование.
4. Останавливаться нужно на самом простом решении из возможных, но при этом оставлять возможности для будущих рефакторингов (чтобы при необходимости можно было легко получить более "правильное" решение).
5. "Естественные" понятия, которые проблематично описать фиксированным набором "свойств", представить "универсальным" классом практически невозможно. Конкретное задачи потребуют разные классы. Откуда следует вывод, что применимость ООП достаточно ограничена и рассматривать его как "мышление" можно только с натяжкой.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34186716
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs
А вы почитайте это ..

слишкам многа букаф

нужен descision table pattern а не class Os. ловим
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
 class  OsDescisioner{
String setSource(String src) ;  
Map<String,String> setDescisionTable(Map<String,String> descisionTableFromAnywhere);
String getDescision();
}

...
...
OsDescisioner osd =  new  OsDescisioner();
osd.setSource(sys.getProp("os.name"));
osd.setDescisionTable(staticDscTable);
System.out.println(odd.getDescision());
...
...

NotGonnaGetUs
1. Если злоупотреблять ООП ...
а если херакнуть молотком по пальцу ... не злоупотребляйте им. <<хороших>> молотков не бывает.
NotGonnaGetUs
2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией.
просматривая подобные объёмы кода я как правило вспоминаю "обезъяну с гранатой". динамические языки верный способ отстрела собственных ног.
NotGonnaGetUs
3. Хороший ООЯ должен сочетать не ООП + процедурное программирование, а ООП + функциональное программирование.
вот и сочетайте. функциональные фишки лекго впендюриваются в нормальные языки. вам что с чем надо скрестить?
NotGonnaGetUs
4. Останавливаться нужно на самом простом решении ... я бы постеснялся так боянить
NotGonnaGetUs
5. "Естественные" понятия, ... а об этом немного позже
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34186967
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppслишкам многа букаф
Ну вы сосредоточтесь, попросите кого-нибудь помочь вам разобраться.
А то мне придётся повторять тоже самое, будет опять много буковок, а т.к. для вас это сложно, то получится замкнутый круг.

expp
ловим
Код: plaintext
1.
2.
3.
4.
5.
 class  OsDescisioner{
String setSource(String src) ;  
Map<String,String> setDescisionTable(Map<String,String> descisionTableFromAnywhere);
String getDescision();
}


Полную имплементацию плз (вместе с инициализаций descisionTable и т.п.), чтобы между нами не вышло не понимания.

А пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е
класс OsDesc* просто лишний.
Достаточно иметь проинициализированный map.

Сравниваем:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
//было:
OsDescisioner osd =  new  OsDescisioner();
osd.setSource(sys.getProp("os.name"));
osd.setDescisionTable(staticDscTable);
System.out.println(odd.getDescision());

//стало:
string descision = staticDscTable.get(sys.getProp("os.name"));
System.out.println(descision);

Практически никаких _потенциальных_ проблем исходного решения ваше решение не решает и добавляет новые.
Так при изменении условий проверок, н-р, с (osName.equals("Windows NT") || ...) на (osName.toLowerCase().startWith("win")) таблицу придётся целиком выкинуть.

expp
а если херакнуть молотком по пальцу ... не злоупотребляйте им. <<хороших>> молотков не бывает.

Тоже любите боянить? :)

Говоря "не злоупотребляйте", вы соглашаетесь с невозможность применять объекто-ориентированный подход на всех этапах написания кода. А это равнозначно признанию в том, что данный подход не является универсальным и достаточно полным. Если это так, то ни о каком оо-мышлении говорить нельзя. А вы, кажется, с этим не хотите соглашаться? )


expp
NotGonnaGetUs
2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией.
просматривая подобные объёмы кода я как правило вспоминаю "обезъяну с гранатой". динамические языки верный способ отстрела собственных ног.

И тем не менее факт на лицо: кода получается меньше :)

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

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

expp
вот и сочетайте. функциональные фишки лекго впендюриваются в нормальные языки. вам что с чем надо скрестить?

*впендюриваются* легко, но пользоваться этим потом не возможно. Особенно в java, где нет никакой поддержки этих фокусов со стороны стандартных библиотек и языковых конструкций.
В С# c это всё есть, но всё равно не очень удобно (сужу по полугоду использования функциональных фич в этом языке :)). Поэтому ваш совет не совсем к месту.

Что с чем и как скрещивать иллюстрирует язык nemerle.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34187139
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в том то и прикол что если мысль есть то занимает она две строки от силы...
мой код вы поняли более чем верно.

NotGonnaGetUsА пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е

ООП вообще паттерн процедурного/структурного программирования.

NotGonnaGetUsГоворя "не злоупотребляйте", вы соглашаетесь с невозможность ... да ни в жисть - уметь надо и всё

NotGonnaGetUsИ тем не менее факт на лицо: кода получается меньше :) ассемблер вот язык достойный лаконичного мужа. Лапшу из if ов я просто не навижу авторов её предаю разнузданному геноциду
NotGonnaGetUs*впендюриваются* легко, но пользоваться этим потом не возможно.
вы пробовали ? лично я использовал Drools. впечатления нормальные

NotGonnaGetUsnemerle. с возрастом это проходит
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34187290
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppв том то и прикол что если мысль есть то занимает она две строки от силы...
мой код вы поняли более чем верно.

Прикол в том, что такая таблица приведёт к существенно большему дублированию кода, чем несколько в if-else, если нам потребуется в каком-то месте вывести чуть другие сообщения.
Так же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию.
И т.д. и т.п. (много буков)

Если попытаться честно расписать ваше решение и избавить его от описанных недостатков получится ровно тоже большое количество классов и таже сложность.

И вы это похоже прекрасно понимаете :) Тогда я не понимаю к чему были ваши слова "голимая крамола".


expp
NotGonnaGetUsА пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е
ООП вообще паттерн процедурного/структурного программирования.

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

expp
да ни в жисть - уметь надо и всё

Трухлявый бояян. Умеете - покажите. Не умеете - не говорите.

Я показал к какому коду может привести следовании оо принципам.
Вы назвали это "ущербными оопными кусками", если я правильно понял.
Если "умеете" продемонстрируйте как сделать отличные "оопные куски".
Пока вы этого не сделали.


expp
NotGonnaGetUsИ тем не менее факт на лицо: кода получается меньше :) ассемблер вот язык достойный лаконичного мужа.

Разве на ассемблере получается коротко? Мы вроде как не размер бинарников сравниваем...


expp
Лапшу из if ов я просто не навижу авторов её предаю разнузданному геноциду

Геноцид заключается в том, что авторов заставляют переписывать всё на таблицы? :)


expp
вы пробовали ? лично я использовал Drools. впечатления нормальные

Drools/Groovy/etc это не java. Это другие языки.
Писать тела методов java классов на них не получится.

expp
NotGonnaGetUsnemerle. с возрастом это проходит

Что именно? Желание иметь лямбды, паттерн матчинг, вывод типов и прочии конструкции позволяющие писать более лаконичный код, в частности, лишённый структурного дублирования ? )
Добавте пару буковок для расшифровки, я их осилю.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34187294
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppс возрастом это проходит
Интересно, почему "это" не прошло у разработчиков c# 3.0 и java 7?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34187382
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUsПрикол в том, что такая таблица приведёт к существенно большему дублированию кода, чем несколько в if-else, если нам потребуется в каком-то месте вывести чуть другие сообщения. ниправда: первая версия таблица забивается в коде в static инициализаторе. вторая версия выносится в конф.файло. Ни один из вариантов не валялся рядом с мляцкими ифэлсами.
NotGonnaGetUsТак же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию. это изменения "в ширину", наращивание функциональности, новый релиз. ифэлсы "конечно же" остаются неизменными при таких изменениях?

NotGonnaGetUsЕсли попытаться честно расписать ваше решение и избавить его от описанных недостатков получится ровно тоже большое количество классов и таже сложность. останется один HashMap. ну максимум descisioner и table.
NotGonnaGetUsИ чего? Вместо полиморфизма будет использовать опять таблицы, а вместо классов структуры или массивы с дикриминаторами? И зачем? а низачем. это было написано для того чтобы показать насосанность из пальца вашего утверждения про то что descision table это на самом деле паттерн стыренный оопниками. есть ваша якобы задача и есть descision table и они наиболее друг другу подходят. и отсюда ничего не следует. она так решается и всё а кем и на чём - неважно
в догонку такие шаблоны Domain Specific Language, Little Language

NotGonnaGetUsГеноцид заключается в том, что авторов заставляют переписывать всё на таблицы? :) Нет заставить переписать на таблицы - это знак милосердия. Я просто беру пол ведра ржавых гвоздей и ....
NotGonnaGetUs
Drools/Groovy/etc это не java. Это другие языки.
Писать тела методов java классов на них не получится. не надо тела классов писать на drools. мне приятно что на жабе есть подобная херь и если меня сильно прижмёт я смогу легко её использовать ничего не теряя от явы.

NotGonnaGetUsЧто именно? Желание иметь лямбды, паттерн матчинг, вывод типов и прочии конструкции позволяющие писать более лаконичный код, в частности, лишённый структурного дублирования ? выкобениватья на немерлях. пройдёт. как и у польских аспирантов. получится очередной похеренный .NET O/S проект.

Про jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. про делегаты - ваще молчу

о чём дискусия то? если про subj - то я "за" немедленное выжигание калёным железом быдлокодерства в любых проявлениях. и "за" смачный оопный дизайн .
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34187397
alexx726
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ребята, пукать в лужу не надоело друг перед другом?
Неужели нет более достойных тем (тем более в Java) для обсуждения, кроме как вариантов написания идиотской программки для даунов?
Аж читать гнусно...
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34187439
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
так трындеть не мешки ворочать. Если показать нечего то можно кучу историй нарасказывать.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34188728
exppПро jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. Это почему это closures - плохо? А как же Groovy? Спецально новый язык изобретают для JVM, где поддерживаются closures, curring, agile программирование и scripting.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34190577
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppниправда: первая версия таблица забивается в коде в static инициализаторе. вторая версия выносится в конф.файло.

Код в студию. Мне не понятно о чём вы.


expp
NGGU
Практически никаких _потенциальных_ проблем исходного решения ваше решение не решает и добавляет новые.
Так при изменении условий проверок, н-р, с (osName.equals("Windows NT") || ...) на (osName.toLowerCase().startWith("win")) таблицу придётся целиком выкинуть.


NotGonnaGetUsТак же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию.

это изменения "в ширину", наращивание функциональности, новый релиз. ифэлсы "конечно же" остаются неизменными при таких изменениях?


Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения.
Необходимость избавления от этой фиксации приведёт к необходимости реализации различного рода интерпретаторов (те самые дсл и кастрированные языки), а это существенно большее усложнение решения, чем использование полиморфизма для избавления от ветвлений.

Можете меня переубедить. Для этого достаточно привести-таки целиком ваш вариант с табличками и показать как он изменится при изменении одного из правил проверки с equlas на startWith.

expp
NotGonnaGetUsЕсли попытаться честно расписать ваше решение и избавить его от описанных недостатков получится ровно тоже большое количество классов и таже сложность. останется один HashMap. ну максимум descisioner и table.

ПОКАЖИТЕ. Зачем произносить лишние слова?

expp
это было написано для того чтобы показать насосанность из пальца вашего утверждения про то что descision table это на самом деле паттерн стыренный оопниками.


Повторюсь, в тайной надежде, что вы просто не внимательно до этого читали.

Использование "таблицы выбора" оставит процедруный код процедурным.
В ООЯзыке этот "паттерн" вшит, называется "полиморфизм".
Использование классов и полиморфизма вместо дискриминатора и таблицы лучше тем, что
- вызывать метод быстрее, чем бегать по мапе,
- не нужно каждый раз изобретать велосипед и заставлять разбираться в нём своих коллег,
- из-за плюсов статической типизации (н-р, Map<string, string> adress2name и Map<string, string> name2department не попадут в один метод)
- ...

expp
выкобениватья на немерлях. пройдёт. как и у польских аспирантов. получится очередной похеренный .NET O/S проект.

Что значит "выкобениватья на немерлях"? Приверженцы функциональных языков тоже только "выкобениваются"? :)

Есть пример DLINQ от МS. Языки like nemerle уже реальность.

expp
Про jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. про делегаты - ваще молчу

Объясните здесь.

expp
о чём дискусия то? если про subj - то я "за" немедленное выжигание калёным железом быдлокодерства в любых проявлениях. и "за" смачный оопный дизайн .

Давайте повспоминаем о чём дискусия...

Вы не смогли понять буковок и попросили очень коротких, а потому обязательно спорных, тезисов, которые вы смогли бы оспорить и назвали гавном моё ооп :). Я их вам дал (мне не жалко) и заодно предложил показать ваш вариант ОО решения для поставленной задачи.

Вы как-то вяло стали спорить с тезисами и привели микс из класса и таблицы выбора в качестве оо решения.

Далее я писал о том, что этот микс к ООП не имеет никакого отношения и ничем не лучше, чем набор if/else, а вы писали, что у меня "всё пройдёт", что вы "умеете готовить ООП", но так никому и не показали как и что-то там про насосасывание из пальца добавили...

Резюмируя: Я не знаю о чём вы ведёте дискусию и что хотите сказать (кроме того, что к if/else у вас не любовь). Я же пытался и пытаюсь узнать, как "правильно готовить ООП" и почему у меня оно на ваш (или чей угодно ещё) взгляд "галимое"(с) :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34190589
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexx726Ребята, пукать в лужу не надоело друг перед другом?
Неужели нет более достойных тем (тем более в Java) для обсуждения, кроме как вариантов написания идиотской программки для даунов?
Аж читать гнусно...

Хочешь пообсуждать написание программки "не для даунов"?
А как ты думаешь, если в таком простом варианте находится столько разных позиций и "странных" убеждений у людей, в сложном случае их станет меньше? :)

Будет только хуже. Почитай только, что о хибернейт с соседних топиках писалось.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34191474
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
це кот
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
 static  Map<String,String> staticDscTable =  new  HashMap<String,String>();
 static {
   staticDscTable.put("linux","pretty nice"); 
   staticDscTable.put("berkley","pretty nice too"); 
   staticDscTable.put("windows","unknown OS. please reboot"); 
}

 class  EqualsOsDescisioner  extends  OsDescisioner{
  String setSource(String src) ;  
  Map<String,String> setDescisionTable(Map<String,String> descisionTableFromAnywhere);
  String getDescision(){
      return  descisionTable.get(source)
  };
}
 class  StartWithOsDescisioner  extends  OsDescisioner{
  String setSource(String src) ;  
  Map<String,String> setDescisionTable(Map<String,String> descisionTableFromAnywhere);
  String getDescision(){
      for (Map.Entry e : descisionTable.entrySet()){
         if (source.toLower().startWith(e.getKey())){
             return  e.getValue()
        }
     }
      return  "unknown";
  };
}
...
...
OsDescisioner osd =  new  OsDescisioner();
osd.setSource(sys.getProp("os.name"));
osd.setDescisionTable(staticDscTable);
System.out.println(odd.getDescision());

можно я map у из файла грузить не буду а то работать нада ...

NotGonnaGetUs
Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения.

не а. мапы рулят. нужен алгоритм сравнения пишем IEqulizer - и фаны closure показывают всю свою мощь
NotGonnaGetUs
Необходимость избавления от этой фиксации приведёт к необходимости реализации различного рода интерпретаторов (те самые дсл и кастрированные языки), а это существенно большее усложнение решения, чем использование полиморфизма для избавления от ветвлений.

для клинических случаев дсл и кастро языки или plug-in class (каждый раз что то новое придумываю - воистину не исчерпаемая затача таксономии ОСов). дсл и кастро языки уже есть бери и юзай если надо. не надо приплетать сюда полиморфизм чтобы показать, что он "не вывозит"

NotGonnaGetUs
В ООЯзыке этот "паттерн" вшит, называется "полиморфизм".
вы открываете мне глаза, значит я дурак всю жизнь конфиги своих прог (которые не достойны отдельных файлов, и поэтому) держал в статик мапах, а надо было кучей классов делать ... а потом ещё фабрику примострячивать для их создания - стопудовый отстрел своих ног.

NotGonnaGetUsЧто значит "выкобениватья на немерлях"? это значит злобать на них helloworld не убившись от стену, восклицать : "буть прокляты годы на с# (жабе и т.п.)"
NotGonnaGetUsЕсть пример DLINQ от МS. Языки like nemerle уже реальность. smalltalk, lisp, oberon, OODB, ai тоже реальность

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

а вобще уже сожалею, что ввязался . alexx726, 1024 - без б.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34192887
teb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
teb
Гость
NotGonnaGetUs
5. "Естественные" понятия, которые проблематично описать фиксированным набором "свойств", представить "универсальным" классом практически невозможно. Конкретное задачи потребуют разные классы. Откуда следует вывод, что применимость ООП достаточно ограничена и рассматривать его как "мышление" можно только с натяжкой.

Дык... мил-человек... разве ООП инструмент для решения абстрактных задач?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34193411
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teb Дык... мил-человек... разве ООП инструмент для решения абстрактных задач?

И в основном - именно абстрактных. Живой пример:

- бизнес приложения, мало ООП-абельны на практике (в сравнении откровенных бредовых Java EE ORM и прочих MVC с какими дедушками вроде Cobol, ABAP и PL/SQL)
- системные средства (ОС Unix) - аналогично, даже С++ идет строго лесом и степью
- RDBMS - пишутся в массе, аналогично, на голом C
- RAD (Delphi, VB) с чистым (правильным) ООП - аналогично, имеют мало общего (в конечных приложениях)
- JSP, JSF, Struts, ASP - назвать именно ООП средствами... можно, но базовый их концепт - вовсе не в ООП
- большинство современных API - аналогично, с классами, абтракциями, инкапсуляциями и прочими декомпозициями... имеют лишь воображаемое общее).

----

Может ООП и его дальнешие фреймворк-agile развития - это был просто "вирус в воспалённых головах", когда в принципе вполне успешную модель абстрактных компонентно-инструментальных средств (AWT, SWT, J2EE, VCL, WinForms) вдруг начали с "общего перепугу" натягивать на те области, которые к ООП изначально отношение не имеют (вовсе) ? В смысле - не имеют целесообразности и реальной необходимости в ООП?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34193541
teb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
teb
Гость
grexhide вдруг начали с "общего перепугу" натягивать

Так "натягивать" - это не ООП.
Вот NotGonnaGetUs этим как раз и занялся в своём примере.
Мне так каэтся.

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

И получилось плохо.
Чему удивляться?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34194883
teb grexhide вдруг начали с "общего перепугу" натягивать

Так "натягивать" - это не ООП.
Вот NotGonnaGetUs этим как раз и занялся в своём примере.
Мне так каэтся.

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

И получилось плохо.
Чему удивляться?Я все таки всё ещё не понимаю, вот объясните, полиморфизм хорош, когда нужно описать поведение (создать классы) для 5-10 ОС. А если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34195193
teb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
teb
Гость
какбытькакжить
А если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора?

А в чём проблема?
Если использумая разработчиком технология - ООП, то да - 100 классов и пусть полиморфизм сам разбирается, он для того и придуман.
А если нет - то можно и таблицу, но тогда это не ООП и ругать его нечего.

Я так думаю.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34195707
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да прекратить дальнейшие ооспекуляции, хотелось бы акцентировать внимание общественности на том что суть оопа это не три известных мега-слова (которые являются критериями объ.ориент-ности языка). Суть же выражается оо-коаном "Tell Don't Ask", ну и более точно выражается в правильном распределении ответсвенности. ООП это не нарожать кучу классов!!! ну вот где то так ...
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34218682
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppце кот
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
 static  Map<String,String> staticDscTable =  new  HashMap<String,String>();
 static {
   staticDscTable.put("linux","pretty nice"); 
   staticDscTable.put("berkley","pretty nice too"); 
   staticDscTable.put("windows","unknown OS. please reboot"); 
}

 class  EqualsOsDescisioner  extends  OsDescisioner{
}
 class  StartWithOsDescisioner  extends  OsDescisioner{
}
...
...
OsDescisioner osd =  new  OsDescisioner();
osd.setSource(sys.getProp("os.name"));
osd.setDescisionTable(staticDscTable);
System.out.println(odd.getDescision());

можно я map у из файла грузить не буду а то работать нада ...

1. new OsDescisioner(); - это опечтка?

2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит.

3. В примере были более сложные условия выбора. У вас оно выглядело бы так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 static {
   staticDscTable.put("SunOS","pretty nice"); 
   staticDscTable.put("Linux","pretty nice"); 
   staticDscTable.put("Windows 95","pretty nice too"); 
   staticDscTable.put("Windows NT","pretty nice too"); 
   staticDscTable.put("unknown","unknown OS. please reboot"); 
}
Т.е. появляется дублирование.

Когда понадобится в другом месте использовать аналогичный выбор, то получится ещё большое дублирование:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 static {
   anotherDscTable.put("SunOS","pretty nice 2"); 
   anotherDscTable.put("Linux","pretty nice 2"); 
   anotherDscTable.put("Windows 95","pretty nice too 2"); 
   anotherDscTable.put("Windows NT","pretty nice too 2"); 
   anotherDscTable.put("unknown","unknown OS. please reboot 2"); 
}

Учитывая, что эти фрагменты будут писать разные люди, какова вероятность, что все такие куски кода будут изменяться одновременно и корректно? Да никакой.

И почему статический мап, в который можно внести изменения из любого фрагмента кода лучше, чем класс, содержащий туже функциональность? Нет никаких объяснений, кроме фанатичной преданности "мапе".


4. Грузить из файла? Зачем?!

expp
NotGonnaGetUs
Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения.

не а. мапы рулят. нужен алгоритм сравнения пишем IEqulizer - и фаны closure показывают всю свою мощь

Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат?

А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ?

А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой?
Моделировать средствами ООЯзыков паттерны процедурных языков - это круто...


expp
NotGonnaGetUs
Необходимость избавления от этой фиксации приведёт к необходимости реализации различного рода интерпретаторов (те самые дсл и кастрированные языки), а это существенно большее усложнение решения, чем использование полиморфизма для избавления от ветвлений.

для клинических случаев дсл и кастро языки или plug-in class (каждый раз что то новое придумываю - воистину не исчерпаемая затача таксономии ОСов). дсл и кастро языки уже есть бери и юзай если надо. не надо приплетать сюда полиморфизм чтобы показать, что он "не вывозит"


А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма".

Анекдот в том, что все эти dsl-и, плагины и десишин мапы приводят к коду обладающими всеми недостатками динамически типизированных языков и практически никаким плюсам.



expp
NotGonnaGetUs
В ООЯзыке этот "паттерн" вшит, называется "полиморфизм".
вы открываете мне глаза, значит я дурак всю жизнь конфиги своих прог (которые не достойны отдельных файлов, и поэтому) держал в статик мапах, а надо было кучей классов делать ... а потом ещё фабрику примострячивать для их создания - стопудовый отстрел своих ног.

Мы не "конфиг" пишем.

А в целом вы правы. Зря статик мапы держали. Вместо:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 class  BlaBla {
 public   static  Map<String,String> staticDscTable =  new  HashMap<String,String>();
 static {
   staticDscTable.put("linux","pretty nice"); 
   staticDscTable.put("berkley","pretty nice too"); 
   staticDscTable.put("windows","unknown OS. please reboot"); 
}
}
//доступ:
String s = BlaBla.staticDscTable.get("linux");

Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 class  BlaBla {
    public   static   final  String linux = "pretty nice"; 
    public   static   final  String berkley= "pretty nice too"; 
    public   static   final  String windows= "unknown OS. please reboot"; 
}
//доступ:
String s = BlaBla.linux;


expp
NotGonnaGetUsЧто значит "выкобениватья на немерлях"?
это значит злобать на них helloworld не убившись от стену, восклицать : "буть прокляты годы на с# (жабе и т.п.)"
...
smalltalk, lisp, oberon, OODB, ai тоже реальность

Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}.
Что меня радует так это:
- кратность нотации без потери статической типизации,
- вывод типов (фактически возможность локально применять duck typing),
- возможность делать больше проверок при компиляции средствами языка (таже валидация sql),
- паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений,
- оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека)

expp
NotGonnaGetUsЕсть пример DLINQ от МS. Языки like nemerle уже реальность.
про jdk7 я конечно рад closure и delegateам в ущербном жабаязыке, но думаю никогда их использовать не буду т.к. они явлются излишней мутью, необходимой только их авторам

Смеха ради, почитайте как используются ущербные лямбды в DLINQ'е.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34218735
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
teb
Дык... мил-человек... разве ООП инструмент для решения абстрактных задач?

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

Конечно, можно отказаться этой возможности и других, и страгать на ООЯ в стиле "plain c", но тогда к чему все эти слова о "распределении обязанностей", гибкости решений и т.п.?

teb grexhide вдруг начали с "общего перепугу" натягивать

Так "натягивать" - это не ООП.
Вот NotGonnaGetUs этим как раз и занялся в своём примере.
Мне так каэтся.

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

И получилось плохо.
Чему удивляться?

Солнышко! Ну покажи, наконец-то, дурачку как правильно классы писать.
Приведи решение, аргументируй почему оно гибче/лучше того, что приводил я.
Покажи как оно будет меняться при возможных изменениях тербований. И все станут счастливы.
Зачем сидеть и просто так "удивляться"?!
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34218742
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
какбытькакжитьА если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора?

А ты просто попробуй, поделишься потом впечатлениями :)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219037
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs1. new OsDescisioner(); - это опечтка?
да. создаём конкретный EqualsOsDescisioner, StartWithOsDescisioner.
NotGonnaGetUs2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит. такое изощрение лечиться wildcardами или сразу regexpами
NotGonnaGetUs
3. В примере были более сложные условия выбора. У вас оно выглядело бы так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 static {
   staticDscTable.put("SunOS","pretty nice"); 
   staticDscTable.put("Linux","pretty nice"); 
   staticDscTable.put("Windows 95","pretty nice too"); 
   staticDscTable.put("Windows NT","pretty nice too"); 
   staticDscTable.put("unknown","unknown OS. please reboot"); 
}
Т.е. появляется дублирование.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 static   final  String pretty_nice="...";
 static   final  String pretty_nice_too="...";
....
 static {
   staticDscTable.put("SunOS",pretty_nice); 
   staticDscTable.put("Linux",pretty_nice); 
   staticDscTable.put("Windows 95",pretty_nice_too); 
   staticDscTable.put("Windows NT",pretty_nice_too); 
   staticDscTable.put("unknown",unknown_OS_please_reboot); 
}
NotGonnaGetUs
И почему статический мап, в который можно внести изменения из любого фрагмента кода лучше, чем класс, содержащий туже функциональность? Нет никаких объяснений, кроме фанатичной преданности "мапе".
Collections.unmodifableMap и воьще поставить с default доступом
NotGonnaGetUs4. Грузить из файла? Зачем?! а вот это помоему действительно нужный функционал - конфигурировать прогу неперекомпиляя её. во всяком случае очень много людей думают так же
NotGonnaGetUs
Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат?

нет каждая DescistionTable имеет свой IEqulizer.
NotGonnaGetUs
А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ? да. при извратской логике доступ по ключу не нужен - просто список пар.
NotGonnaGetUs
А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой?
Моделировать средствами ООЯзыков паттерны процедурных языков - это круто...
пишу буквами побольше ни нужен тут этот рукав (полиморфизм)
NotGonnaGetUs
А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма". Анекдот в том, что все эти dsl-и, плагины и десишин мапы приводят к коду обладающими всеми недостатками динамически типизированных языков и практически никаким плюсам. анекдот очень смешной. полиморфизм штука статическая. задача проще решать как динамическую.
NotGonnaGetUs
Мы не "конфиг" пишем.

повторюсь. это и есть конфиг, нах.
NotGonnaGetUsА в целом вы правы. я всегда прав...
NotGonnaGetUsЗря статик мапы держали. Вместо:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 class  BlaBla {
 public   static  Map<String,String> staticDscTable =  new  HashMap<String,String>();
 static {
   staticDscTable.put("linux","pretty nice"); 
   staticDscTable.put("berkley","pretty nice too"); 
   staticDscTable.put("windows","unknown OS. please reboot"); 
}
}
//доступ:
String s = BlaBla.staticDscTable.get("linux");

Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 class  BlaBla {
    public   static   final  String linux = "pretty nice"; 
    public   static   final  String berkley= "pretty nice too"; 
    public   static   final  String windows= "unknown OS. please reboot"; 
}
//доступ:
String s = BlaBla.linux;

какая то странная прога её для виндов перекомпилять нада???? решение вроде принимается исходя из значения runtime ?
NotGonnaGetUs
Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}.
Что меня радует так это:
- кратность нотации без потери статической типизации,
- вывод типов (фактически возможность локально применять duck typing),
- возможность делать больше проверок при компиляции средствами языка (таже валидация sql),
- паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений,
- оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека)
круто, рад за вас.... нахер всё это. дайте жабу да будет свет!!!

NotGonnaGetUsСмеха ради, почитайте как используются ущербные лямбды в DLINQ'е. всё бросил и пошёл читать ... буду как приду
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219350
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
expp

NotGonnaGetUs2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит. такое изощрение лечиться wildcardами или сразу regexpами



Такое изощрение лечить не надо.
Нужно лечить того, кто для определения типа ОS по имени предалагает вместо класса содержащего простой метод (вроде s.equals("Linux") || s.equals("SunOS")) что-то параметризовывать и интерпретировать (да ещё с регэкспами).

expp

NotGonnaGetUs
Т.е. появляется дублирование.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
 static   final  String pretty_nice="...";
 static   final  String pretty_nice_too="...";
....
 static {
   staticDscTable.put("SunOS",pretty_nice); 
   staticDscTable.put("Linux",pretty_nice); 
...
}


Осталось привести код, как избавиться от дублирования в случае с "anotherDscTable"... чтобы понять всё удобство использования map вместо полиморфизма.


expp
Collections.unmodifableMap и воьще поставить с default доступом

Круто...

expp
NotGonnaGetUs4. Грузить из файла? Зачем?! а вот это помоему действительно нужный функционал - конфигурировать прогу неперекомпиляя её. во всяком случае очень много людей думают так же

Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно.


expp
NotGonnaGetUs
Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат?

нет каждая DescistionTable имеет свой IEqulizer.

Я привёл пример, когда одним equlizer'ом не обойтись. Только не надо опять об регэкспах.

expp
NotGonnaGetUs
А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ? да. при извратской логике доступ по ключу не нужен - просто список пар.

"Извратской" и трудно реализуемой данная логика становится только при использовании вашего решения. В приводившихся выше вариантах это совсем не проблема.

expp
NotGonnaGetUs
А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой?
Моделировать средствами ООЯзыков паттерны процедурных языков - это круто...
пишу буквами побольше ни нужен тут этот рукав (полиморфизм)

Ну так обоснуйте...

expp
NotGonnaGetUs
А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма". Анекдот в том, что все эти dsl-и, плагины и десишин мапы приводят к коду обладающими всеми недостатками динамически типизированных языков и практически никаким плюсам. анекдот очень смешной. полиморфизм штука статическая. задача проще решать как динамическую.

Что-то не пойму в каком смысле вы используете слова статическая/динамическая.
Полиморфизм - шутка "динамическая", т.к. вызов метода происходит на основе рантайм информации, и к статической/динамической типизации отношения не имеет.

Почему вам проще связать таблицу с интерпретируемым языком вместо того, чтобы написать один класс - не знаю. А ещё говорили, что код на динамичеки типизируемых языках "отстрел ног"...


expp

NotGonnaGetUs
Мы не "конфиг" пишем.

повторюсь. это и есть конфиг, нах.

Неа. Это не конфиг. Это вывод сообщения в зависимости от типа ос/цвета шерсти кролика/чего угодно другого.

Не забывайте, что начали мы с замены гирлянды if/else на что-то нибудь более подходящее.
Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут?

Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках.
Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще.

Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно.


expp

NotGonnaGetUsЗря статик мапы держали. Вместо:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 class  BlaBla {
 public   static  Map<String,String> staticDscTable =  new  HashMap<String,String>();
 static {
   staticDscTable.put("linux","pretty nice"); 
   staticDscTable.put("berkley","pretty nice too"); 
   staticDscTable.put("windows","unknown OS. please reboot"); 
}
}
//доступ:
String s = BlaBla.staticDscTable.get("linux");

Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 class  BlaBla {
    public   static   final  String linux = "pretty nice"; 
    public   static   final  String berkley= "pretty nice too"; 
    public   static   final  String windows= "unknown OS. please reboot"; 
}
//доступ:
String s = BlaBla.linux;

какая то странная прога её для виндов перекомпилять нада???? решение вроде принимается исходя из значения runtime ?


Слава богу. А то, я уж грешным делом подумал, что вы всё и всегда кладёте в статик мапы.

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

При любом раскладе не могу понять почему interface, содержащий набор getter'ов, классы реализации для разных OS и фактори метод (для получения подходящей реализации интерфейса) будут хуже для конфигурирования приложения, чем десишин мап, через который можно выбрать мап, в котором лежат какие-то пары значений (и для ключей которых наверняка заведены константы)...

expp

NotGonnaGetUs
Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}.
Что меня радует так это:
- кратность нотации без потери статической типизации,
- вывод типов (фактически возможность локально применять duck typing),
- возможность делать больше проверок при компиляции средствами языка (таже валидация sql),
- паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений,
- оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека)
круто, рад за вас.... нахер всё это. дайте жабу да будет свет!!!

Нахер? Всё? Точно? :)
Вот и поговорили.

expp
NotGonnaGetUsСмеха ради, почитайте как используются ущербные лямбды в DLINQ'е. всё бросил и пошёл читать ... буду как приду
%)
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219495
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs

Извините за офтопик... а почему nemerle а не groovy?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219536
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
------>>> как избавиться от дублирования в случае с "anotherDscTable"...
надо на неё посмотреть чем она another ... в крайнем случае putAll()
------>>> Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно.
угу. вот сложность то - дёрнуть Property

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

----->>>Почему вам проще связать таблицу с ...
Ну сложилось так. просто и всё

----->>>Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут?
В ФАЙЛЕ ПИШЕМ МАПУ ось1=решение ос2=решение ос*=решение_с_wildcardой, что не понятно???

----->>>Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках.Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще.
ДА НЕ ЭТИ ЗАДАЧИ ОН РЕШАЕТ!!! это просто подходящее решение этой задачи - на любом языке.

----->>>Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно.
нафига тогда её туда выносят???

----->>>Вы создавали на каждое проперти по статик мапе? Или у вас была статик мапа с единственным проперти, которое само по себе было мапа?
убился ап текст ... ещё раз. Есть Descisioner c интерфейсом которого и работает клиент - даёт ему значение из системного окружения, берёт от него решение. Больше его ничего не волнует. Самая простая реализация Descisionerа использует статичну мапу, другая грузит таблицу из файла. Этим достигается разделение кода и данных

к сожалению иногда выходят новые ОСы , и примерно после того как ваша прога с лапшой откомпилирована и установлена. Что проще перехреначить лапшу, впендюрить новый класс или добавить строчку в конфиг. То же самое справедливо и для чуваков на суппорте - тех у кого есть исходники, даже им по моему проще в мапу внести новую пару

вот и потрепались
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219659
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
expp------>>> как избавиться от дублирования в случае с "anotherDscTable"...
надо на неё посмотреть чем она another ... в крайнем случае putAll()

Как чем another... Там решения другие принимаются в зависимости от типа ос.

putAll куда писать?

expp
------>>> Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно.
угу. вот сложность то - дёрнуть Property

----->>>Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут?
В ФАЙЛЕ ПИШЕМ МАПУ ось1=решение ос2=решение ос*=решение_с_wildcardой, что не понятно???

----->>>Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно.
нафига тогда её туда выносят???

Есчо рас. Мы изначально говорили о лапше if/else. Вы всё сводите к задаче конфигурации.

Смотрим на два фрагмента кода:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 if  (s.equals(...)) {
     methodA(x);
}  else   if  (s.equals(...)){
     methodB(x, y);
}  else  ...

 if  (s.equals(...)) {
   sytem.out.prinln("A");
}  else   if  (s.equals(...)){
   sytem.out.prinln("B");
}  else  ...

Как тут обойтись десишин мапами с любый хитрости икволайзерами?
Как инициализировать мапы и при этом не дублировать код?
Да, и зачем всё это сохранять в файл?

expp
----->>>Почему вам проще связать таблицу с ...
Ну сложилось так. просто и всё

Т.е. просто "вредная" привычка? 6)

expp
----->>>Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках.Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще.
ДА НЕ ЭТИ ЗАДАЧИ ОН РЕШАЕТ!!! это просто подходящее решение этой задачи - на любом языке.

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


expp
----->>>Вы создавали на каждое проперти по статик мапе? Или у вас была статик мапа с единственным проперти, которое само по себе было мапа?
убился ап текст ... ещё раз. Есть Descisioner c интерфейсом которого и работает клиент - даёт ему значение из системного окружения, берёт от него решение. Больше его ничего не волнует. Самая простая реализация Descisionerа использует статичну мапу, другая грузит таблицу из
файла. Этим достигается разделение кода и данных


к сожалению иногда выходят новые ОСы , и примерно после того как ваша прога с лапшой откомпилирована и установлена. Что проще перехреначить лапшу, впендюрить новый класс или добавить строчку в конфиг. То же самое справедливо и для чуваков на суппорте - тех у кого есть исходники, даже им по моему проще в мапу внести новую пару


Ок, ещё раз.
Поговорим о конфигурации приложения.
В зависимости от типа ос (o1, o2, o3) могут настриваться несколько параметров (p1, p2, p2).
Как это сделать при помощи мап?

Вижу один вариант:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
map o1p = (p1, v11), (p2, v12), (p3, v13)
map o2p = (p1, v21), (p2, v22), (p3, v23)
map o3p = (p1, v31), (p2, v32), (p3, v33)

bool isO1(osName) ...
bool isO2(osName) ...
bool isO3(osName) ...
 
map descisioner = (isO1, o1p), (isO2, o2p), (isO3, o3p)

map p = descisioner.findBy(osName); 

p.get("p1");
p.get("p2");
p.get("p3");
все обращения к p1,2,3 идут через захардкоженный строки или через константы.


Как это сделать по-человечески:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
 interface  P {getP1, getP2, getP3};
 class  o1p { isO1{}, getP1 { return  v11;} getP2 { return  v12;} getP3 { return  v13;} }
 class  o2p { isO2{}, getP1 { return  v21;} getP2 { return  v22;} getP3 { return  v23;} }
 class  o3p { isO3{}, getP1 { return  v31;} getP2 { return  v32;} getP3 { return  v33;} }

 class  Factory { P getP(osName) }

p = Factory.getP(osName);

p.getP1();
p.getP2();
p.getP3();
все обращения к p1,2,3 идут через стандартный интерфейс, который является "халявной" документацией и избавляет от проблем при переименовании имён параметров и т.п. рефакторингов.

Нужно вынести конфигурацию за пределы приложения?
Вместо "регэкспов" прописываем в конфиг файла имена классов o1p/o2p/etc, среди которых будет искаться подходящая реализация (читает конфиг фактори).

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

Где я не прав, говоря, что полиморфизм тут более чем уместен?
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219679
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUsСмотрим на два фрагмента кода:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 if  (s.equals(...)) {
     methodA(x);
}  else   if  (s.equals(...)){
     methodB(x, y);
}  else  ...

 if  (s.equals(...)) {
   sytem.out.prinln("A");
}  else   if  (s.equals(...)){
   sytem.out.prinln("B");
}  else  ...


Во избежание не понимания: Это два блока 100% аналогичных друг другу if/else, различающихся только выбором действия.
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34219766
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пы-лять ... чо за склонность к изврату.

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

я говорю
1. как быдлокодера меня не скребёт сама логика принятия решения. я делаю дырку для припендюривания разных логик и забываю оп этом.
2. быдлокодера налепившего ифов придётся порешить при попытке в них разобриться или существенно прорефакторить каркас - например переделать решение в <код, строка>
3. быдлокодера налепившего для каждого case'а класс нужно сдать в html дизайнеры где он сможет раскрыться в css

говно вопрос и трёп закончен
...
Рейтинг: 0 / 0
Объектно-ориентированный vs хакерский подход к программированию
    #34224640
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppпы-лять ... чо за склонность к изврату.

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

Не надо истерии.

Задача состояла в другом: показать как может выглядять решение в ОО-стиле и чем оно будет лучше/хуже решения в "процедурном" стиле.

Очевидные этапы решения:
1. Определение типа ОS по имени
2. Выбор действия в зависимости от типа OS.
3. Выделение и изоляция алгоритма определения типа OS (обеспечение точки расширения)

if/else при водит к ребусу, в котором все эти действия соединены воедино.
Маp - ещё больше запутывает решение, т.к. приводит к большому количеству "если" разрешаемых только в runtime (в отличии от легко верифицируемого набора if/else). А когда дело доходит до дублирования структуры if/else, map'ы, в общем случае, оказываются ещё хуже (я приводил примеры (anotherMap, etc)).

Ясное (как день) описание каждого из этапов в ОО-нотации почему-то приводит вас в ужас.

expp
я говорю
1. как быдлокодера меня не скребёт сама логика принятия решения. я делаю дырку для припендюривания разных логик и забываю оп этом.

А кому-то потом приходится вспоминать и ругаться матом автора дырки, потому что логики приходится именно "впендюривать" :)

expp
2. быдлокодера налепившего ифов придётся порешить при попытке в них разобриться или существенно прорефакторить каркас - например переделать решение в <код, строка>

Вы всё-таки определитесь: все if'ы заменять на мапы и выносить ветки в конфигурационные файлы, или только те, где действительно производится конфигурация приложения? :)

expp
3. быдлокодера налепившего для каждого case'а класс нужно сдать в html дизайнеры где он сможет раскрыться в css

А налепившего на каждый case' по десишн мап куда надо сдать? В perl-программисты? :)

exppговно вопрос и трёп закончен
Если бы вы не трепались, а проявили больше конструктива, то вопрос не стал бы гавном :)
...
Рейтинг: 0 / 0
75 сообщений из 75, показаны все 3 страниц
Форумы / Java [игнор отключен] [закрыт для гостей] / Объектно-ориентированный vs хакерский подход к программированию
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]