Monday, December 24, 2018
Sunday, December 23, 2018
Um dia a Verdade e a Mentira se encontram
Um dia a Verdade e a Mentira se encontram. A Mentira diz à Verdade: “Hoje está um dia maravilhoso!” A Verdade olha para o céu, desconfiada, e suspira, pois o dia estava realmente lindo. Elas passam algum tempo juntas, chegando finalmente a um poço. A Mentira diz à Verdade: “A água está muito boa, vamos tomar um banho juntas!” A Verdade, mais uma vez desconfiada, testa a água e descobre que realmente está muito gostosa. Elas se despem e começam a tomar banho. De repente, a Mentira sai da água, veste as roupas da Verdade e foge. A Verdade, furiosa, sai do poço e corre para encontrar a Mentira e pegar suas roupas de volta.
O mundo, vendo a Verdade nua, desvia o olhar, com desprezo e raiva. A pobre Verdade volta ao poço e desaparece para sempre, escondendo nele sua vergonha. Desde então, a Mentira viaja ao redor do mundo vestida como a Verdade, satisfazendo as necessidades da sociedade. Porque o mundo não nutre o menor desejo de encontrar a Verdade nua.
Parábola judaica
O mundo, vendo a Verdade nua, desvia o olhar, com desprezo e raiva. A pobre Verdade volta ao poço e desaparece para sempre, escondendo nele sua vergonha. Desde então, a Mentira viaja ao redor do mundo vestida como a Verdade, satisfazendo as necessidades da sociedade. Porque o mundo não nutre o menor desejo de encontrar a Verdade nua.
Parábola judaica
S.O.L.I.D: The First 5 Principles of Object Oriented Design
S.O.L.I.D is an acronym for the first five object-oriented design(OOD)** principles** by Robert C. Martin, popularly known as Uncle Bob.
These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
Note: this is just a simple "welcome to _S.O.L.I.D" article, it simply sheds light on what S.O.L.I.D is_.
All of that logic would be handled by the AreaCalculator class, this is what SRP frowns against; the AreaCalculator class should only sum the areas of provided shapes, it should not care whether the user wants json or HTML.
So, to fix this you can create an SumCalculatorOutputter class and use this to handle whatever logic you need to handle how the sum areas of all provided shapes are displayed.
The SumCalculatorOutputter class would work like this:
A way we can make this sum method better is to remove the logic to calculate the area of each shape out of the sum method and attach it to the shape's class.
Coding to an interface is an integral part of S.O.L.I.D, a quick example is we create an interface, that every shape implements:
Still making use of out AreaCalculator class, say we have a VolumeCalculator class that extends the AreaCalculator class:
To fix this, instead of returning an array from the VolumeCalculator class sum method, you should simply:
ISP says no to this, instead you could create another interface called SolidShapeInterface that has the volume contract and solid shapes like cubes e.t.c can implement this interface:
You can create another interface, maybe ManageShapeInterface, and implement it on both the flat and solid shapes, this way you can easily see that it has a single API for managing the shapes. For example:
Later if you were to change the database engine, you would also have to edit the PasswordReminder class and thus violates Open-close principle.
The PasswordReminder class should not care what database your application uses, to fix this again we "code to an interface", since high level and low level modules should depend on abstraction, we can create an interface:
These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
Note: this is just a simple "welcome to _S.O.L.I.D" article, it simply sheds light on what S.O.L.I.D is_.
S.O.L.I.D stands for:
When expanded the acronyms might seem complicated, but they are pretty simple to grasp.- S - Single-responsiblity principle
- O - Open-closed principle
- L - Liskov substitution principle
- I - Interface segregation principle
- D - Dependency Inversion Principle
Single-responsibility Principle
S.R.P for short - this principle states that:A class should have one and only one reason to change, meaning that a class should have only one job.For example, say we have some shapes and we wanted to sum all the areas of the shapes. Well this is pretty simple right?
class Circle {
public $radius;
public function construct($radius) {
$this->radius = $radius;
}
}
class Square {
public $length;
public function construct($length) {
$this->length = $length;
}
}
First, we create our shapes classes and have the constructors setup the required parameters. Next, we move on by creating the AreaCalculator class and then write up our logic to sum up the areas of all provided shapes.class AreaCalculator {
protected $shapes;
public function __construct($shapes = array()) {
$this->shapes = $shapes;
}
public function sum() {
}
public function output() {
return implode('', array(
"",
"Sum of the areas of provided shapes: ",
$this->sum(),
""
));
}
}
To use the AreaCalculator class, we simply instantiate the class and pass in an array of shapes, and display the output at the bottom of the page.$shapes = array(
new Circle(2),
new Square(5),
new Square(6)
);
$areas = new AreaCalculator($shapes);
echo $areas->output();
The problem with the output method is that the AreaCalculator handles the logic to output the data. Therefore, what if the user wanted to output the data as json or something else?All of that logic would be handled by the AreaCalculator class, this is what SRP frowns against; the AreaCalculator class should only sum the areas of provided shapes, it should not care whether the user wants json or HTML.
So, to fix this you can create an SumCalculatorOutputter class and use this to handle whatever logic you need to handle how the sum areas of all provided shapes are displayed.
The SumCalculatorOutputter class would work like this:
$shapes = array(
new Circle(2),
new Square(5),
new Square(6)
);
$areas = new AreaCalculator($shapes);
$output = new SumCalculatorOutputter($areas);
echo $output->JSON();
echo $output->HAML();
echo $output->HTML();
echo $output->JADE();
Now, whatever logic you need to output the data to the user is now handled by the SumCalculatorOutputter class.Open-closed Principle
Objects or entities should be open for extension, but closed for modification.This simply means that a class should be easily extendable without modifying the class itself. Let's take a look at the AreaCalculator class, especially it's sum method.
public function sum() {
foreach($this->shapes as $shape) {
if(is_a($shape, 'Square')) {
$area[] = pow($shape->length, 2);
} else if(is_a($shape, 'Circle')) {
$area[] = pi() * pow($shape->radius, 2);
}
}
return array_sum($area);
}
If we wanted the sum method to be able to sum the areas of more shapes, we would have to add more if/else blocks and that goes against the Open-closed principle.A way we can make this sum method better is to remove the logic to calculate the area of each shape out of the sum method and attach it to the shape's class.
class Square {
public $length;
public function __construct($length) {
$this->length = $length;
}
public function area() {
return pow($this->length, 2);
}
}
The same thing should be done for the Circle class, an area method should be added. Now, to calculate the sum of any shape provided should be as simple as:public function sum() {
foreach($this->shapes as $shape) {
$area[] = $shape->area();
}
return array_sum($area);
}
Now we can create another shape class and pass it in when calculating
the sum without breaking our code. However, now another problem arises,
how do we know that the object passed into the AreaCalculator is actually a shape or if the shape has a method named area?Coding to an interface is an integral part of S.O.L.I.D, a quick example is we create an interface, that every shape implements:
interface ShapeInterface {
public function area();
}
class Circle implements ShapeInterface {
public $radius;
public function __construct($radius) {
$this->radius = $radius;
}
public function area() {
return pi() * pow($this->radius, 2);
}
}
In our AreaCalculator sum method we can check if the shapes provided are actually instances of the ShapeInterface, otherwise we throw an exception:public function sum() {
foreach($this->shapes as $shape) {
if(is_a($shape, 'ShapeInterface')) {
$area[] = $shape->area();
continue;
}
throw new AreaCalculatorInvalidShapeException;
}
return array_sum($area);
}
Liskov substitution principle
Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.All this is stating is that every subclass/derived class should be substitutable for their base/parent class.
Still making use of out AreaCalculator class, say we have a VolumeCalculator class that extends the AreaCalculator class:
class VolumeCalculator extends AreaCalulator {
public function construct($shapes = array()) {
parent::construct($shapes);
}
public function sum() {
return array($summedData);
}
}
In the SumCalculatorOutputter class:class SumCalculatorOutputter {
protected $calculator;
public function __constructor(AreaCalculator $calculator) {
$this->calculator = $calculator;
}
public function JSON() {
$data = array(
'sum' => $this->calculator->sum();
);
return json_encode($data);
}
public function HTML() {
return implode('', array(
'',
'Sum of the areas of provided shapes: ',
$this->calculator->sum(),
''
));
}
}
If we tried to run an example like this:$areas = new AreaCalculator($shapes);
$volumes = new AreaCalculator($solidShapes);
$output = new SumCalculatorOutputter($areas);
$output2 = new SumCalculatorOutputter($volumes);
The program does not squawk, but when we call the HTML method on the $output2 object we get an E_NOTICE error informing us of an array to string conversion.To fix this, instead of returning an array from the VolumeCalculator class sum method, you should simply:
public function sum() {
return $summedData;
}
The summed data as a float, double or integer.Interface segregation principle
A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use.Still using our shapes example, we know that we also have solid shapes, so since we would also want to calculate the volume of the shape, we can add another contract to the ShapeInterface:
interface ShapeInterface {
public function area();
public function volume();
}
Any shape we create must implement the volume method, but we know that squares are flat shapes and that they do not have volumes, so this interface would force the Square class to implement a method that it has no use of.ISP says no to this, instead you could create another interface called SolidShapeInterface that has the volume contract and solid shapes like cubes e.t.c can implement this interface:
interface ShapeInterface {
public function area();
}
interface SolidShapeInterface {
public function volume();
}
class Cuboid implements ShapeInterface, SolidShapeInterface {
public function area() {
}
public function volume() {
}
}
This is a much better approach, but a pitfall to watch out for is when type-hinting these interfaces, instead of using a ShapeInterface or a SolidShapeInterface.You can create another interface, maybe ManageShapeInterface, and implement it on both the flat and solid shapes, this way you can easily see that it has a single API for managing the shapes. For example:
interface ManageShapeInterface {
public function calculate();
}
class Square implements ShapeInterface, ManageShapeInterface {
public function area() { /Do stuff here/ }
public function calculate() {
return $this->area();
}
}
class Cuboid implements ShapeInterface, SolidShapeInterface, ManageShapeInterface {
public function area() { /Do stuff here/ }
public function volume() { /Do stuff here/ }
public function calculate() {
return $this->area() + $this->volume();
}
}
Now in AreaCalculator class, we can easily replace the call to the area method with calculate and also check if the object is an instance of the ManageShapeInterface and not the ShapeInterface.Dependency Inversion principle
The last, but definitely not the least states that:Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.This might sound bloated, but it is really easy to understand. This principle allows for decoupling, an example that seems like the best way to explain this principle:
class PasswordReminder {
private $dbConnection;
public function __construct(MySQLConnection $dbConnection) {
$this->dbConnection = $dbConnection;
}
}
First the MySQLConnection is the low level module while the PasswordReminder is high level, but according to the definition of D in S.O.L.I.D. which states that Depend on Abstraction not on concretions, this snippet above violates this principle as the PasswordReminder class is being forced to depend on the MySQLConnection class.Later if you were to change the database engine, you would also have to edit the PasswordReminder class and thus violates Open-close principle.
The PasswordReminder class should not care what database your application uses, to fix this again we "code to an interface", since high level and low level modules should depend on abstraction, we can create an interface:
interface DBConnectionInterface {
public function connect();
}
The interface has a connect method and the MySQLConnection class implements this interface, also instead of directly type-hinting MySQLConnection class in the constructor of the PasswordReminder, we instead type-hint the interface and no matter the type of database your application uses, the PasswordReminder class can easily connect to the database without any problems and OCP is not violated.class MySQLConnection implements DBConnectionInterface {
public function connect() {
return "Database connection";
}
}
class PasswordReminder {
private $dbConnection;
public function __construct(DBConnectionInterface $dbConnection) {
$this->dbConnection = $dbConnection;
}
}
According to the little snippet above, you can now see that both the high level and low level modules depend on abstraction.Conclusion
Honestly, S.O.L.I.D might seem to be a handful at first, but with continuous usage and adherence to its guidelines, it becomes a part of you and your code which can easily be extended, modified, tested, and refactored without any problems.Saturday, December 22, 2018
Friday, December 21, 2018
Thursday, December 13, 2018
Some key figures that have influenced thinking about research
- Plato (427–347 BC) and Aristotle (348–322 BC) – these represent the two contrasting approaches to acquiring knowledge and understanding the world (epistemology). Plato argued for deductive thinking (starting with theory to make sense of what we observe) and Aristotle for the opposite, inductive thinking (starting with observations in order to build theories).
- René Descartes (1596–1650) – provided the starting point for modern philosophy by using a method of systematic doubt; that we cannot rely on our senses or logic, and therefore he challenged all who sought for the basis of certainty and knowledge. His famous maxim is ‘I think, therefore I am’, that is – I can only be sure of my own existence, the rest must be doubted.
- John Locke (1632–1704) – made the distinction between bodies or objects that can be directly measured, and therefore have a physical existence, and those abstract qualities that are generated by our perceptions and feelings.
- George Berkeley (1685–1753) – argued that all things that exist are only mental phenomena. They exist by being perceived. This is ‘our’ world.
- David Hume (1711–1776) – made a distinction between systems of ideas that can provide certainty – e.g. maths – and those that rely on our perceptions (empirical evidence) which are not certain. He recognized the importance of inductive thinking in the advancement of scientific knowledge, but highlighted its restrictions in finding the truth.
- Immanuel Kant (1724–1804) – held that our minds organize our experiences to make sense of the world. Therefore ‘facts’ are not independent of the way we see things and interpret them.
- Karl Popper (1902–1994) – formulated a combination of deductive and inductive thinking in the hypothetico-deductive method, commonly known as scientific method. This method aims to refine theories to get closer to the truth.
- Auguste Compte (1789–1857) – maintained that society can be analysed empirically just like any other subjects of scientific enquiry. Social laws and theories are based on psychology and biology.
- Karl Marx (1818–1883) – defined moral and social aspects of humanity in terms of material forces.
- Emil Durkheim (1858–1917) – argued that society develops its own
- system of collectively shared norms and beliefs – these were ‘social facts’.
- Max Weber (1864–1920) – insisted that we need to understand the values and meanings of subjects without making judgements – ‘verstehen’ was the term he coined for this which is German for ‘understanding’.
- Thomas Kuhn (1922–1995) – revealed that scientific research cannot be separated from human influences and is subject to social norms.
- Michel Foucault (1926–1984) – argued that there was no progress in science, only changing perspectives, as the practice of science is shown to control what is permitted to count as knowledge. He demonstrated how discourse is used to make social regulation and control appear natural.
- Jacques Derrida (1930–2004) – stated that there is no external or fixed meaning to text, nor is there a subject who exists prior to language and to particular experiences. You cannot get outside or beyond the structure. This approach led to the movement called Deconstruction.
Sunday, December 09, 2018
Os 12 Arquétipos Comuns
O termo “arquétipo” tem suas origens na Grécia antiga, as palavras raiz são archein que significa “original ou velho” e typos que significa “padrão, modelo ou tipo”, o significado combinado é “padrão original” do qual todas as outras pessoas similares, objetos ou conceitos são derivados, copiados, modelados, ou emulados.
O psicólogo Carl Gustav Jung usou o conceito de arquétipo em sua teoria da psique humana, ele acreditava que arquétipos de míticos personagens universais residiam no interior do inconsciente coletivo das pessoas em todo o mundo, arquétipos representam motivos humanos fundamentais de nossa experiência como nós evoluímos consequentemente eles evocam emoções profundas.
Embora existam muitos diferentes arquétipos, Jung definiu doze tipos principais que simbolizam as motivações humanas básicas, cada tipo tem seu próprio conjunto de valores, significados e traços de personalidade, além disso, os doze tipos são divididos em três grupos de quatro, ou seja, Ego, Alma e Eu, os tipos em cada conjunto compartilha uma fonte de condução comum, por exemplo, tipos dentro do conjunto Ego são levados a cumprir agendas definidas pelo ego.
A maioria se não todas as pessoas têm vários arquétipos em jogo na construção da sua personalidade, no entanto, um arquétipo tende a dominar a personalidade em geral, ele pode ser útil para saber quais arquétipos estão em jogo em si e nos outros, especialmente nos entes queridos, amigos e colegas de trabalho a fim de obter uma visão pessoal sobre comportamentos e motivações.
Os Tipos de Ego
1. O Inocente
Lema: Livre para ser você e eu
Desejo principal: Chegar ao paraíso
Objetivo: ser feliz
Maior medo: Ser punido por ter feito algo de ruim ou errado
Estratégia: Fazer as coisas certas
Fraqueza: Chato por toda a sua inocência ingênua
Talento: Fé e otimismo
O Inocente também é conhecido como: utópico, tradicionalista, ingênuo, místico, santo, romântico, sonhador.
2. O Cara Comum, o Órfão
Lema: Todos os homens e mulheres são iguais
Desejo central: Ligação com os outros
Objetivo: Fazer parte
Maior medo: Ficar de fora ou se destacar da multidão
Estratégia: Desenvolver sólidas virtudes comuns, seja para a Terra ou o contato comum
Fraqueza: Perder o próprio Eu em um esforço para se misturar ou por uma questão de relações superficiais
Talento: O realismo, a empatia, a falta de pretensão
A pessoa normal também é conhecida como: O bom menino velho, o homem comum, a pessoa da porta ao lado, o realista, o cidadão sólido, o trabalhador rígido, o bom vizinho, a maioria silenciosa.
3. O Herói
Lema: Onde há uma vontade, há um caminho
Desejo central: Provar o valor para alguém através de atos corajosos
Objetivo: Especialista em domínio de um modo que melhore o mundo
Maior medo: Fraqueza, vulnerabilidade, ser um “covarde”
Estratégia: Ser tão forte e competente quanto possível
Fraqueza: Arrogância, sempre precisando de mais uma batalha para lutar
Talento: Competência e coragem
O herói também é conhecido como: O guerreiro, o salvador, o super-herói, o soldado, o matador de dragão, o vencedor e o jogador da equipe.
4. O Cuidador
Lema: Ame o seu próximo como a si mesmo
Desejo central: Proteger e cuidar dos outros
Objetivo: Ajudar os outros
Maior medo: Egoísmo e ingratidão
Estratégia: Fazer coisas para os outros
Fraqueza: Martírio e ser explorado
Talento: Compaixão e generosidade
O cuidador também é conhecido como: O santo, o altruísta, o pai, o ajudante, o torcedor.
Os Tipos de Alma
5. O Explorador
Lema: Não me cerque
Desejo central: A liberdade de descobrir quem é através da exploração do mundo
Objetivo: A experiência de um mundo melhor, mais autêntico, mais gratificante na vida
Maior medo: Ficar preso, conformidade e vazio interior
Estratégia: Viajar, procurar e experimentar coisas novas, fugir do tédio
Fraqueza: Perambular sem destino tornando-se um desajustado
Talento: Autonomia, ambição, ser fiel a sua alma
O explorador também é conhecido como: O candidato, o iconoclasta, o andarilho, o individualista, o peregrino.
6. O Rebelde
Lema: As regras são feitas para serem quebradas
Desejo central: Vingança ou revolução
Objetivo: Derrubar o que não está funcionando
Maior medo: Ser impotente ou ineficaz
Estratégia: Interromper, destruir ou chocar
Fraqueza: Cruzar para o lado negro do crime
Talento: Ousadia, liberdade radical
O rebelde também é conhecido como: O ilegal, o revolucionário, o homem selvagem, o desajustado, o iconoclasta.
7 O Amante
Lema: Você é único
Desejo central: Intimidade e experiência
Objetivo: Estar em um relacionamento com as pessoas no trabalho e no ambiente que eles amam
Maior medo: Ficar sozinho, ser um invisível, se indesejado, ser mal amado
Estratégia: Tornar-se cada vez mais atraente fisicamente e emocionalmente
Fraqueza: Com o desejo de agradar aos outros corre o risco de perder sua identidade externa
Talento: Paixão, gratidão, valorização e compromisso
O amante também é conhecido como: O parceiro, o amigo íntimo, o entusiasta, o sensualista, o cônjuge, o construtor de equipe.
8. O Criador
Lema: Se você pode imaginar algo, isso pode ser feito
Desejo central: Criar coisas de valor duradouro
Objetivo: Realizar uma visão
Maior medo: A visão ou a execução medíocre
Estratégia: Desenvolver a habilidade e o controle artístico
Tarefa: Criar cultura, expressar a própria visão
Fraqueza: Perfeccionismo, soluções ruins
Talento: Criatividade e imaginação
O Criador também é conhecido como: O artista, o inventor, o inovador, o músico, o escritor, o sonhador.
Os tipos de Eu
9. O Tolo
Lema: Só se vive uma vez
Desejo central: Viver para o momento com pleno gozo
Objetivo: Ter um grande momento e iluminar o mundo
Maior medo: Se aborrecer ou chatear os outros
Estratégia: Jogar, fazer piadas, ser engraçado
Fraqueza: Frivolidade, desperdício de tempo
Talento: Alegria
O tolo também é conhecido como: O bobo da corte, o malandro, o palhaço, o brincalhão, o comediante.
10. O Sábio
Lema: A verdade vos libertará
Desejo central: Encontrar a verdade
Objetivo: Usar a inteligência e a análise para compreender o mundo
Maior medo: Ser enganado, iludido, ou ser ignorante
Estratégia: Buscar informação e conhecimento, auto reflexão e compreensão dos processos de pensamento
Fraqueza: Pode estudar detalhes para sempre e nunca agir
Talento: Sabedoria, inteligência
O Sábio também é conhecido como: O perito, o erudito, o detetive, o conselheiro, o pensador, o filósofo, o acadêmico, o pesquisador, o pensador, o planejador, o profissional, o mentor, o professor, o contemplador.
11. O mágico
Lema: Eu faço as coisas acontecerem.
Desejo central: Compreensão das leis fundamentais do universo
Objetivo: Realizar sonhos
Maior medo: Consequências negativas não intencionais
Estratégia: Desenvolver uma visão e viver por ela
Fraqueza: Se tornar manipulador
Talento: Encontrar soluções ganha-ganha
O mágico também é conhecido como: O visionário, o catalisador, o inventor, o líder carismático, o xamã, o curandeiro, o feiticeiro.
12. O Governante
Lema: O poder não é qualquer coisa, é a única coisa
Desejo central: Controle e poder
Objetivo: Criar uma família ou uma comunidade bem sucedida e próspera
Estratégia: Exercer o poder
Maior medo: O caos, ser destituído
Fraqueza: Ser autoritário, incapaz de delegar
Talento: Responsabilidade, liderança
O Governante é também conhecido como: O chefe, o líder, o ditador, o aristocrata, o rei, a rainha, o político, o gerente, o administrador.
As quatro Orientações cardeais
As quatro orientações cardeais definem quatro grupos, com cada grupo contendo três tipos (como a roda de arquétipos acima ilustra), cada grupo é motivado por seu respectivo foco orientador: satisfação do ego, liberdade, socialidade e ordem, esta é uma variação nos grupos dos três tipos anteriormente mencionados, no entanto, todos os tipos dentro do Ego, Alma e Eu compartilham da mesma fonte de condução, os tipos que compõem a orientação dos quatro grupos têm diferentes unidades de origem, mas a mesma orientação de motivação, por exemplo, o cuidador é impulsionado pela necessidade de cumprir agendas do ego através do atendimento das necessidades dos outros que é uma orientação social, considerando que o herói também é impulsionado pela necessidade de cumprir agendas do ego o faz através de ação corajosa que comprova a autoestima, compreender os agrupamentos ajudará na compreensão da dinâmica de motivação e autopercepção de cada tipo.
Carl Golden
Subscribe to:
Posts (Atom)