Special Issue: Technological Pedagogical Content Knowledge

This Special Issue is dedicated to advancing the theory as well as contrasting conceptual frameworks that inform and guide research in the area of technology integration in teaching and learning (Selfe, 1990; Zhao, 2003; Margerum-Rays & Marx, 2003; Niess, 2005; Angeli, 2005; Mishra & Koehler, 2006; Gess-Newsome, 1999). Selfe (1990) recognizes this need and indicates that “until we share some theoretical vision of this topic, we will never glimpse the larger picture that could give our everyday classroom efforts direction and meaning (p. 119).

Given that the knowledge base of the teaching profession is not adequately developed to guide teacher preparation in technology integration, researchers during the last five years initiated systematic research programs for the purpose of developing theory and models to ground research in the area of teacher cognition about technology integration (Margerum-Rays & Marx, 2003; Angeli & Valanides, 2005; Angeli & Valanides, 2009; Mishra & Koehler, 2006). Particularly, it is advocated that teachers need to develop a new body of knowledge, namely, technological pedagogical content knowledge (TPCK). TPCK constitutes an enrichment to Shulman’s (1986, 1987) pedagogical content knowledge (PCK), and is conceptualized as a body of knowledge that results from the interaction among different teacher knowledge bases, such as, knowledge about subject matter, pedagogy, learners, context, and technology. Studies on TPCK are worthy of consideration and critical examination from the research community at large, as they reflect a new direction in understanding the complex interactions among content, pedagogy, learners, context, and technology.

This special issue of the Journal of Educational Computing Research will focus on TPCK. The Guest Editors seek manuscripts that discuss, critique, and advance the theoretical conceptions of TPCK, or report data (quantitative, qualitative, or mixed) on methods of how to develop and assess TPCK. The issue strives to be international in scope.


Angeli, C. (2005). Transforming a teacher education method course through technology: Effects on preservice Teachers’ technology competency. Computers & Education45(4), 383–398.

Angeli, C., & Valanides, N. (2005). Preservice teachers as ICT designers: An instructional design model based on an expanded view of pedagogical content knowledge. Journal of Computer-Assisted Learning21(4), 292–302.

Angeli, C., & Valanides, N. (2009). Epistemological and methodological issues for the conceptualization, development, and assessment of ICT–TPCK: Advances in technological pedagogical content knowledge (TPCK). Computers & Education52, 154-168.

Gess-Newsome, J. (1999). Pedagogical content knowledge: An introduction and   orientation. In J. Gess-Newsome & N. G. Nederman (Eds.), Examining           pedagogical content knowledge (pp. 3-17). Dordrecht, The Netherlands:    Kluwer Academic.

Margerum-Lays, J., & Marx, R. W. (2003). Teacher knowledge of educational technology: A case study of student/mentor teacher pairs. In Y. Zhao (Ed.), What should teachers know about technology? Perspectives and practices (pp. 123–159). Greenwich, CO: Information Age Publishing.

Mishra, P., & Koehler, M. J. (2006). Technological pedagogical content knowledge: A new framework for teacher knowledge. Teachers College Record108(6), 1017–1054.

Niess, M. L. (2005). Preparing teachers to teach science and mathematics with technology: Developing a technology pedagogical content knowledge. Teaching and Teacher Education21(5), 509–523.

Selfe, C. (1990). Technology in the english classroom: Computers through the lens of feminist pedagogy. In C. Handa (Ed.), Computers and community: Teaching composition in the twenty-first century (pp. 118–139). Portsmouth, NH: Boynton/Cook.

Shulman, L. S. (1986). Those who understand: Knowledge growth in teaching. Educational Researcher, 15, 4–14.

Shulman, L. S. (1987). Knowledge and teaching: Foundations of the new reform. Harvard Educational Review, 57, 1–22.

Zhao, Y. (Ed.). (2003). What should teachers know about technology? Perspectives and practices. Greenwich, CO: Information Age Publishing.


Object-Oriented Programming Gone Wrong

Object-oriented Programming (OOP) can be defined as a programming language model organized around “objects” rather than “actions” and data rather than logic. In other words, OOP focuses on objects that we want to manipulate in the business domain and assign behavior that manipulates the data encapsulated by these objects. A domain model is a visual representation of conceptual classes or real-world objects (domain objects) in a business domain.

Languages that enable OOP have been in the mainstream for three decades now. But with the introduction of JAVA and .NET framework, OOP has become widespread across the enterprise. Many business processes are being automated, and developers are increasingly using these languages.

Object-Oriented vs Procedural ProgrammingBut is the developer community using these languages as they were meant to? To illustrate, consider a fictitious scenario where a developer has been tasked to convert the program written in a procedural style to an object-oriented language say JAVA. How would he go about this task? He probably would refer JAVA material, understand the JAVA constructs and the principles of object orientation and then write the code. If he is motivated, he might look up popular design patterns (Gamma et al., 1994) and apply them where applicable. Once completed, the program would probably look similar.

What is Wrong?

In the example, OOP principles like inheritance (Larman 2002, p. 409) and polymorphism (Larman, 2002, p. 326), as well as design patterns have been used to organize code. But the classes in the example above do not have their responsibilities distributed appropriately. The domain objects in the code snippet above have data only. They do not have any behavior. Additionally, all the logic is concentrated in the ‘Manager’ class. The programmer has put in a lot of thought in writing the logic that satisfies the business requirements, but not on the domain model. The true benefits of object orientation have not been realized.

This is a pretty common phenomenon. Martin Fowler, author, and speaker describes this feature as ‘Anemic Domain Model.’ He says:

This is one of those anti-patterns that’s been around for quite a long time, yet seems to be having a particular spur of the moment.

So why are developers, after more than thirty years of popular object-oriented languages out there, still writing code that resembles code written in procedural style? A few reasons that come to mind are:

  • The subjective nature of domain analysis and design make OOP hard. There are no step-by-step instructions to follow while modeling a business domain. Each business has its own set of quirks and exceptions.
  • It is easier to understand the code in procedural style for particular business logic as all the logic is in one place as opposed to OOP where logic is dispersed in different classes.
  • It is easier to code in procedural style as you do not need to figure out what which object to assign a particular behavior to
  • You do not need to understand or represent the complex object relationships that are often the case in any real-world problem domain that the software is trying to solve

Due to this, developers often take the easy route and do not spend much time in modeling the domain. The downsides of these:

  • The logic can be duplicated in multiple places as different processes are defined taking these objects into consideration. One can argue that the duplication can be avoided by extracting the common logic into common helper classes. But then you have unrelated logic sitting in these classes.
  • Logic may contradict each other as they are dispersed in multiple areas.
  • And because logic is dispersed it is difficult to make changes to the different processes.

What Can be Done?

Eric Evans notes that talented developers are more concerned with designing frameworks, rather than getting into the guts of a problem domain (Evans, 2003, p.4). This is mostly because gaining a good understanding to model the problem domain is a time-consuming process that requires immense patience and close work with the business stakeholders, which developers are either not willing to do or not given enough time to do so.

Analysis and DesignWhat then can be done to encourage proper domain design? For one thing, it is foremost necessary for an organization to realize that poorly designed model is indeed detrimental to the overall health of the application. It is required then to understand the state your domain currently is in and if it needs improvement, take the necessary steps.

When discussing solutions for the problem domain, an attempt should be made to present solutions concerning the domain model rather than the data model. This shift to domain model will encourage the developer community to think in terms of objects rather than just data that needs to be manipulated somehow.

An organization needs to understand and augment the skill set of its resources. Mentors and experts need to ensure that developers invest time upfront in organizing their thoughts around objects and their behavior. They should resist the temptation to rush ahead into coding the solution. In the example above if the payment logic is moved to the ‘Card’ class, it would make for a better design. The manager class then becomes just an entry point to the domain and it does not have any logic.

The important thing to realize is that there isn’t any single right model. There is always more than one solution. Different approaches can be taken, and they can all capture the problem domain accurately enough to solve the problem at hand as well as making it easy to extend it later on. One need not be afraid to undertake this process for fear of getting it wrong. Robert C Martin, founder and president of Object Mentor Inc, says “I’ve personally learned probably most of what I know based on either making mistakes or observing other mistakes” .

Over time object-oriented design will become second nature to the developer.


As cited in the fictitious example above, often a developer may not realize that there is anything wrong with the approach being taken. It is, therefore, necessary to understand the expertise level of your development team and offer training to ensure proper understanding. Ultimately, the developer community needs to accept and make a commitment to start applying an object-oriented approach to problem-solving.


Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional

Larman, C. (2002). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional