привет всем
работаю с java уже давно. Все время работал в одном месте, теперь перейдя на новое понял что пишу код не на хорошем уровне. Т.е код рабочий и с производительностью все в порядке.
Проблемы с Обьектно Ориентированным программированием. Код сложно менять и другим людям сложно с ним работать.
вопрос:
-- как ето дело побороть
-- какие книги , статьи почитать.
Заранее спасибо.
Re: java и Обьектно Ориентированнoе программирование
Здравствуйте, Аноним, Вы писали:
А>работаю с java уже давно. Все время работал в одном месте, теперь перейдя на новое понял что пишу код не на хорошем уровне. Т.е код рабочий и с производительностью все в порядке.
Для начала хорошо бы понять что производительность она очень вторична. Главное простой, читаемый и модифицируемый код. А с таким кодом и производительности и масштабируемости можно добится.
А>Проблемы с Обьектно Ориентированным программированием. Код сложно менять и другим людям сложно с ним работать. А>вопрос: А> -- как ето дело побороть А> -- какие книги , статьи почитать.
Здравствуйте, Аноним, Вы писали:
А> работаю с java уже давно. Все время работал в одном месте, теперь перейдя на новое понял что пишу код не на хорошем уровне. Т.е код рабочий и с производительностью все в порядке. А>Проблемы с Обьектно Ориентированным программированием. Код сложно менять и другим людям сложно с ним работать.
Практикуйте code review. Попросите кого-то из опытных коллег просматривать переодически ваш код и указывать н ошибки в дизайне.
Re: java и Обьектно Ориентированнoе программирование
Здравствуйте, Аноним, Вы писали:
А>привет всем А> работаю с java уже давно. Все время работал в одном месте, теперь перейдя на новое понял что пишу код не на хорошем уровне. Т.е код рабочий и с производительностью все в порядке. А>Проблемы с Обьектно Ориентированным программированием. Код сложно менять и другим людям сложно с ним работать.
К тому, что уже сказали, добавлю свой быстрый тест для определения нужности рефакторинга (в том числе и кода, который еще в голове):
1)Если что-то можно сделать абстрактнее, делай. Не надо объявлять поле через ArrayList, если используются только методы интерфейса List. Объявлять, соответственно, надо List.
2)Если что-то немного похоже на самостоятельную сущность, выделяй ее в самостоятельную сущность.
3)Если код в разных местах хоть немного похож между собой, думай, как его выделить в отдельный метод (но без фанатизма с парой десятков входных параметров).
4)Чем больше метод зависит от состояния объекта, от есть от значений полей объекта, тем сложнее за ним уследить. Соответственно, наиболее простые для восприятия, тестирования, использования и рефакторинга метода — статические (хотя возможно этот пункт является просто моим бзиком на текущий момент).
5)Количество возможных вариантов использования (однотипных сущностей, не знаю как точно выразиться) может быть: ноль, один, много. Например, если на данный момент реализация умеет отправлять только один тип пакетов по сети, но уже просят добавить еще один, надо сразу же закладываться, что типов пакетов может быть неограниченно много. Соответственно, количество состояний может быть: одно, два, много. Или состояние постоянно, или описывается булевской переменной, или их может быть бесконечно много (ну или Integer.MAX_VALUE). Естественно, при первой же прикидки реализации надо задумываться о расширяемости. Случай с отсылкой пакетов потому не очень показательный, так как сразу понятно, что типов пакетов много.
Здравствуйте, Donz, Вы писали:
D>4)Чем больше метод зависит от состояния объекта, от есть от значений полей объекта, тем сложнее за ним уследить. Соответственно, наиболее простые для восприятия, тестирования, использования и рефакторинга метода — статические (хотя возможно этот пункт является просто моим бзиком на текущий момент).
Мысль верная, но выводы ошибочны. Мы вот, наоборот, стараемся статических методов избегать по ряду причин. Это, ведь, уже процедуры, а не методы. Их нельзя переопределить, вынести в интерфейс и пр.
Но проблема идентифицирована верно. Часто толстый метод может использовать кучу полей, но вдруг мы обнаружили, что этот метод можно где-то ещё использовать, где нет этих полей.
Но проблема была не в том что метод не статический. А в том что нарушена инкапсуляция и Single Responsibility Principle. Класс занимался чем-то таким чего делать был не должен. Решением должно быть вынесение метода в соответствующий класс, а не добавление модификатора static.
Re[3]: java и Обьектно Ориентированнoе программирование
Здравствуйте, Blazkowicz, Вы писали:
D>>4)Чем больше метод зависит от состояния объекта, от есть от значений полей объекта, тем сложнее за ним уследить. Соответственно, наиболее простые для восприятия, тестирования, использования и рефакторинга метода — статические (хотя возможно этот пункт является просто моим бзиком на текущий момент). B>Мысль верная, но выводы ошибочны. Мы вот, наоборот, стараемся статических методов избегать по ряду причин. Это, ведь, уже процедуры, а не методы. Их нельзя переопределить, вынести в интерфейс и пр.
В интерфейс можно вынести обертку над этими методами. То же самое и с переопределением.
Проще говоря, если мы можем на данный момент сделать метод статическим, то делаем. Если обнаруживаем, что нам надо переопределить поведение, то вводим обычный метод-обертку, над которым и изголяемся в наследниках. При желании статический метод можно сделать private. Таким образом снаружи все будет выглядеть, как обычно, а внутри все вкусности от статики.
В общем, нравится мне эта парадигма фунционального программирования
Re: java и Обьектно Ориентированнoе программирование
Здравствуйте, Donz, Вы писали:
D>Проще говоря, если мы можем на данный момент сделать метод статическим, то делаем. Если обнаруживаем, что нам надо переопределить поведение, то вводим обычный метод-обертку, над которым и изголяемся в наследниках. При желании статический метод можно сделать private. Таким образом снаружи все будет выглядеть, как обычно, а внутри все вкусности от статики.
У меня чет обратный процесс пошел . Вместо статических методов начал предпочитать спринговые бины синглтоны . Учитывая, что бины аннотациями прекрасно определяются, минусов по сравнению со статиком не вижу, одни плюсы (например влегкую могу мемоизацию на любой метод навесить одной аннотицией).
Re[2]: java и Обьектно Ориентированнoе программирование
