>не инкапсулирует. убрать из реализации переменную типа int (или любую сущность, семантически ей эквивалентную) при неизменном интерфейсе уже нельзя
Кто-то утверждает, что X в интерфейсе это именно мембер реализации? Если да, то это конечно бред, даже не представляю кому может придти в голову такое.

Что тогда можно?

твою же дивизию, где я говорил что что-то нельзя, а что-то можно? ну? где?

class A
{
public:
A(int *x): x_(x) {}

int getX() const { return *x_; }
void setX(const int x) { *x_ = x; }
private:
int *x_;
};

или

class A
{
public:
int getX() const { int x; cin >>x; return x; }
void setX(const int x) { cout << x; }
};

В обоих случаях интерфейс(int getX(), void setX(const int x)) не поменялся, поменялась лишь реализация.

Кто-то утверждает, что X в интерфейсе это именно мембер реализации?

переменную типа int (или любую сущность, семантически ей эквивалентную)

а если было принято решение, что переменная x больше не нужна? что реализация может обойтись без неё? что тогда ты сделаешь с интерфейсом getX/setX? чем он будет заниматься?

«X» как правило это не абстрактное «X - просто мембер», а всё же предметная область. Если «X» нет в предметной области, его никто открывать и не будет, ибо бред сивой кобылы.

jtootf просто гонит

Если «X» нет в предметной области, его никто открывать и не будет, ибо бред сивой кобылы.

судя по этим двум тредам, всё намного запущеней

jtootf просто гонит

ну ты просто сражаешь наповал аргументацией

getX/setX создавались с учетом того, что X будет всегда. То что временно нужно как то абстрагировать по другому

> ну ты просто сражаешь наповал аргументацией

Как еще реагировать? Люди разработали класс с фиксированным неизменным API, оно составляет эти геттеры и сеттеры. А внутри может быть _x или нет, это не важно. Вот это называется инкапсуляция. Вы рассказываете что нет, «инкапсуляция - это что-то еще но я не скажу что»

В предметной области есть понятие «позиция» и нужно сделать интерфейс для получения и установки этой позиции. setX и getX нельзя? Что тогда можно?

кстати, хороший пример. если в предметной области есть понятие «позиция», то и в интерфейса должно фигурировать именно оно. а задаётся она двумя координатами типа int, или double, или тремя, или одним значением угла поворота - это уже неважно

getX/setX создавались с учетом того, что X будет всегда

если писать «с учётом что %something% будет всегда», то никакая абстракция вообще не нужна. ни функциональная, ни данных, ни объектная. мы же сразу всё знаем, зачем нам лишние сложности?

затем что setX и getX будут всегда, но сейчас они в переменной, завтра в БД, а послезавтра хранятся на сервере с вебсервисом. Вуаля, инкапсуляция

Вы рассказываете что нет, «инкапсуляция - это что-то еще но я не скажу что»

у кого из нас проблемы со зрением?

http://www.linux.org.ru/jump-message.jsp?msgid=4493849&cid=4495683

Люди разработали класс с фиксированным неизменным API, оно составляет эти геттеры и сеттеры

в прошлом треде я давал ссылки на статьи Голуба и Фаулера на тему why getters violate encapsulation. если ты считаешь, что это лично моё мнение - иди туда и критикуй их

затем что setX и getX будут всегда

да с какой радости они будут всегда? что за детский сад?

>кстати, хороший пример. если в предметной области есть понятие «позиция», то и в интерфейса должно фигурировать именно оно. а задаётся она двумя координатами типа int, или double, или тремя, или одним значением угла поворота - это уже неважно
А в сущности «позиция» можно поэлементно задавать или нет? А если сущность из одного элемента? И вам не кажется, что попахивает странным из всего обязательно делать отдельные сущности?

А в сущности «позиция» можно поэлементно задавать или нет?

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

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

нет. это всего лишь стремление не допустить утечек абстракции

[quote]а если было принято решение, что переменная x больше не нужна? что реализация может обойтись без неё?[/quote]

Если переменная не нужна то я её уберу.

[quote]что тогда ты сделаешь с интерфейсом getX/setX? чем он будет заниматься?[/quote]

Зависит от конкретного случая.

PS: А интерфейс всетаки иногда приходится менять.

>а это уже другой вопрос, не имеющий отношения к делу. в том и прелесть, что варьировать эту сущность мы теперь может совершенно свободно
Ну мне интересно, имею я право в сущности «Позиция», сделать getX/setX или это снова порушит всю инкапсуляцию?

Если переменная не нужна то я её уберу.

ну так и что ты сделаешь с getX/setX? заменишь на stub'ы, пустые методы? вырастишь огород из костылей?

А интерфейс всетаки иногда приходится менять.

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

и менять его в таком случае придётся реже

Ну мне интересно, имею я право в сущности «Позиция», сделать getX/setX или это снова порушит всю инкапсуляцию?

зависит от проекта. в случае с данным примером я бы сделал позицию обыкновенной плоской структурой

> да с какой радости они будут всегда?

А почему бы и нет. Мы же не говорим о конкретном классе. Не знаю о чем вы, но я говорил о том что если у обьекта есть свойство Х, то то где оно хранится нужно инкапсулировать путем определения геттеров и сеттеров согласно рекомендации Sun. Внутреннее место хранения надо скрыть. Проще всего это делается элементом меню Incapsulate fields в Netbeans

в прошлом треде я давал ссылки на статьи Голуба и Фаулера на тему why getters violate encapsulation

Надо вам поискать статьи Иванова, Петрова и Сидорова, они считают по другому ))

Честно говоря в любом учебнике по Java написано, что геттеры и сеттеры - инструменты инкапсуляции, без всякого теоретизирования вместе с какими-то докторами, которым нужно публиковаться для удержания степени

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

сказал джавист про Фаулера. ничего так, доставляет :)

> ну так и что ты сделаешь с getX/setX? заменишь на stub'ы, пустые методы? вырастишь огород из костылей?

Если говорить конкретно о позиции, то для хорошей инкапсуляции таки необходим класс Position, у которого определены публичные геттеры для X и Y, ибо они нужны для рисования. Задание же позиции может быть или в субклассах или в конструкторах класса Position. Задаваться они могут и полярно и как угодно

Если говорить конкретно о позиции, то для хорошей инкапсуляции таки необходим класс Position

*выдохнул* да здравстует здравый смысл!

Осиливать тред с витьеватым смыслом было сложно. Начал читать как раз с примера с кодом, подумал что там говорят без привязки к конкретной задаче, просто свойство Х

>ссылки на статьи Голуба и Фаулера на тему why getters violate encapsulation

Cool! Could you please post these links here again? I've missed that thread.

Представим ситуацию, нужно поменять позицию курсора только по X. Что нам делать? Запросить объект «позиция», записать туда новое X и предать в «курсор»? Не будет ли затрат производительности не только при этих операциях копирования, но и при вызове метода «курсора» изменить позицию?

зависит от проекта. в случае с данным примером я бы сделал позицию обыкновенной плоской структурой

И обречь себя на то, что открыта внутренняя организация(имена полей(я хочу называть их по-своим правилам, размер, порядок следования и пр.))? Если я захочу метод сравнения позиций в структуре, то она уже будет не POD и открытая спецификация внутренней организации тогда станет ахтунгом.

ну так и что ты сделаешь с getX/setX?

Поменяю реализацию. А если была допущена ошибка в проектировании интерфейся то поменяю и его.

Возьмём ещё пример: бинарные компоненты. Там открытый доступ к полям есть полнейший ахтунг.

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

что же касается затрат производительности, то всегда существует баланс между производительностью и гибкостью системы. на этапе активного развития проекта предпочтительней гибкость, т.к. premature optimization is the root of all evil

А если была допущена ошибка в проектировании интерфейся то поменяю и его

интерфейсы так просто не меняются, увы

нтерфейсы так просто не меняются, увы

Это уже тема для другого разговора, увы.

Cool! Could you please post these links here again? I've missed that thread.

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

http://martinfowler.com/bliki/GetterEradicator.html

you're welcome

Это уже тема для другого разговора, увы.

никоим образом :) однако если есть такая точка зрения, я буду рад её выслушать

Окончательный вариант

package pkg;
import java.awt.Graphics;
import java.awt.Polygon;

import javax.swing.JFrame;

public class MyClass extends JFrame
{
	private static final long serialVersionUID = 1L;
	
	public Polygon star(int x,int y,int n, double r1,double r2) 
	{
		
		 /* 
		 * x ,y   - координаты центра звезды
		 * r1,r2  - внешний и внутренний радиус
		 * n      - количество вершин звезды
		 */
		
		// вычисления координат вершин
		double a=Math.PI/n , r=r1 , rnext=r2 , temp ;
		Polygon p = new Polygon ();
		int i ;
		for (i=1;i<=(2*n);i++)
		{
			p.addPoint( x+(int)(r*Math.sin(a*i)), y-(int)(r*Math.cos(a*i)) ) ;
			temp=r;r=rnext;rnext=temp;
		}
		return p ;
	 }
	
	// -------------------------------------
	public void paint(Graphics g) 
	{
		Polygon p1 = new Polygon ();
		Polygon p2 = new Polygon ();
		Polygon p3 = new Polygon ();
		Polygon p4 = new Polygon ();
		
		p1 = star (80,80,7,10.5,40.5);
		p2 = star (160,80,5,15.5,50.67);
		p3 = star (80,200,9,10.9,70.45);
		p4 = star (280,280,3,40.5,120.6);
		g.drawPolygon(p1);
		g.drawPolygon(p2);
		g.drawPolygon(p3);
		g.drawPolygon(p4);
		
	}
	
	
	public static void main(String[] args) 
	{
		MyClass gd = new MyClass();
		// Определяем заголовок окна
		gd.setTitle("Для Ъ :)");
		// Определяем размер окна
		gd.setSize(400, 400);
		// Запрещаем пользователю изменять размеры окна
		gd.setResizable(false);
		// Определяем, что при закрытии окна заканчивается работа
		// программы
		gd.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		// Делаем окно видимым
		gd.setVisible(true);


	}

}

как правило, так не пишут

p1 = star (80,80,7,10.5,40.5);

из названия star непонятно, что метод возвращает новый объект. Назови его createStar или что-то типа такого.

Спасибо!