|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Рассудите спор двух коллег. Пример такой. Есть 3 формы с 1ой кнопкой на каждой форме. При нажатии на кнопку на любой форме Background меняет цвет (то есть выполняется одна и таже функция). Можно ли вынести эту функцию в отдельный Модуль или правильнее будет написать один и тот же код в каждой форме 3 раза? В жизни этот код может быть 100-200 итд строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 14:37 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем Gили правильнее будет написать один и тот же код в каждой форме 3 раза?В Button1_Click ? Код на "100-200 итд строк"? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 14:44 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем G, Лучше а одно место, потом "зае..сь пыль глотать бегая по судам" (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:13 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GМожно ли вынести эту функцию в отдельный Модуль или правильнее будет написать один и тот же код в каждой форме 3 раза? В жизни этот код может быть 100-200 итд строк. А какие тут могут быть рассуждения? Ну, какие аргументы со стороны "против выноса в отдельный модуль"? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:18 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем G 3 раза? Уже использование 2 раза - причина обьединить. Но! код коду рознь - плодить классы-усыновители некритичных для бизнеса функций - а кто ими будет пользоваться потом? Создание всевозможных "Util" и хелперов - совсем не хорошо. Я бы подумал о создании "абстрактного" базового класса. Наследование все-таки надежней говорит, что функция подходящая. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:19 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Против: Нарушение ОПП За: Повышение читабельности, повторное использование. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:20 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GПротив: Нарушение ОПП Какой принцип ООП нарушается? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:25 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
PallarisАртем GПротив: Нарушение ОПП Какой принцип ООП нарушается? Инкапсуляция. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:28 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
D129Pallarisпропущено... Какой принцип ООП нарушается? Инкапсуляция. Поясни. Был создан метод, который на основе некоторых параметров предлагает новый цвет. Где нарушена инкапсуляция? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:31 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Pallaris, Логика выноситься человеком из класса в модуль. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:40 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GPallaris, Логика выноситься человеком из класса в модуль. И что? Создал класс-хэлпер, который реализует некоторую логику. Далее класс-форма может либо пользоваться методом этого класса, либо нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:42 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Добавлю в догонку. Логика выноситься человеком из класса в модуль для того, чтобы использовать потом эту логику еще раз в другой форме. Ну и + типа в классе формы и так много событий и получается длинная портянка из кода... таким образом приводиться довыд в сторону читабельности. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:42 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
PallarisАртем GPallaris, Логика выноситься человеком из класса в модуль. И что? Создал класс-хэлпер, который реализует некоторую логику. Далее класс-форма может либо пользоваться методом этого класса, либо нет. Вот тот же довыд приводит и коллега. Мол и что? Поэтому и вопрос. Кто прав? Почему прав? и хотелось бы услышать кто-нибудь делает так у себя в проектах. Заранее спасибо за Ваши ответы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:47 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GПоэтому и вопрос. Кто прав? Почему прав?. SOLID (object-oriented design) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:49 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GPallarisпропущено... И что? Создал класс-хэлпер, который реализует некоторую логику. Далее класс-форма может либо пользоваться методом этого класса, либо нет. Вот тот же довыд приводит и коллега. Мол и что? Поэтому и вопрос. Кто прав? Почему прав? и хотелось бы услышать кто-нибудь делает так у себя в проектах. Заранее спасибо за Ваши ответы. - Ребе, что мне делать? У меня есть один петушок и одна курочка. Если я зарежу курочку, обидится петух. Если зарежу петуха, обидится курочка. Раввин долго размышляет, потом сообщает свое решение: – Режь петуха! – Но тогда курочка обидится! – Ну и пусть обижается! ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:49 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
PallarisПоясни. Был создан метод, который на основе некоторых параметров предлагает новый цвет. Где нарушена инкапсуляция? Если этот метод static public, а используется для того, чтобы поменять цвет форме. Причем, если он просто возвращает цвет - это еще туда-сюда, а если там сложный код, и для того, чтобы поменять нужны операции с самой формой, и ему дают форму (ссылку на) как параметр.... Я много раз сталкивался в чужих проэктах, с "Tools" , "Utils", "Helpers" - которые содержат статические функции, полезные для чего-то, а вот то, что они подойдут мне - судить по одному названию тяжело. A форму свою я куда попало посылать не хочу, мало ли чего с ней сделают... А вот когда я нахожу функцию в базовом классе - тут я уверен, что она все сделает правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:53 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
D129A форму свою я куда попало посылать не хочу, мало ли чего с ней сделают... Не, объявление метода такое: Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 15:59 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
PallarisАртем GПоэтому и вопрос. Кто прав? Почему прав?. SOLID (object-oriented design) Почитаем. Ясности не добавило ( ввиду отсутствия прямых ответов ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 16:53 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GДа.Ну это же хрень. Обработчики должны быть лёгкими :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 17:32 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
skyANAАртем GДа.Ну это же хрень. Обработчики должны быть лёгкими :) Да согласен. Но в данном контексте это не суть важно. Я поднял вопрос не из праздного любопытства. Хотелось бы услышать конкретный, короткий ответ. Вот по сути тот же пример... но с другими сущьностями. Есть класс OrderRepository. Где есть метод Add. И вдруг "разработчик" по каким-то причинам решает что логика в методе Add класса OrderRepository слишком длинная, и тут его еще осеняет что она похожа на логику в методе Add класса StudentRepository. И тут у него возникает желание вынести этот большой да еще и повторяющийся кусок кода в МОДУЛЬ Этому "разработчику" нравиться что не нужно объявлять переменную, а просто пишешь название модуля и появляется функция (похоже на static class) По мне такое можно написать не зная теории aka матчасти. Почему я против был такого выноса логики отдельно в модуль. Возьму пример на зверях. Есть жираф. У него голова, ноги, хвост. Он может жрать и срать. Бегимот имеет тоже самое и делает тоже самое. МОй коллега пытается вынести сранье жирафа только потому что это слишком сложный процесс у жирафа, добавляя при этом что бегимот тоже срет... и процессы у них схожи. ПО моему ОПП нам говорит что описывать сранье нужно у каждого в своем классе - это часть логики инкапсуляции. Вот как то так... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 21:54 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем G ПО моему ОПП нам говорит что описывать сранье нужно у каждого в своем классе - это часть логики инкапсуляции. Еще говорят, что у класса должна быть своя область ответственности. Поэтому, если наш жираф срет золотом, то не ему нужно его нести в банк ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 22:08 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
Артем GВот как то так... Я бы сказал так по поводу повторяющегося кода - лучше его не повторять. Потому что завтра ты решишь его оптимизировать, как ты будешь вспоминать, где он у тебя еще используется? А вот какой подход применять - наследование, или отдельный модуль, - это вопрос другой. Если класс начинает лезть не в свое дело, повторяющийся код не слишком запутан и не требует кучи ссылочных объектов - то модуль (как пример с формой и свойством бэкграунд). Если же имеется незначительное отличие в поведении схожих сущностей (как пример с репозиторием) - то наследование. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 22:20 |
|
Вынос кода в отдельный модуль
|
|||
---|---|---|---|
#18+
PallarisАртем GВот как то так... Я бы сказал так по поводу повторяющегося кода - лучше его не повторять. Потому что завтра ты решишь его оптимизировать, как ты будешь вспоминать, где он у тебя еще используется? По моему это палка о двух концах. Первый. Это ваш пример. Когда нужно повторяющийся код поменять только в одном месте для двух объектов или в 2х местах если он не вынесен в отдельный модуль (но тут я знаю в каких классах мне нужно менять). Второй. Это может сложиться ситуация когда мне нужно изменить код, но только для одного объекта. Вынесенную часть кода придется его разъединить. Студия конечно позволяет быстро найти все нужное по ссылкам над классом / модулем. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2015, 23:35 |
|
|
start [/forum/topic.php?fid=20&msg=38941662&tid=1401607]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
59ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 346ms |
total: | 492ms |
0 / 0 |