Помогите мне с моим ООП

Духовность™

Продвинутый новичок
Помогите мне с моим ООП

Привет.
Я написал "класс для работы с администратором". Вот он: http://phpclub.ru/paste/index.php?show=1938

Но у меня есть сомнения насчет правильности этого решения.

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

Класс имеет общую форму

PHP:
class admin 
{
    // конструктор - получить данные админа из БД 
    // в соответствии с куками `cookie_id_admin` и `cookie_admin_hash`

    // метод 1 - получить значение 1
    // метод 2 - получить значение 2
    // и т.д.

    // метод проверки прав
}
изначально в класс были добавлены методы типа setName(), setLogin(), setPassowrd() и т.д.
но потом я понял, что эти методы мне не нужны - их никто никогда вызывать не будет! А все админы редактируются через другой скрипт, который к данному методу вообще отношения не имеет!

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

PHP:
$adminObj = new Admin($db);

if (!$adminObj->getId())
{
    // авторизация нужна 
}
else
{
    // работаем в админе 
}
??? :confused: :( :cool:
 
я не могу понять - что я написал?
Это не сюда :)
Правильно ли я написал этот класс?
С точки зрения синтаксиса - да, а юзабалити - это уже Ваши проблемы
Ведь, насколько я понимаю, это не ООП
Это - ООП

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

StUV

Rotaredom
triumvirat
ооп ради ооп - зло
написать 100 строк кода, а потом задаться вопросом "зачем?* - разве не кажется нелогичным? =)
 

IIIEPJIOK

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

Духовность™

Продвинутый новичок
"блокировка разработки из-за анализа" — ситуация, при которой реализа-
ция приложения откладывается на неопределенное время из-за бесконечного
поиска наилучшего решения
я этим болею уже несколько лет -- свою CMS так пишу ((

Спасибо.
 

Pingvin22

Новичок
Автор оригинала: IIIEPJIOK
Термин есть какой-то, когда из-за того, что программист сильно уходит в рефакторинг, проект стоит.(ща пойду книги рыть)

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

Xeon303

Новичок
По-моему, автору темы следует лучше разобраться в ООП, потому что неправильное применение и вызывает вопросы типа "А зачем оно всё, что я написал?". Почему так сложно писать осмысленный код? Почему бы не реализовать класс User со всеми необходимыми методами, добавив к нему свойство admin = true | false? Или поступить по-другому: реализовать класс Admin наследником User.

Мне кажется, если использовать технологии (в данном случае ООП) по назначению, то эффективность возрастет в несколько раз. Не говоря о том, что пропадут вопросы "Зачем это?", "Почему я так сделал?" и т.д. Наверное, лучше дрелью сверлить дырки, а не забивать гвозди...
 

StUV

Rotaredom
использовать технологии (в данном случае ООП) по назначению
для этого необходимо по крайней мере книжки читать
учиться программированию на примере чужих исходников без фундамента базовых знаний - просто глупо
как и в любой другой деятельности
 

Духовность™

Продвинутый новичок
Почему бы не реализовать класс User со всеми необходимыми методами, добавив к нему свойство admin = true | false? Или поступить по-другому: реализовать класс Admin наследником User.
это все понятно... в контексте моей задачи я не знаю как правильно реализовать класс. см. мое первое сообщение

Тоже болею этим почти год в понедельник из за этого с работы уволили...
можно поподробнее про это?
 

Pigmeich

Новичок
Автор оригинала: A1x
тогда выходит "хорошее враг лучшего" :)
это нетранзитивное отношение

-~{}~ 06.12.07 10:43:

triumvirat
э-э, чтобы такого посоветовать? Нужен обучающий проект.

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

Вот еще креш-курс "бездумного программирования" - тоже иногда помогает когда жаба правильности душит:
http://pigmeich.livejournal.com/3771.html
 

A1x

Новичок
Автор оригинала: Pigmeich
это нетранзитивное отношение
да правильно. но походу симметричное

triumvirat
надо пойти выпить пива. в смысле отвлечься на что-то другое и расслабиться.
иногда в такие моменты приходят отличные идеи
 

phpdev2007

Новичок
налицо то что нету методологии программирования, автору посоветую почитать про tdd
После понять нужно всегда программировать так что решать конкретные бизнес задачи, тут опоминались cms которые пишутся год, и еще наверное будут писаться столь коже (или бесконечность), я больше чем уверен что в данных cms нет тз, есть только идея, и так же сто процентов нет часового плана выполнения тз, если даже оно есть.
 

Pigmeich

Новичок
phpdev2007
Какое отношение имеет TDD к дизайну? Use Cases - это не совсем TDD.
 

phpdev2007

Новичок
Pigmeich
а думаете не имеет? вообще ни какого и рефлакторинг ну никак не влияет на дизайн кода?
 

Pigmeich

Новичок
phpdev2007
TDD к Adaptive Design никакого отношения не имеет и с Рефакторингом не связан.

Synergy есть, но просто от введения TDD дизайн ну никак улучшиться не может.

-~{}~ 07.12.07 02:08:

Представь что у тебя есть "Запорожец" этак 70-го года выпуска. От того что ты затонируешь окна и прилепишь красивые наклейки запор не станет ездить со скоростью за 150 км/ч.
 

whirlwind

TDD infected, paranoid
Какое отношение имеет TDD к дизайну? Use Cases - это не совсем TDD.
Объясняю что такое TDD и какое отношение оно имеет к дизайну. Тест, который пишется сначала, отвечает на вопрос что делает. Если ты не можешь написать тест (то есть ответить на вопрос что делает), значит этот класс в проекте не нужен и можно спокойно переключаться на другую задачу. Непосредственно тестируемый класс отвечает на вопрос как делает, то есть каким образом достигается тот результат, что описан в тестах. Исходя из этого, начинать проектировать класс нужно глядя на результат, который мы хотим получить, а не на то, что "мне кажется было бы неплохо написать еще один класс".

введения TDD дизайн ну никак улучшиться не может.
Может мы по разному понимаем что такое дизайн, но вообще TDD заставляет правильно проектировать классы: использовать композицию, подводит к использованию паттернов, и т.п.. ИМХО это достаточно тесно связано с дизайном, нет? Я конечно не спорю, что и с TDD можно такого нагородить, что ахнешь. Но все таки это уже не бездумная писанина - что вижу то и пишу.

PS. Знакомиться с TDD однозначно нужно каждому уважающему себя разработчику. Преимуществ огромное множество. Все минусы и "страшилки" с лихвой компенсируются результатом.
 
Сверху